{"id":8501,"date":"2026-08-12T06:02:00","date_gmt":"2026-08-12T04:02:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8501"},"modified":"2026-10-24T03:17:09","modified_gmt":"2026-10-24T01:17:09","slug":"first-party-cookie-restoration-surviving-itp-with-cloudflare-workers","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/first-party-cookie-restoration-surviving-itp-with-cloudflare-workers\/","title":{"rendered":"Server-Set Cookies with Cloudflare and ssGTM: Consent and ITP Limits"},"content":{"rendered":"

A Cloudflare Worker can set cookies through HTTP responses and forward measurement requests to a server container. This provides control over data paths and cookie attributes. It does not guarantee a bypass of Safari’s Intelligent Tracking Prevention (ITP), a fixed retention period or legal compliance.<\/p>\n

What ITP actually limits<\/h2>\n

WebKit describes deletion of script-writable storage after seven days of Safari use without interaction with the website. This counts Safari usage days, not simply seven calendar days. Detected link decoration can impose a 24-hour limit on cookies created by JavaScript on the landing page. Not every URL parameter meets those detection conditions.<\/p>\n

HTTP cookies can also fall under a seven-day cap when WebKit detects third-party CNAME or IP cloaking. The specific relationship to the main page matters; CDN use alone is not the criterion. IP detection is heuristic and can change. A matching hostname or consent does not grant an exception from browser rules.<\/p>\n

Max-Age<\/code> specifies a requested lifetime. Browser limits, private sessions, cleanup and manual deletion can shorten actual storage. If a missing identifier causes the server to generate a new UUID, that creates a new identifier rather than restoring the previous identity.<\/p>\n

\"Permission,
Permission, scoped cookies, explicit destination mapping and withdrawal; storage duration remains browser-controlled.<\/figcaption><\/figure>\n

Cookie attributes without false guarantees<\/h2>\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nEffect and limit<\/th>\n<\/tr>\n<\/thead>\n
HttpOnly<\/code><\/td>\nBlocks direct JavaScript access to the cookie value. XSS can still perform actions in the page context; there is no ITP immunity.<\/td>\n<\/tr>\n
Secure<\/code><\/td>\nRestricts cookie transmission to secure connections. The Worker-to-backend connection also needs suitable transport configuration.<\/td>\n<\/tr>\n
SameSite=Lax<\/code><\/td>\nControls sending on cross-site requests. It does not turn a vendor into the website’s own organization.<\/td>\n<\/tr>\n
No Domain<\/code><\/td>\nCreates a host-only cookie. A Domain attribute expands scope to matching subdomains and does not prevent CNAME detection.<\/td>\n<\/tr>\n
Path=\/<\/code><\/td>\nCovers all paths on the matching host; a cookie path is not a reliable security boundary.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

An explicit cookie lifecycle<\/h2>\n

For an analytics identifier requiring consent, permission must be checked before creation and the associated processing. A freely supplied request parameter containing \u201cgranted\u201d is not reliable evidence of consent. The actual CMP integration needs to account for the current choice, purpose and withdrawal.<\/p>\n

    \n
  1. A dedicated endpoint accepts only its intended request type and verified origin; state changes require suitable protection against externally induced calls.<\/li>\n
  2. Without valid permission, no new analytics identifier is created. Withdrawal deletes the existing cookie with matching scope and stops further use.<\/li>\n
  3. With permission, an existing valid value can be reused. A missing value leads to a fresh random identifier only when creation is allowed.<\/li>\n
  4. The personalized response explicitly disables caching. Shared page caches must not reuse identifiers from visitor-specific responses.<\/li>\n
  5. The server client and every destination tag need a documented mapping covering consent, missing identifiers and withdrawal.<\/li>\n<\/ol>\n

    The following headers describe a new host-only cookie with an illustrative 30-day lifetime. The placeholder requires replacement with a securely generated random value. The example contains no CMP verification, endpoint or proxy implementation and is not a deployable Worker.<\/p>\n

    Cache-Control: private, no-store\nSet-Cookie: __Host-fp_id=RANDOM_IDENTIFIER; Max-Age=2592000; Path=\/; Secure; HttpOnly; SameSite=Lax<\/code><\/pre>\n
    In supporting browsers, the __Host-<\/code> prefix requires Secure<\/code>, Path=\/<\/code> and no Domain<\/code>. Withdrawal on the same host uses:<\/p>\n
    Cache-Control: private, no-store\nSet-Cookie: __Host-fp_id=; Max-Age=0; Path=\/; Secure; HttpOnly; SameSite=Lax<\/code><\/pre>\n
    Existing cookies with different names, domains or paths require their own matching deletions. The next request after withdrawal must not immediately create another identifier. Actual browser storage and outgoing requests provide stronger evidence than the deletion header alone.<\/p>\n
    The first request does not contain the new cookie<\/h2>\n
    With forwarding through fetch(request)<\/code>, the backend request is already underway before an added Set-Cookie<\/code> response reaches the browser. A newly set response cookie therefore does not retroactively appear in the first backend request. The integration must explicitly handle that sequence rather than assume automatic mapping.<\/p>\n
    A custom fp_id<\/code> or __Host-fp_id<\/code> is also not automatically a GA4 or Google Ads client ID. The responsible server client, destination schemas and effects on user and session counts need verification. A parallel identifier can change the existing identity model.<\/p>\n
    Google Tag Gateway is a separate component<\/h2>\n
    Google Tag Gateway (GTG) serves Google scripts and measurement requests through configured paths on first-party web infrastructure. Cloudflare provides a dedicated integration; a custom cookie Worker is neither a prerequisite nor automatically part of that integration.<\/p>\n
    GTG and an ssGTM container perform different jobs. A matching origin can allow connection reuse, but does not guarantee exactly the same IP across all requests or a particular latency. Forwarding and processing remain additional work. Google states that GTG processes Google first-party cookies and drops other forwarded first-party cookies. Enabling GTG alone therefore does not make a custom identifier available.<\/p>\n
    Handling an existing _ga cookie<\/h2>\n
    Separate HTTP renewal of _ga<\/code> requires verified coordination with the Google tag. The script must access this cookie, so HttpOnly<\/code> is unsuitable for an ordinary script-read _ga<\/code> configuration. Name, domain and path must match the existing cookie; otherwise multiple cookies can appear instead of a renewal.<\/p>\n
    cookie_domain: 'auto'<\/code> and cookie_update<\/code> affect Google tag behavior. cookie_update: false<\/code> prevents ongoing tag-side renewal, but provides no ITP exception. Additional renewal must not override an earlier decision or deliberate deletion. Google’s documented default lifetime is also not a guaranteed browser lifetime.<\/p>\n
    Questions and answers<\/h2>\n
    Does a cookie automatically break Cloudflare caching?<\/h3>\n
    No. The documented default cache key does not include all cookie values. Custom cache keys and bypass rules can consider cookies, while Set-Cookie<\/code> responses separately affect cacheability. Ignoring a cookie is appropriate only when content and access rights are demonstrably independent of that cookie.<\/p>\n
    Does a cache MISS establish a cookie problem?<\/h3>\n
    No. Empty or expired caches, cache rules and response headers also matter. Repeated requests and the effective configuration need assessment together.<\/p>\n
    Does a Cookie request header reveal the expiry date?<\/h3>\n
    No. It contains names and values, not the original attributes such as Max-Age. A renewal window needs a separately defined timing mechanism; an existence check is insufficient.<\/p>\n
    What needs testing before deployment?<\/h3>\n
    Acceptance, rejection, withdrawal, subsequent requests, the first request without an identifier, parallel requests, cookie scope and cache isolation belong in browser and integration tests. Tests need the actual Safari and Chrome versions and the concrete GTG\/ssGTM setup. No universal lifetime or compliance guarantee follows.<\/p>\n
    Sources<\/h2>\n