Cookie Attributes

1

Introduction

i

Introduction

Session identifiers are commonly transported in cookies, which means the security of an authenticated session depends heavily on how that cookie is configured, not just on how securely the session ID itself was generated.

A strong, unpredictable session ID can still be exposed or abused if the cookie carrying it is allowed to travel over an insecure connection, be read by injected JavaScript, or be automatically attached in unsafe cross-site contexts.

Each cookie attribute addresses a different risk:

Secure
→ prevents transmission over plain HTTP

HttpOnly
→ prevents JavaScript from directly reading the cookie

SameSite
→ restricts cookie transmission in cross-site contexts

Path / Domain
→ limit which parts of the application receive the cookie

A production session cookie should combine the appropriate protections rather than relying on any single attribute:

Set-Cookie: session=a9f3e7c1b2d84f...;
            Secure;
            HttpOnly;
            SameSite=Lax;
            Path=/

The important principle is that these controls are independent layers:

Strong session ID
        +
Secure cookie configuration
        +
HTTPS
        +
Session regeneration
        +
Proper server-side invalidation

A failure in any one area can undermine the security of the session.

2

Concept

Cookie Secure

The Secure attribute tells the browser to send a cookie only over HTTPS connections.

Set-Cookie: session=a9f3e7c1b2d84f...; Secure

Without Secure, a browser may send the session cookie over plain HTTP if it makes an HTTP request to a matching domain.

User visits:

http://example.com
        ↓
Browser sends:
Cookie: session=a9f3e7c1b2d84f...
        ↓
Cookie travels without HTTPS encryption
        ↓
Someone able to observe the connection
may capture the session ID

The risk can arise from situations such as:

Stale http:// bookmark
Shared http:// link
Misconfigured redirect
Network attempting to interfere with HTTPS access

If a session credential is transmitted over an unencrypted connection, anyone able to observe that traffic may be able to capture it and reuse the session.

With Secure enabled:

HTTP request
        ↓
Browser does NOT send Secure cookie

HTTPS request
        ↓
Browser may send Secure cookie

The attribute therefore protects the session credential from accidentally being exposed through a plain HTTP request.

For a production application served over HTTPS, session cookies should normally always include:

Secure

However, Secure protects the cookie, not the entire application:

Secure cookie
→ prevents that cookie from being sent over HTTP

HTTPS enforcement
→ ensures the application itself is accessed securely

Applications should therefore also redirect HTTP traffic to HTTPS and, where appropriate, use mechanisms such as HSTS to reduce the chance that users ever reach the insecure version in the first place.

3

Concept

Cookie HttpOnly

The HttpOnly attribute tells the browser to withhold the cookie from JavaScript. When a cookie is marked HttpOnly, it will not appear in document.cookie, regardless of what script is running on the page.

Set-Cookie: session=a9f3e7c1b2d84f...; HttpOnly

Without HttpOnly, an XSS vulnerability may allow injected JavaScript to read and steal the session cookie:

document.cookie

The attack can look like:

XSS vulnerability
        ↓
Attacker's JavaScript runs
        ↓
Reads session cookie
        ↓
Sends cookie to attacker
        ↓
Attacker reuses stolen session

With HttpOnly enabled:

XSS vulnerability
        ↓
Attacker's JavaScript runs
        ↓
document.cookie
        ↓
Session cookie is not accessible

The script may still run, but it cannot directly read that particular cookie.

The important limitation is:

HttpOnly
→ helps prevent cookie theft through JavaScript

HttpOnly
≠
prevents XSS

An attacker with JavaScript execution in the victim's browser may still be able to perform actions using the victim's existing authenticated session:

Attacker's script runs
        ↓
Sends request to application
        ↓
Browser automatically attaches
the HttpOnly session cookie
        ↓
Server sees an authenticated request

The attacker cannot necessarily steal the cookie, but they may still be able to abuse the victim's active session while their script is running.

For this reason, HttpOnly should be treated as a damage-limitation control, not an XSS defense.

Fix XSS
→ prevents attacker-controlled script execution

HttpOnly
→ reduces the ability of that script
   to steal the session credential

4

Concept

Cookie Samesite

The SameSite attribute controls whether a cookie is sent when a request occurs in a cross-site context.

This matters because browsers normally attach session cookies automatically. That automatic behavior is what classic Cross-Site Request Forgery relies on:

Victim is logged in to:

