Session leak protection

When an application relies on a third party to operate a subdomain of their primary domain, it is possible for session tokens to leak to the third party operator.

Although the third party is trusted, leaking session tokens is not advised, since an attack on the third party could be chained into an attack on the application.

Consider an application where:

In this example, the application owner may want to share the session token across www and dashboard.

The easiest way to accomplish this is by storing the session token in a cookie with the Domain flag set to example.com so it is shared across both subdomains.

Unfortunately, this also shares the cookie with support, which is operated by a third party.

Instead of setting a shared cookie on example.com, Clerk sets two cookies: one on www.example.com and one on dashboard.example.com.

During the setup process, Clerk will ask the developer to configure two CNAME records in their DNS: one for clerk.www.example.com and one for clerk.dashboard.example.com.

These records allow us to set cookies scoped to www and dashboard respectively.

Note: Clerk currently only allows setting a cookie on one subdomain, but this strategy is still used to ensure the cookie is scoped properly and does not leak to other subdomains.