Firefox Total Cookie Protection can break embedded logins—here's how to diagnose it

A login widget that works everywhere except Firefox

Open a relying-party site in Firefox with Enhanced Tracking Protection set to Strict, click “Sign in with” a third-party provider, and the popup may close without returning a session. The same flow may work in browsers with looser defaults. The problem is usually not a bug in your identity provider; it is Firefox’s Total Cookie Protection keeping cookies in separate jars by top-level site.

What Total Cookie Protection partitions

Total Cookie Protection gives each top-level site its own cookie jar. A cookie set by example.com while you are on example.com is available only in example.com’s jar. If example.com loads an iframe or redirect from idp.example.net, that third-party context cannot read or write idp.example.net’s cookies unless Firefox grants an exception. This blocks many cross-site tracking techniques, but it also blocks legitimate state that SSO, payment redirects, and embedded widgets depend on.

Firefox offers three modes: Standard, Strict, and Custom. Strict blocks more third-party trackers and applies cookie partitioning more aggressively. Behavior can differ between release channels and between desktop Firefox and Firefox for Android or iOS, so desktop results do not transfer directly to mobile.

Worked example: diagnose a broken embedded login

You can verify whether partitioning is the cause without changing Firefox settings.

1. Open Firefox and go to about:preferences#privacy. Confirm Enhanced Tracking Protection is set to Strict.
2. Open the site with the broken login flow.
3. Press F12 (or Ctrl+Shift+I) to open Developer Tools, then open the Storage inspector.
4. Expand Cookies and select the top-level site. Look for cookies from the embedded identity provider or payment domain. If they are absent while the same domains show cookies in another browser, partitioning is the likely cause.
5. In the Network panel, reload the page and attempt the login. Look for requests to the third-party domain that are canceled or return 403 or 401, especially when the request includes no cookies.

To test whether an exception restores the flow, click the shield icon in the address bar, then turn off Enhanced Tracking Protection for that site only. Reload and repeat the login. If it works, the breakage was ETP-related. This exception is user-controlled; developers cannot set it for visitors. Turn protection back on after testing.

What developers can do instead of asking users to disable protection

• Use the Storage Access API or related standards-based mechanisms when an embedded iframe needs cookie access after user interaction.
• Avoid relying on third-party cookies for core navigation. Prefer same-site session cookies and explicit redirect parameters for state.
• Test login and payment flows in Firefox Strict mode before release, not just in browsers with looser defaults.
• Document the Firefox exception path in support articles so users can add your domain if a flow still breaks.

Trade-offs and limitations

Per-site cookie jars increase storage and memory overhead compared with a single shared jar. Firefox may also produce false positives: a site not on a tracking blocklist can still break if it depends on cross-site state. Because ETP mode and Total Cookie Protection availability depend on platform and version, a flow that works on Firefox desktop may behave differently on Firefox for Android.

Check the result before you ship

Open Firefox preferences, confirm Strict mode is active, and complete the full login or payment journey in a private window. Then repeat with Enhanced Tracking Protection disabled for that site. If both paths succeed, your flow is compatible with Firefox’s default privacy posture. If only the exception path works, review your iframe and redirect cookie usage.