Redirect Cookie Behavior

Understanding how cookies behave when following HTTP redirects is crucial for cookie management in web applications.

Types of Redirects

301 Permanent Redirect

• Browser may cache the redirect
• Search engines update their index
• Cookies set on redirect domain are sent with redirect request

302 Temporary Redirect

• Browser does not cache redirect
• Original URL remains indexed
• Cookies behave similarly to 301

Cookie Behavior with Redirects

Scenario 1: Cookie Set Before Redirect

Flow:

1. User visits redirect.example.com
2. Server sets cookie: Set-Cookie: session=abc; Domain=redirect.example.com
3. Server responds with 301 redirect to target.example.com
4. Browser follows redirect
5. Request to target.example.com includes cookie from redirect domain

Important: Cookies are sent with the redirect request if:

• Domain matches
• Path matches
• SameSite policy allows

Sequence Diagram:

Scenario 2: Cookie Set After Redirect

Flow:

1. User visits redirect.example.com
2. Server responds with 301 redirect to target.example.com
3. Browser follows redirect to target.example.com
4. Server sets cookie: Set-Cookie: session=xyz; Domain=target.example.com
5. Cookie is stored for target domain

Sequence Diagram:

Scenario 3: Cross-Domain Redirect

Flow:

1. User visits redirect.example.com
2. Server responds with 301 redirect to target.example.com (different domain)
3. Browser follows redirect

Cookie Considerations:

• Cookies with SameSite=Strict are NOT sent with cross-site redirects [^1]
• Cookies with SameSite=Lax ARE sent with top-level navigation redirects (with important nuances - see below) [^1]
• Cookies with SameSite=None; Secure are sent with all redirects (requires HTTPS) [^1]

Critical Domain Attribute Requirement:

For a cookie set on redirect.example.com to be sent to target.example.com after a redirect, the cookie's Domain attribute must explicitly allow the target domain. Simply having SameSite=Lax is not sufficient:

• ❌ Won't work: Set-Cookie: session=abc; Domain=redirect.example.com; SameSite=Lax

  • Cookie is scoped to redirect.example.com only
  • Cannot be sent to target.example.com even with SameSite=Lax

• ✅ Will work: Set-Cookie: session=abc; Domain=example.com; SameSite=Lax

  • Cookie is scoped to example.com and all subdomains
  • Can be sent to both redirect.example.com and target.example.com if they are subdomains

Important: The browser checks both the Domain attribute AND the SameSite policy. Both must allow the cookie to be sent. [^2]

Sequence Diagram - SameSite=Lax:

Sequence Diagram - SameSite=Strict:

SameSite=Lax Nuances with Redirects

While SameSite=Lax cookies are generally sent with top-level navigation redirects, there are important subtleties:

What Works:

• ✅ User-initiated top-level navigation (clicking a link, typing URL)
• ✅ Same-site redirects (e.g., example.com → www.example.com)
• ✅ Cross-site redirects when initiated by user navigation

Browser Behavior Variations:

1. Redirect Chains: In a chain of redirects (A → B → C), browsers may treat intermediate redirects differently:

   • First redirect (A → B): Cookie may be sent if it's a top-level navigation
   • Subsequent redirects (B → C): Behavior varies by browser and how the redirect chain is tracked
   • Some browsers treat the entire chain as a single navigation context
   • Others may evaluate each redirect separately

2. Cross-Site → Same-Site Chains: A redirect chain that goes from cross-site to same-site may have different behavior:

   • Example: external.com → redirect.example.com → target.example.com
   • Browsers may apply stricter checks to prevent cross-site cookie leakage
   • The cookie's domain must match throughout the chain

3. POST Redirects: POST requests that result in redirects behave differently:

   • POST → 302 redirect is treated as a GET request (per HTTP spec) [^3]
   • Some browsers may not send SameSite=Lax cookies on POST-initiated redirects [^4]
   • This is a historical quirk and varies by browser implementation

Browser-Specific Considerations:

