Safari ITP Limits Script-Set Third-Party Cookies to Seven Days

The embedded widget that forgets users after a week

You embed a support chat or payment widget inside an iframe on a partner's page. The widget stores a session token with document.cookie so returning visitors do not have to sign in again. It works reliably in Chrome and Firefox. In Safari, the token can disappear after about seven days, even though the user never logged out.

The cause is Safari's Intelligent Tracking Prevention (ITP). ITP partitions cookies by top-level site and places a seven-day cap on writable cookies that JavaScript sets from a third-party context. Because both macOS Safari and iOS Safari use WebKit, the same limit appears across Apple devices.

What changes under ITP

Partitioning means Safari stores cookies separately for each top-level site, so a cookie set by widget.example.com inside merchant.example.com is not the same cookie store as when the user visits widget.example.com directly. Third-party context means the iframe's origin does not match the page's top-level origin.

Cookies set through document.cookie inside that iframe are treated as client-side, script-set cookies. Safari can expire them after seven days of Safari inactivity and keep them siloed under the embedding site. Cookies issued by your server through the Set-Cookie header are not subject to the same script-set cap, though they can still be partitioned and SameSite=None requires Secure.

Workaround: issue session cookies from your server

Move session state out of the iframe's JavaScript and into an HTTP response from your own domain. When the widget initializes, have it request a token from https://widget.example.com/session and set the cookie with Set-Cookie rather than document.cookie.

Set-Cookie: widget_session=abc123def456; Path=/; SameSite=None; Secure; HttpOnly

Run this on your origin server, not in the browser. You need deploy or server-configuration permissions. Replace widget.example.com with your actual host. The Secure attribute requires HTTPS; SameSite=None tells browsers to send the cookie cross-site, but Safari may still partition it under the top-level site.

Workaround: re-authenticate through a top-level window

When Safari blocks third-party access to storage, an iframe cannot silently renew a session. The dependable fallback is a top-level redirect: send the user to https://widget.example.com/auth, complete sign-in there, then return to the merchant page. This gives Safari a direct user interaction with your domain and refreshes the session cookie outside the restricted iframe context.

Worked example: diagnose the cap in Safari Web Inspector

Do not rely on Chrome or Firefox for this test; they do not reproduce WebKit partitioning. Verify on Safari directly.

1. Open Safari and enable the Develop menu: Safari > Settings > Advanced > Show features for web developers.
2. Open a page that embeds your iframe from a different top-level site, such as https://merchant.example.com/page.
3. Open Web Inspector (Option + Command + I), select the iframe, and open the Storage > Cookies tab.
4. In the iframe console, run:

document.cookie = "widget_session=diagnostic; path=/; max-age=31536000";

1. Inspect the cookie row. Check whether it is stored under the top-level site's partition, what expiry Safari assigns, and whether it disappears after seven days of Safari inactivity.
2. Repeat the same flow on iOS Safari to confirm consistent behavior.

Expected checks: the cookie should appear under the embedding site's partition rather than the widget's origin, and its lifetime should not be trusted beyond the ITP window. Risks: users can clear website data at any time, and Safari may block the write entirely if all cookies are blocked.

Limitations

• ITP heuristics change between Safari versions. Do not hardcode a seven-day expiry in application logic.
• SameSite=None; Secure cookies may still be partitioned by Safari.
• Client-side storage is never durable; users can clear it manually.
• Review WebKit release notes and Safari Technology Preview notes before relying on specific behavior.

Action

Audit every embedded widget that uses document.cookie for session state. Move issuance to your server's Set-Cookie response, add a top-level sign-in path for Safari, and test the flow on macOS Safari and iOS Safari before shipping.