About the SameSite Cookie Issue
Background
Because of GDPR regulations, major browsers have been restricting third-party sites from writing cookies in order to prevent ad tracking on users. Our product is often embedded by customers (via iframe) inside their own websites, so we ran into this restriction.
Problems We've Hit
-
After a Windows update, IIS changed the default cookie mode from strict to Lax. (The product team later used URL Rewrite to override the response header value based on different user agents.)
-
After one Safari update, third-party sites were blocked from writing cookies. (After validating feasibility through a PoC, we discussed it with the product department and ended up adopting Apple's Storage Access API.)
Solutions
Short-term
- Redirect the page to the product vendor's site.
- Adopt Apple's Storage Access API. Platform side: the iframe sandbox needs allow-same-origin and allow-storage-access-by-user-activation. Product side: the page that sets the cookie needs a button so the user can confirm and trigger the Storage Access API.
Mid- to long-term (product side)
- Switch to token-based authentication (the product side stops using cookies).
- Remove sticky cookies (need to think about how logs will be tracked afterwards).
- Remove cookie data.
Notes
- The SameSite bug on iOS 13 On versions before iPhone 13 there was a bug where any value set on SameSite was treated as Lax. You can't set SameSite=none, so you have to set SameSite="".
- Storage Access API support The new Edge and Chrome already support the Storage Access API and it's currently in beta. It's likely more browsers will follow in the future.





























Comments