Limits on SameSite=None Cookies Missing the Secure Flag in Chrome 80 and Later

Answer

Yes. Chrome 80 and later rejects a Set-Cookie header that contains SameSite=None without Secure, and the rejection applies to responses that are returned by a Service Worker fetch handler just as it does for direct network requests. The Service Worker is a proxy; the browser’s cookie parser runs after the worker returns a Response and enforces the SameSite=None; Secure rule globally.

Confirmed facts

• Chrome 80 introduced mandatory Secure for SameSite=None. From Chrome 80 onward a cookie with SameSite=None and no Secure attribute is not stored in the cookie jar.
• Enforcement lives in the browser network stack, not in the main-thread fetch API. A response produced by serviceWorker.onfetch, including a cross-origin fetch, is processed by the same cookie parser.
• Rejected cookies do not appear in Application → Storage → Cookies for the relevant origin. DevTools surfaces the problem in the Issues tab with a message about SameSite=None requiring Secure. The Application pane will simply show the cookie absent; a warning badge may appear on the Cookies table in newer builds.
• Service Workers cannot set cookies via document.cookie. Cookie creation is only possible via Set-Cookie headers in a response. Modifying headers in the worker does not bypass the attribute check.

Likely explanation for conflicting reports

Developers who see a cookie appear despite missing Secure are usually observing a different code path: a cookie set by document.cookie in a page, a cookie with SameSite omitted which Chrome treats as Lax, or a test over an insecure origin where Chrome’s localhost exception or an older pre-80 build is in use. A Service Worker cannot make the browser store an invalid SameSite=None cookie.

Minimal verification for this case

1. Serve the site over HTTPS. Secure cookies cannot be set over plain HTTP in modern Chrome.
2. Register a Service Worker in scope for the page and intercept a fetch to a different origin that returns Set-Cookie: swtest=1; SameSite=None with no Secure.
3. Reload the page, trigger the intercepted fetch, then open DevTools → Application → Cookies for the response origin.
4. Check DevTools → Issues for a SameSite=None requires Secure warning and confirm the cookie is absent from the list.

Version note: Enforcement is consistent from Chrome 80 through 115 and the current stable. Chrome 80-84 had transitional messaging; Chrome 86+ removed legacy allowances. Behavior is stable across those ranges for network-delivered Set-Cookie.

One diagnostic detail that changes the recommendation: is the Set-Cookie header you are inspecting coming unchanged from the network origin, or is the Service Worker adding/modifying it via response.headers.set('Set-Cookie', ...)? If the worker is synthesizing the header, the worker must add Secure itself; the browser will still reject it if missing.