• Chrome/Edge: Generally sends SameSite=Lax cookies with top-level navigation redirects
• Firefox: Similar behavior, but may have edge cases with redirect chains
• Safari: Can be more restrictive, especially with redirect chains
• Older browsers: May not fully implement SameSite=Lax behavior correctly

POST Redirects and Cookie Behavior

POST requests that result in redirects have special considerations:

Flow:

1. User submits form via POST to redirect.example.com
2. Server responds with 302 redirect to target.example.com
3. Browser converts POST to GET (per HTTP spec) and follows redirect [^3]

Cookie Behavior:

• SameSite=Strict: ❌ NOT sent (cross-site redirect)
• SameSite=Lax: ⚠️ May or may not be sent depending on browser:
  • Some browsers treat POST-initiated redirects differently than GET-initiated redirects
  • The redirect may not be considered "top-level navigation" in the same way
  • Behavior varies between browsers and browser versions
• SameSite=None; Secure: ✅ Sent (if domain allows)

Recommendation: For POST redirects, rely on SameSite=None; Secure for cross-site scenarios, or use server-side session management to transfer state.

Redirect Chains and Corner Cases

Redirect chains (multiple redirects in sequence) introduce additional complexity:

Scenario: A → B → C Redirect Chain

1. User visits site-a.com
2. Cookie set: Set-Cookie: session=abc; Domain=site-a.com; SameSite=Lax
3. site-a.com redirects to site-b.com
4. site-b.com redirects to site-c.com

Cookie Behavior:

• First redirect (A → B):

  • Cookie may be sent if Domain attribute allows site-b.com
  • If Domain=site-a.com, cookie won't be sent to site-b.com

• Second redirect (B → C):

  • Browser behavior varies:
    • Some browsers treat the chain as a single navigation context
    • Others evaluate each redirect independently
    • Cookie from site-a.com may or may not be sent to site-c.com depending on domain matching

Cross-Site → Same-Site Chains:

When a redirect chain spans from cross-site to same-site (e.g., external.com → redirect.example.com → target.example.com), browsers apply additional checks:

• Cookies from external.com typically won't be sent to target.example.com (different domains)
• Cookies set on redirect.example.com with Domain=example.com may be sent to target.example.com if they're subdomains
• Browsers may be more restrictive to prevent cross-site cookie leakage

Recommendation: Avoid relying on cookies surviving long redirect chains. Use server-side session management or URL parameters (with appropriate security measures) for state transfer.

DNS Redirection and Aliasing

DNS redirection/aliasing is fundamentally different from HTTP redirects. Instead of the server sending a redirect response, multiple domain names resolve to the same IP address or server through DNS configuration (CNAME records, A record aliases, etc.).

Key Differences from HTTP Redirects

HTTP Redirects:

• Browser sees a redirect response (301/302)
• Browser makes a new request to the target URL
• SameSite policy applies to the redirect flow
• Browser tracks redirect chains

DNS Aliasing:

• Browser sees it as a direct request to that domain
• No redirect response - DNS resolution is transparent
• Browser treats each domain as completely separate
• Each domain has its own cookie jar (unless parent domain is used)

Cookie Behavior with DNS Aliases

When multiple domains resolve to the same server via DNS:

1. Separate Cookie Jars: Each domain maintains its own cookie storage

   • alias1.example.com and alias2.example.com have separate cookies
   • Cookie set on alias1 is NOT accessible from alias2

2. No Cross-Domain Cookie Access: Unless parent domain is used

   • Cookie with Domain=alias1.example.com only works on alias1
   • Cookie with Domain=alias2.example.com only works on alias2
   • Cookie with Domain=example.com works on both aliases

3. SameSite Policy: Applies to actual navigation, not DNS resolution

   • Navigation from alias1 to alias2 is cross-site
   • SameSite=Strict blocks cookie sending
   • SameSite=Lax allows top-level navigation

Scenario: DNS Aliased Domains

Flow:

