Cybersecurity glossary
What is Cookie Tossing?
Learn what cookie tossing is, how attackers plant cookies on parent domains or related hosts to confuse applications, what impact looks like, and how __Host- and tight Domain scope help.
Definition
Cookie tossing is an attack technique in which an adversary sets or overwrites cookies for a target site from a related context—often a sibling subdomain or parent domain they control—so the victim application receives attacker-controlled cookie values it may trust.
Why cookie tossing matters
Applications often assume “if the browser sent this cookie, we set it.” That assumption fails when cookie scope spans hosts you do not equally trust. Cookie tossing exploits shared Domain cookies, path quirks, or related-host control to insert values the main application will consume.
Impact ranges from broken features to session fixation, CSRF token poisoning, feature-flag abuse, or logic bugs that treat cookie strings as trusted configuration.
How cookie tossing works
Find a related writable context
Attacker controls a subdomain, parent-domain response, or other host that can set cookies visible to the target.
Plant a cookie with a trusted name
Set-Cookie uses a name the target app reads, often with Domain=.example.com.
Victim uses the main application
Browser sends the attacker-influenced cookie along with legitimate ones.
Application trusts the value
Session handling, preferences, or security tokens accept the planted data.
Attacker achieves an objective
Fixation, bypasses, or state confusion follow depending on what the cookie gates.
Common tossing scenarios
Sibling subdomain
XSS or takeover on shop.example.com sets Domain=.example.com cookies for accounts.example.com.
Abandoned subdomain
Dangling DNS lets attackers serve Set-Cookie for a forgotten host under the parent domain.
Path ambiguity
Extra same-named cookies on different paths confuse parsers that take the first value.
Session fixation goal
Victim authenticates into an attacker-chosen session identifier.
Defenses that help
| Control | Effect |
|---|---|
| __Host- session cookies | Host-only Secure Path=/ cookies resist cross-subdomain planting |
| Avoid broad Domain | Do not share auth cookies across all subdomains by default |
| Server-side session binding | Cookie value is only a pointer; server validates session state |
| Rotate on login | Reduces fixation usefulness of pre-planted session IDs |
| Inventory subdomains | Removes abandoned hosts that become tossing launchpads |
Hardening checklist
- Prefer __Host- for primary authentication cookies.
- Omit Domain unless cross-subdomain sharing is explicitly required and trusted.
- Rotate session identifiers at authentication and privilege change.
- Do not trust cookie values as authorization decisions without server lookups.
- Monitor and decommission unused subdomains.
- Normalize Cookie header parsing; reject unexpected duplicates where possible.
- Treat XSS on any related subdomain as a threat to shared-domain cookies.
- Add regression tests for Domain/Path on security-sensitive Set-Cookie responses.
The practical takeaway
Cookie tossing plants attacker-controlled cookies into an application’s jar from a related host or ambiguous path scope. The app then may treat those values as its own.
Shrink cookie scope, prefer __Host-, rotate sessions, and never confuse “cookie present” with “cookie trustworthy.”
Related security terms
__Host- Cookie Prefix
Prefix that forbids Domain and helps resist many tossing scenarios.
Cookie Prefix
Browser-enforced naming rules that harden cookie acceptance.
Cookie
Baseline cookie scope model attackers abuse during tossing.
Domain Hijacking
Related risk when attackers control DNS for a subdomain used in tossing.
Frequently asked questions
What is cookie tossing in simple terms?
An attacker who controls a related host sets a cookie that your main app will also receive. Your app may then trust that attacker-supplied value.
Why do related hosts matter?
Cookies scoped with Domain=.example.com are shared across subdomains. A malicious or XSS-compromised blog.example.com can plant cookies for app.example.com.
Is cookie tossing the same as session fixation?
They overlap. Tossing is the mechanism of planting cookies from a related context. Session fixation is one possible goal—forcing a known session identifier.
How does __Host- help?
__Host- cookies cannot use Domain and are host-only with Path=/. An attacker on another subdomain generally cannot set a valid __Host- cookie for your exact host.
Can path-based cookies be tossed?
Yes. Multiple cookies with the same name on different paths can create ambiguous Cookie headers that some servers parse insecurely.
What should apps do if they see unexpected cookie values?
Do not trust cookies as authenticators without server-side session binding. Prefer cryptographically unguessable IDs stored server-side and reject malformed values.
Does HttpOnly stop cookie tossing?
No. Tossing usually uses Set-Cookie from a related host or response, not document.cookie on the victim page.
References
Explore authoritative guidance and frameworks related to cookie tossing.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.