A third-party cookie is a cookie set by a domain other than the one a person is visiting. That third party can read the same cookie again on other sites that embed its content, which makes it useful for tracking across multiple domains. It is a core mechanism of cross-site profiling.
Expanded Definition
A third-party cookie is not just a browser storage object, it is a cross-site identifier that can be read when the same outside domain appears on multiple websites. In practice, that makes it a tracking primitive for profiling, attribution, ad measurement, and embedded service behavior. The term is often discussed alongside browser privacy controls, but its security relevance is broader because it shapes how data follows a user across trust boundaries.
Definitions vary across vendors and privacy regimes on when a cookie is treated as “third-party” in edge cases such as embedded widgets, redirects, and partitioned storage. For NHI and digital identity work, the important distinction is that the cookie is set and controlled by a different domain than the site a person intentionally visited, which creates a persistent cross-site signal. Standards bodies such as the MDN Web Docs on cookies describe the mechanics, while privacy frameworks increasingly constrain how that signal can be used. The most common misapplication is treating third-party cookies as harmless analytics data, which occurs when teams ignore the cross-domain linkability they enable.
Examples and Use Cases
Implementing or relying on third-party cookies rigorously often introduces a tradeoff between measurement fidelity and user privacy, requiring organisations to weigh attribution needs against surveillance risk and browser restrictions.
- An ad-tech pixel on multiple publisher sites uses the same cookie to recognise a browser and build a cross-site audience profile.
- A social media embed sets a cookie that lets the provider measure engagement across unrelated domains.
- An analytics vendor uses a third-party cookie for session stitching, then loses continuity when browsers block or partition that cookie.
- A consent management flow attempts to suppress cookie creation until the user accepts tracking, but embedded tags may still trigger storage if not governed correctly.
- Browser privacy features or enterprise controls reduce the reliability of third-party cookies, forcing teams to shift to first-party or server-side approaches.
These patterns are visible in real-world compromise and supply-chain reporting, including the The 52 NHI breaches Report, where cross-system trust failures repeatedly expand blast radius. For technical grounding, the MDN Web Docs on cookies remains the clearest public reference for browser behavior.
Why It Matters in NHI Security
Third-party cookies matter in NHI security because they model a wider class of trust leakage: identifiers that persist beyond the original boundary and become reusable elsewhere. That pattern is familiar in service accounts, API keys, and embedded integrations, where an externally controlled token can be replayed across environments if governance is weak. In browser ecosystems, the cookie becomes a policy problem as much as a tracking mechanism, especially when vendors, analytics tags, and ad networks are allowed to operate with broad read access. The OWASP Non-Human Identity Top 10 is relevant here because it frames how persistent credentials and externally reachable identities expand risk when they are not tightly scoped.
NHI Mgmt Group has found that 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, which mirrors the same cross-boundary exposure pattern seen in cookie-based tracking. That is why cookie governance, third-party script review, and data minimisation are not just privacy tasks, but part of broader identity attack-surface reduction. Organisations typically encounter the true cost only after a browser change, consent failure, or privacy incident breaks tracking and reveals how much business logic depended on an unstable cross-site identifier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Cross-site identity abuse parallels persistent token misuse across automated agents. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Third-party cookies resemble externally controlled secrets that expand access boundaries. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access mechanisms should be scoped to intended trust boundaries. |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects implicit trust in reusable identifiers across domains. | |
| NIST AI RMF | Tracking identifiers can create privacy and governance risk in data pipelines. |
Restrict reusable identifiers and review any cross-domain credential-like signal for overreach.
Related resources from NHI Mgmt Group
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What are the implications of using OAuth tokens in third-party integrations?
- How should security teams govern third-party AI agents that use OAuth access?
- How should organisations govern third-party identity access more tightly?
