Cookie tossing

What it means

Cookie tossing is a trick where one subdomain sets a cookie for the parent domain. A page on blog.example.com can write a cookie scoped to .example.com, and the browser will then send it to app.example.com as if the app had set it. The browser decides which cookies to send by domain and path, not by who wrote them.

The app cannot tell who wrote a cookie from the cookie alone. It sees a name and a value arrive, so a value planted by a weaker sibling can end up trusted by a stronger one. That gap, between who wrote a cookie and who reads it, is the entire attack.

Why it matters

The weakest subdomain sets the security level for all of them. A forgotten marketing site, a staging host or a taken-over subdomain can plant cookies that touch your main product, even though the main product itself has no flaw. Nothing needs to be broken on the main app itself for the attack to work against it.

What gets planted matters. A chosen session token is session fixation. A forged CSRF token can defeat a cross-site request protection. A bad preference or feature flag can change what a signed-in customer sees. Each of these is quiet, and none shows up as a server error.

How it shows up

You meet it where several subdomains share one registered domain and cookies are set with a Domain attribute. Cookies set without it stay on the host that wrote them. Also check whether any subdomain runs third-party code or user content, since that is how an attacker gets to set a cookie in the first place. See cookie scope.

The defences are narrow scope and checks that do not rely on cookies alone. Use the __Host- prefix, which forces a cookie to be host-only and rules out a sibling overwriting it. Bind sessions to something the server holds, and keep untrusted content on a separate registered domain.