1. DNS configured: alias1.example.com → 192.0.2.1
2. DNS configured: alias2.example.com → 192.0.2.1 (same server)
3. User visits alias1.example.com
4. Server sets cookie: Set-Cookie: session=abc; Domain=alias1.example.com
5. User navigates to alias2.example.com
6. Cookie is NOT sent (different domain)

Sequence Diagram:

Using Parent Domain for Shared Cookies

To share cookies across DNS-aliased domains, use the parent domain:

Configuration:

• alias1.example.com → 192.0.2.1
• alias2.example.com → 192.0.2.1
• Set cookie with: Domain=example.com

Sequence Diagram - Parent Domain Cookie:

Common DNS Aliasing Scenarios

Scenario 1: Multiple Subdomains

• www.example.com → 192.0.2.1
• app.example.com → 192.0.2.1
• Solution: Use Domain=example.com to share cookies

Scenario 2: International Domains

• example.com → 192.0.2.1
• example.co.uk → 192.0.2.1
• Challenge: Cannot share cookies (different TLD)
• Solution: Set cookies separately or use server-side session storage

Scenario 3: Branding Aliases

• brand1.com → 192.0.2.1
• brand2.com → 192.0.2.1
• Challenge: Cannot share cookies (completely different domains)
• Solution: Use OAuth or server-side session management

Differences from HTTP Redirects

Testing DNS Aliasing

When testing DNS aliases in the playground or any environment:

1. Verify DNS Resolution:

   dig alias1.example.com
   dig alias2.example.com
   # Both should resolve to same IP

2. Check Cookie Isolation:

   • Set cookie on alias1
   • Navigate to alias2
   • Verify cookie is NOT accessible

3. Test Parent Domain Cookie:

   • Set cookie with Domain=example.com
   • Navigate between alias1 and alias2
   • Verify cookie IS accessible on both

4. Inspect in DevTools:

   • Network tab: Check Host header (shows actual domain)
   • Application tab: Check cookies per domain
   • No redirect entries (unlike HTTP redirects)

Important Notes

• DNS aliasing is transparent: Browser doesn't know domains share the same server
• SameSite applies to navigation: Navigating from one alias to another is cross-site
• Parent domain required: To share cookies, domains must be subdomains of the same parent
• No redirect chain: DNS resolution happens before HTTP request
• Server-side session: If cookies can't be shared, use server-side session storage

Testing in the Playground

Setup

1. Redirect Domain: site-c.cookie-playground.pun7o.click

   • All requests return 301 redirect
   • Redirects to: site-a.cookie-playground.pun7o.click

2. Target Domain: site-a.cookie-playground.pun7o.click

   • Receives redirected requests
   • Has redirect test page: /redirect-test.html

Test Procedures

Test 1: Basic Redirect Cookie Flow

1. Visit https://site-c.cookie-playground.pun7o.click
2. Observe 301 redirect in browser DevTools
3. Check cookies on target domain
4. Verify redirect preserves query parameters

Test 2: Cookie Set Before Redirect

1. Set cookie on redirect domain (if possible via JavaScript before redirect)
2. Follow redirect
3. Check if cookie persists on target domain

Test 3: Cookie Set After Redirect

1. Follow redirect to target domain
2. Set cookie on target domain
3. Verify cookie is stored correctly

Test 4: Programmatic Redirect Following

1. Use JavaScript fetch with redirect: 'manual'
2. Inspect redirect response headers
3. Manually follow Location header
4. Observe cookie behavior

HTTP Status Codes

301 Moved Permanently

HTTP/1.1 301 Moved Permanently
Location: https://target.example.com/path

302 Found (Temporary)

HTTP/1.1 302 Found
Location: https://target.example.com/path

Important Considerations

Browser Caching

• 301 redirects may be cached by browser
• Subsequent requests may skip redirect entirely
• Clear browser cache to retest

Cookie Domain Mismatch

