highWeb Security

Insecure Cookie Flags Allow Session Hijacking and CSRF

What Is This Vulnerability?

Session cookies and authentication tokens stored in cookies must be configured with the Secure, HttpOnly, and SameSite flags. Without Secure, cookies are sent over unencrypted HTTP connections. Without HttpOnly, JavaScript can read them via document.cookie. Without SameSite, they are attached to cross-site requests, enabling CSRF attacks.

Why It Happens

Many cookie-setting libraries and frameworks default to permissive cookie flags for backward compatibility. Developers set the cookie value without explicitly configuring security attributes, and the defaults (no Secure, no HttpOnly, SameSite=None or Lax depending on browser) leave the cookie exposed.

Example Code

Vulnerableapp/api/auth/login/route.ts
import { NextResponse } from "next/server";

export async function POST(request: Request) {
  const { email, password } = await request.json();
  const session = await authenticate(email, password);

  const response = NextResponse.json({ success: true });
  // Cookie set without security flags
  response.cookies.set("session_id", session.id);
  return response;
}
Fixedapp/api/auth/login/route.ts
import { NextResponse } from "next/server";

export async function POST(request: Request) {
  const { email, password } = await request.json();
  const session = await authenticate(email, password);

  const response = NextResponse.json({ success: true });
  response.cookies.set("session_id", session.id, {
    httpOnly: true,
    secure: true,
    sameSite: "strict",
    maxAge: 60 * 60 * 24,
    path: "/",
  });
  return response;
}

How Hackers Exploit It

Without HttpOnly, an XSS attack can steal the session cookie with document.cookie and send it to the attacker's server. Without Secure, an attacker on the same network can intercept the cookie over an HTTP connection. Without SameSite, a malicious site can trigger authenticated requests to your app using the victim's cookies.

How to Fix It

Always set httpOnly: true to prevent JavaScript access, secure: true to restrict the cookie to HTTPS connections, and sameSite: 'strict' or 'lax' to control cross-site sending behavior. Set a reasonable maxAge and scope the cookie to the narrowest path needed. Audit all places in your codebase where cookies are set.

Frequently Asked Questions

What does the HttpOnly flag actually prevent?
The HttpOnly flag tells the browser to block JavaScript from accessing the cookie via document.cookie or similar APIs. This means even if an attacker successfully injects a script through an XSS vulnerability, they cannot read or exfiltrate the session cookie.
When should I use SameSite Strict vs Lax?
Use Strict for sensitive session cookies since it blocks the cookie on all cross-site requests, including top-level navigations. Use Lax for cookies that need to survive link clicks from external sites (like email links) while still blocking cross-site POST requests.
Do cookie flags protect against all session attacks?
Cookie flags are one layer of defense. They prevent common attacks like XSS cookie theft and CSRF, but you still need server-side session management best practices: short expiration times, session regeneration after login, and proper logout that invalidates the session on the server.

Related Security Topics

Missing Content Security Policy Header Enables Script Injection

Learn about missing content security policy header enables script injection and how to fix it.

Missing HTTPS Redirect Exposes Traffic to Interception

Learn about missing https redirect exposes traffic to interception and how to fix it.

Missing HTTP Security Headers Expose Application to Common Attacks

Learn about missing http security headers expose application to common attacks and how to fix it.

Check Your Code for This Vulnerability

Run a free scan to check if your site is affected by insecure cookie flags allow session hijacking and csrf.