Quote from luishp on September 4, 2025, 8:03 am

@edward-rose-iii

Short answer: it’s almost never the <iframe> itself—it's the cookie context.

Modern browsers treat an iframe as a separate browsing context, and your PHP session (usually the PHPSESSID cookie) will be blocked or isolated unless everything lines up. The most common culprits:

1. Third-party context (cross-site):
   If the iframe’s origin (scheme+host+port) is different from the top page, the cookie is “third-party.”

• With today’s defaults, third-party cookies are blocked (Safari/Firefox for years; Chrome is actively phasing them out).

• To allow a session cookie inside a cross-site iframe you must set:

  • SameSite=None; Secure (and serve over HTTPS).

  • In PHP 7.3+, do e.g.:

  • session_set_cookie_params([
      'lifetime' => 0,
      'path'     => '/',
      'domain'   => 'iframe-domain.example', // or a parent domain if truly same-site
      'secure'   => true,
      'httponly' => true,
      'samesite' => 'None',
    ]);
    session_start();

    If you can, consider partitioned cookies (CHIPS): Set-Cookie: __Host-yourcookie=...; Secure; Path=/; SameSite=None; Partitioned (framework support varies). This lets a third-party iframe keep a cookie, but siloed per top site.

2. Same-site but different subdomain / scheme:
   Sessions won’t “stick” if you switch between http:// and https://, or between app.example.com and www.example.com, unless your cookie’s domain and path are set correctly and you stay on HTTPS if Secure is set. Keep scheme, host, and path consistent.

3. Iframe is sandboxed:
   If you use sandbox on the iframe without allow-same-origin, the iframe becomes a unique origin and cannot see or set cookies. Remove sandbox or add allow-same-origin (and any other needed flags).

4. Default SameSite behavior biting you:
   Many stacks now default cookies to SameSite=Lax. In an iframe that’s effectively cross-site, that means no cookie. Explicitly set SameSite=None; Secure for any cookie you need inside the iframe.

5. Set-Cookie is not accepted:
   Open DevTools → Network on the iframe requests and check the response headers. If Set-Cookie is there but greyed/ignored, the browser will show why (e.g., “Blocked: third-party cookie”, “Not Secure”, “SameSite”). Fix per the message.

6. File / blob / data URLs:
   If the iframe loads file://, about:blank, blob: or data: URLs, you won’t get normal cookie behavior.

7. Backend/session issues:
   Less common, but if session.save_path is unwritable, or you regenerate IDs on every request, it looks like “the iframe lost the session.” Log the session_id() and confirm it’s stable across iframe navigations.

---

Quick diagnostics

• In the iframe’d page, temporarily log:

  session_start();
  echo 'SID=' . session_id() . PHP_EOL;
  var_dump($_COOKIE);

  Reload inside the iframe; confirm whether PHPSESSID is present and whether it changes between requests

• In DevTools → Application → Cookies, watch whether the cookie for the iframe’s origin exists, and if it’s marked as Blocked.

---

Minimal working recipe (cross-site iframe)

1. Serve the iframe content over HTTPS.

2. Before session_start():

   ini_set('session.cookie_secure', '1');
   ini_set('session.cookie_samesite', 'None'); // PHP 7.3+: or use session_set_cookie_params([...])
   session_start();

3. Ensure the <iframe> is not sandboxed (or includes allow-same-origin).

4. If you still hit blocks in Chrome’s latest, consider setting a partitioned cookie in addition to your session cookie (if your app logic allows) until your framework supports partitioned session cookies.

If your iframe and parent are truly same-origin and you still lose state, look at (a) sandbox, (b) switching between http/https, or (c) your code regenerating/destroying the session inadvertently.