Why Safari Caps JavaScript Cookies to Seven Days

Apple’s Safari browser limits the lifespan of client-side cookies created through JavaScript's document.cookie API to a maximum of seven days. This restriction is a core component of WebKit's Intelligent Tracking Prevention (ITP) feature, designed to protect user privacy. This article explains why Apple implemented this seven-day cap, how it prevents third-party scripts from exploiting first-party storage for long-term user tracking, its secondary security benefits, and how developers can legitimately maintain longer user sessions using server-side cookies.

Stopping the First-Party Tracking Loophole

Historically, cross-site tracking relied on third-party cookies. When Safari blocked third-party cookies by default, tracking companies adapted. They began providing website owners with JavaScript snippets to embed directly onto their pages.

Because these scripts run directly on the host website, any cookie they create via document.cookie is technically considered a "first-party" cookie. Trackers used this method to generate unique user IDs that expired years into the future. By pairing these long-lived first-party cookies with URL link decoration (passing tracking IDs in the URL parameters when a user clicks a link), ad networks could still track users across different websites.

By capping document.cookie lifespans to seven days, Safari drastically reduces the effectiveness of this tracking method. If a user does not revisit a specific website within a week, the tracker's cookie expires, erasing the user's long-term behavioral profile on that site.

In addition to the standard seven-day cap, Safari enforces an even stricter 24-hour expiration limit on document.cookie under specific conditions. If a user navigates to a website from a domain classified by ITP as a known tracker, and the URL contains query parameters or fragments (often used to pass tracking IDs), any client-side cookie created on the destination site is capped at just one day. This directly neutralizes cross-site tracking via URL parameters.

Mitigating Cross-Site Scripting (XSS) Risks

Beyond privacy, limiting the usefulness of document.cookie improves web security. Cookies created or read via JavaScript are inherently vulnerable to Cross-Site Scripting (XSS) attacks. If a malicious actor injects a script into a website, that script can read document.cookie and steal sensitive session tokens or user data.

By discouraging the use of JavaScript-accessible cookies for long-term storage, Apple nudges developers toward safer authentication and storage practices.

How Developers Can Persist Sessions Longer

Safari's seven-day cap only applies to cookies created on the client side via JavaScript. It does not apply to standard first-party cookies set by a web server.

To maintain user sessions, preferences, or authentication states for longer than seven days, developers must set cookies via HTTP response headers (Set-Cookie) from a first-party server. For these cookies to bypass the seven-day limit, they must meet the following criteria:

  • Set via HTTP Header: They must be delivered by the server, not generated in the browser via document.cookie.
  • Same-Site Origin: The server setting the cookie must share the same registrable domain as the website the user is visiting.
  • No CNAME Cloaking: The server cannot use DNS CNAME records to disguise a third-party tracking server as a first-party subdomain (Safari detects this and applies the seven-day cap anyway).

For maximum security, server-set cookies should also include the HttpOnly flag, which completely blocks JavaScript from accessing the cookie, and the Secure flag, which ensures the cookie is only transmitted over encrypted HTTPS connections.