EngineeringScoreAsk the tracking vendor to mark their cookies Secure
Some cookies that pass the first-party check by domain are still not the site's own to fix in code: an analytics or ads vendor's script wrote them via document.cookie while running on the site's pages, and only that vendor's own configuration controls the attributes it sets. Google Analytics' _ga, Microsoft Clarity's _clck, and Meta Pixel's _fbp are common examples. Each lives on the site's domain but is entirely managed by its vendor's snippet.
Why it matters
These cookies are written by third-party tracking scripts running on the site (Google Analytics, Google Ads, Microsoft Clarity, Meta Pixel, Microsoft Advertising, and similar), not by the site's own server. "Add Secure to the cookies the app sets" does not apply, because the app never sets them; the vendor's script does, and the vendor's own configuration controls the attributes it uses.
How to fix
- 1 Identify which vendor's tag sets each named cookie (Google Analytics/Ads: _ga, _ga_*, _gid, _gcl_*; Microsoft Clarity: _clck, _clsk; Meta Pixel: _fbp, _fbc; Microsoft Advertising/UET: _uetsid, _uetvid).
- 2 Set the Secure flag in that vendor's own snippet or dashboard: e.g. Google's gtag.js accepts cookie_flags: 'SameSite=None;Secure' in the config call or GTM tag settings; Microsoft Clarity exposes its cookie behaviour in the project's dashboard settings.
- 3 Re-run the scan after the vendor tag next fires (some vendors only apply a changed flag on the next page load) to confirm it actually changed.
Common mistakes
- Trying to set the Secure flag on these cookies from the site's own server or middleware: the vendor's client-side script re-sets the cookie on its own terms and will simply overwrite the change.
- Assuming a vendor cookie missing Secure means the whole vendor integration is insecure, when in most cases only that one configuration flag needs changing in the vendor console.
- Skipping the fix entirely on the assumption that nothing can be done about a third party's cookie, when the vendor's own dashboard or snippet usually exposes exactly this setting.
How to verify
- 1 Re-inspect the cookie in devtools after changing the vendor's configuration and confirm the Secure flag is now present on the next value the vendor's script writes.
- 2 Check the vendor documentation for the specific tag in use (gtag.js, Google Tag Manager, the Clarity snippet, etc.) to confirm where the cookie-attribute setting lives.
- 3 Re-run the scan after the vendor tag has fired at least once post-change, since some vendors only apply an updated flag on the next page load or session.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.