XSS leak protection

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. The OWASP® Foundation, Cross Site Scripting (XSS)(opens in a new tab)

XSS vulnerabilities are incredibly serious and we recommend you reference the OWASP Cheat Sheet(opens in a new tab) to learn how you can prevent an attack.

Prevention is just one aspect of an effective security model, though. To prepare for the worst case scenario where an attack is successful, you should ensure your application is configured to minimize the attack's surface area.

Clerk works to minimize the surface area by using HttpOnly cookies for authenticated requests to our Frontend API(opens in a new tab), so that credentials cannot be leaked during XSS attacks.

What is a HttpOnly cookie?

HttpOnly is a flag on the Set-Cookie(opens in a new tab) header that is issued by a server to set a cookie in the browser.

When this flag is set, the cookie can only be read from a server responding to an HTTP request. It is not accessible through JavaScript with the document.cookie property.

Without the flag, a cookie can also be read by JavaScript in the browser.

How do HttpOnly cookies minimize XSS attacks?

XSS attacks allow the attacker to run arbitrary JavaScript in the browser while users are navigating your application.

If Clerk did not use an HttpOnly cookie, but instead used a storage solution that is accessible through JavaScript, it would mean the malicious JavaScript could access users' session tokens.

Unauthorized access to session tokens is especially problematic because the tokens can be used to take actions on behalf of a user, even after a XSS vulnerability has been resolved. As a result, when session tokens leak, it is recommended you invalidate existing tokens and force users to sign in again.

HttpOnly cookies prevent session tokens from leaking through XSS attacks. Unless your application leaks session tokens another way, there will not be a need to sign your users out after a successful XSS attack.

Other forms of session token storage are susceptible to this issue, so even if you don't use Clerk, we highly recommend avoiding these forms of storage for session tokens:

• Cookies without the HttpOnly flag
• Window.localStorage(opens in a new tab)
• Window.sessionStorage(opens in a new tab)
• IndexedDB(opens in a new tab)

Why is the __session cookie on my application domain not HttpOnly?

The __session cookie contains the session token and it is dropped by Clerk to your application's root domain (e.g. example.com). It is not HttpOnly (as is the case with the __client cookie which lives on the Frontend API domain, e.g. clerk.example.com) because it needs to be accessible by Clerk.js.

However, for this reason, the token contained in this cookie is short-lived (1 minute lifetime), so as to mitigate any potential XSS attacks.