Critical Understanding: A cookie set on redirect.example.com will NOT automatically be accessible on target.example.com after a redirect, even if SameSite=Lax allows the redirect. The Domain attribute must explicitly allow the target domain.

Examples:

• ❌ Won't work:

  Set-Cookie: session=abc; Domain=redirect.example.com; SameSite=Lax

  • Cookie scoped to redirect.example.com only
  • Cannot be sent to target.example.com regardless of SameSite policy

• ✅ Will work (if both are subdomains):

  Set-Cookie: session=abc; Domain=example.com; SameSite=Lax

  • Cookie scoped to example.com and all subdomains
  • Can be sent to both redirect.example.com and target.example.com

Important: Many browsers treat initial navigations with certain flags differently. The Domain attribute is checked before the SameSite policy. Both must allow the cookie to be sent. [^2]

SameSite Policy Impact

• SameSite=Strict: Not sent with cross-site redirects [^1]
• SameSite=Lax: Sent with top-level navigation redirects (with browser-specific nuances - see "SameSite=Lax Nuances" section above) [^1]
• SameSite=None: Sent with all redirects (requires Secure flag and HTTPS) [^1]

Important: The SameSite policy is evaluated after the Domain attribute check. If the domain doesn't match, the cookie won't be sent regardless of SameSite policy. [^2]

Path Matching