https://bank.example
        ↓
Victim visits:

https://attacker.example
        ↓
Malicious page triggers a request to:

https://bank.example/transfer
        ↓
Browser may automatically attach
the victim's session cookie
        ↓
Server sees an authenticated request

SameSite restricts when that cookie is allowed to travel in these cross-site situations.

5

Concept

Cookie Domain

The Domain attribute controls which hosts are allowed to receive a cookie.

The safest default is usually to omit the Domain attribute entirely:

Set-Cookie: session=abc123;
            Secure;
            HttpOnly;
            SameSite=Lax

When Domain is omitted, the browser creates a host-only cookie.

If it was set by:

app.cyunified.com

it is sent only to:

app.cyunified.com

It is not automatically sent to:

www.cyunified.com
blog.cyunified.com
staging.cyunified.com

If the application explicitly sets:

Set-Cookie: session=abc123;
            Domain=cyunified.com

the cookie becomes available to the domain and its matching subdomains:

cyunified.com
app.cyunified.com
www.cyunified.com
blog.cyunified.com

A weakness on a subdomain can potentially create risk for the broader cookie scope. Depending on the specific vulnerability and cookie configuration, an attacker controlling a subdomain may also be able to interfere with cookies intended for other hosts under the same parent domain.

The general rule is:

Need cookie on one host only?
→ Omit Domain

Need cookie shared across subdomains?
→ Set Domain as narrowly as possible
→ Trust every subdomain included in that scope

Every time you broaden a cookie's Domain scope, you broaden the trust boundary of that credential. A session cookie should be sent to as few hosts as the application actually requires.

6

Concept

Cookie Path

The Path attribute restricts which URL paths receive a cookie.

For example:

Set-Cookie: admin_session=abc123; Path=/admin

The browser will attach that cookie to requests such as:

/admin
/admin/users
/admin/settings

But not normally to:

/blog
/products
/account

So:

Path=/admin

/admin/users      → cookie sent
/admin/settings   → cookie sent
/blog/article     → cookie not sent

This can reduce unnecessary cookie exposure and help keep different parts of an application logically separated.

However, Path should not be treated as a real security boundary.

Path is useful for controlling cookie delivery and reducing unnecessary scope, but it is not a substitute for real cookie security controls. Use it for organization and scope reduction; rely on HttpOnly, Secure, and SameSite for the primary security protections.

7

Concept

Cookie Prefixes

__Host- and __Secure- are special cookie name prefixes with rules that are enforced by the browser, rather than being merely naming conventions.

__Host- :

A cookie named with the __Host- prefix is only accepted if it satisfies all of these requirements:

Set-Cookie: __Host-session=abc123;
            Secure;
            Path=/

The browser requires:

__Host- prefix
        ↓
Secure required        → HTTPS only
No Domain attribute    → exact host only
Path=/ required        → available across that host

This means the following will be rejected:

Set-Cookie: __Host-session=abc123; Path=/

No Secure attribute.

Set-Cookie: __Host-session=abc123;
            Secure;
            Domain=example.com;
            Path=/

Domain is not allowed.

Set-Cookie: __Host-session=abc123;
            Secure;
            Path=/admin

Path must be exactly /.

The result is a host-only cookie that cannot accidentally be broadened to subdomains:

Cookie set by:

app.example.com
__Host-session
        ↓
Sent to:

app.example.com        ✅
www.example.com        ❌
api.example.com        ❌
blog.example.com       ❌

This is particularly useful against cookie-scope problems involving subdomains. A potentially compromised subdomain cannot create a __Host- cookie for the parent domain using:

Domain=example.com

because that would violate the prefix requirements and the browser will reject it.

__Secure-:

__Secure- is less restrictive.

Set-Cookie: __Secure-session=abc123; Secure

The browser requires only:

__Secure- prefix
        ↓
Secure attribute required

Unlike __Host-, it can still use:

Domain=example.com
Path=/admin

For a session cookie that only needs to belong to one specific host, __Host- is generally the strongest option:

Set-Cookie: __Host-session=a9f3e7c1b2d84f...;
            Secure;
            HttpOnly;
            SameSite=Lax;
            Path=/

The session cookie must be HTTPS-only and must belong exclusively to the exact host that created it.

Introduction

Cookie Secure

Cookie HttpOnly

Cookie Samesite

Cookie Domain

Cookie Path

Cookie Prefixes

You've completed Session Management