• Cookie path must match or be parent of redirect path [^2]
• / path works for all paths
• /api path only works for /api/*

Browser Exceptions and Historical Quirks

Browser Version Differences

Older Browser Versions:

• Browsers released before 2019 may not fully support SameSite cookie attributes
• Default behavior was often SameSite=None (sent with all requests)
• SameSite=Lax may not be respected in older browsers
• Testing in multiple browser versions is recommended

Modern Browser Defaults:

• Chrome 80+ (2020): Defaults to SameSite=Lax if not specified [^5]
• Firefox 69+ (2019): Supports SameSite but defaults vary [^6]
• Safari 13+ (2019): Supports SameSite with stricter default behavior [^7]
• Edge 80+ (2020): Follows Chromium behavior [^5]

SameSite=None; Secure Requirement

For cross-site cookies to work with redirects, they must include both:

• SameSite=None (allows cross-site sending)
• Secure flag (required when SameSite=None, must be HTTPS)

Example:

Set-Cookie: session=abc; Domain=example.com; SameSite=None; Secure

Why: This requirement prevents insecure cross-site cookie transmission and protects against man-in-the-middle attacks. [^1]

HTTP Working Group Issue #889

The HTTP working group has documented divergences in how browsers treat SameSite=Strict and SameSite=Lax cookies after cross-site redirects. [^4] Key points:

• Specification Ambiguity: The cookie specification doesn't fully define behavior for all redirect scenarios
• Browser Divergences: Different browsers may handle redirect chains differently
• POST Redirects: Particularly problematic - browsers vary in how they treat POST-initiated redirects with SameSite cookies

Recommendation: Don't rely on cookies surviving cross-site redirect chains. Use explicit domain matching and consider server-side session management for critical state.

Browser-Specific Behaviors

Chrome/Edge (Chromium):

• Generally permissive with SameSite=Lax on top-level navigation redirects
• May cache redirects more aggressively (301 redirects)
• Treats redirect chains as single navigation context in many cases

Firefox:

• Similar to Chrome but may be more restrictive with redirect chains
• May evaluate each redirect in a chain separately
• Can be more strict about POST redirects

Safari:

• Often more restrictive than Chromium browsers
• May block cookies more aggressively in redirect scenarios
• Particularly strict with cross-site redirect chains
• Has additional privacy protections (ITP - Intelligent Tracking Prevention) [^8]

Testing Recommendation: Always test redirect cookie behavior in your target browsers, especially Safari if you have Mac/iOS users.

Browser Behavior Comparison Table

Legend:

• ✅ Reliably works
• ⚠️ May work but behavior varies or has edge cases
• ❌ Does not work

Common Use Cases

URL Shortening

• Short URL redirects to long URL
• May need to preserve session cookies
• Use parent domain cookies

Domain Migration

• Old domain redirects to new domain
• Cookies may need to be migrated
• Set cookies on both domains during transition

CDN Redirects

• CDN subdomain redirects to main domain
• Cookies should work across redirect
• Ensure Domain attribute is set correctly

Troubleshooting

Cookie Not Sent After Redirect

Possible Causes:

1. Domain mismatch: Cookie Domain attribute doesn't allow target domain (use parent domain cookie)
2. SameSite policy too restrictive: Policy blocks cross-site redirects
3. Secure flag missing: Required for SameSite=None, must use HTTPS
4. Path mismatch: Cookie path doesn't match redirect path
5. Browser version: Older browsers may not support SameSite correctly
6. POST redirect: May not work with SameSite=Lax, consider SameSite=None; Secure or server-side session

Solutions:

1. Domain mismatch: Set Domain to parent domain that encompasses both redirect and target domains

   • Example: Use Domain=example.com for redirect.example.com → target.example.com

2. SameSite policy: Use SameSite=Lax for top-level navigation redirects or SameSite=None; Secure for cross-site scenarios

3. Secure flag: Ensure Secure flag is set when using SameSite=None (requires HTTPS)

4. Path matching: Set cookie path to / to match all paths, or ensure path matches redirect path

5. Browser compatibility: Test in target browsers, especially Safari for Mac/iOS users

6. POST redirects: Use SameSite=None; Secure for POST-initiated redirects or server-side session management

Cookie Lost After Redirect

Possible Causes:

1. Domain attribute not set
2. Cookie expired
3. Browser privacy settings

Solutions:

• Explicitly set Domain attribute
• Check cookie expiration
• Test in different browsers

Testing Checklist

• 301 redirect works correctly
• Cookies set before redirect are sent
• Cookies set after redirect are stored
• Query parameters preserved
• SameSite policy respected
• Secure flag works on HTTPS
• Parent domain cookies work across redirect
• HTTP inspector shows correct headers

Related Topics

• Domain Migration for Tracker Mergers - Strategies for migrating tracking domains
• Cookie Attributes - Understanding SameSite and Secure
• Cross-Domain Behavior - Cross-domain scenarios
• HTTP Headers - Set-Cookie and Cookie headers

Additional Resources

• Browser Developer Tools Documentation - Chrome DevTools guide
• HTTP State Management Mechanism (RFC 6265) - Cookie specification
• MDN Web Docs on HTTP Cookies - Comprehensive cookie documentation
• HTTP Working Group Issue #889 - SameSite cookie behavior with redirects discussion
• SameSite Cookies Explained - Detailed SameSite behavior guide

Citations

[^1]: RFC 6265bis - HTTP State Management Mechanism . Defines SameSite cookie attribute behavior, including that SameSite=None requires the Secure flag, and specifies when cookies are sent with redirects.

[^2]: RFC 6265 - HTTP State Management Mechanism . Section 5.1.3 defines domain matching rules, and Section 5.2 specifies that domain matching is evaluated before other cookie attributes.

[^3]: RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content . Section 6.4.3 specifies that 302 redirects change POST requests to GET requests.

[^4]: HTTP Working Group Issue #889 . Documents browser divergences in handling SameSite cookies with redirects, particularly POST-initiated redirects.

[^5]: Chrome SameSite Cookie Changes . Chrome 80+ defaults to SameSite=Lax for cookies without an explicit SameSite attribute.

[^6]: Firefox SameSite Cookie Support . Firefox 69+ supports SameSite cookies with varying default behaviors.

[^7]: Safari Intelligent Tracking Prevention . Safari 13+ implements stricter SameSite defaults and additional privacy protections.

[^8]: Safari ITP Documentation . Safari's Intelligent Tracking Prevention includes additional restrictions on cross-site cookie behavior beyond standard SameSite policies.

Next Steps

• Test redirect scenarios in the playground
• Review Browser Behaviors for browser-specific differences