TLDR: A misconfigured Content-Security-Policy (CSP), highlighted in the OWASP Top Ten under “Security Misconfiguration” and “Cross-Site Scripting (XSS),” exposes web applications to malicious script execution, data theft, and resource misuse. Issues like overly permissive directives, incorrect configurations, and failure to enforce the policy compromise security. A properly implemented CSP is crucial for mitigating XSS and other injection-based attacks.
https://owasp.org/www-project-top-ten/
One common issue with CSP misconfiguration is the use of overly permissive directives such as `default-src *` or `script-src 'unsafe-inline'`. These settings allow execution of untrusted scripts, nullifying the protective intent of CSP. OWASP advises restricting directives to trusted sources and avoiding the use of unsafe inline scripts.
https://owasp.org/www-project-cheat-sheets/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
Another frequent oversight is failing to include all relevant resource types in the CSP policy. For example, neglecting to define rules for `img-src`, `media-src`, or `object-src` leaves gaps that attackers can exploit. OWASP recommends explicitly specifying allowed sources for all resource types used in the application.
https://owasp.org/www-project-top-ten/
Improper handling of third-party resources is another vulnerability. Including external scripts, styles, or images from untrusted domains increases the risk of injection attacks. OWASP advises using subresource integrity (SRI) for third-party scripts to ensure they have not been tampered with.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Neglecting to test the effectiveness of the CSP is a critical flaw. Misconfigured policies may inadvertently block legitimate content or fail to restrict harmful sources. OWASP recommends testing CSP implementations using tools like CSP Evaluator and monitoring violation reports.
https://csp-evaluator.withgoogle.com/
Another issue arises from allowing unsafe dynamic content. For example, enabling `unsafe-eval` in the CSP permits the use of `eval()` and similar functions, which are common vectors for XSS. OWASP advises avoiding these directives and refactoring code to eliminate the need for unsafe functions.
https://owasp.org/www-project-cheat-sheets/cheatsheets/XSS_Prevention_Cheat_Sheet.html
Failure to enforce the CSP using the `Content-Security-Policy` header can leave the policy ineffective. Applications that use `Content-Security-Policy-Report-Only` indefinitely fail to prevent malicious scripts from executing. OWASP emphasizes transitioning from report-only mode to enforced mode once violations are resolved.
https://owasp.org/www-project-top-ten/
Exposing detailed violation reports to unauthorized users creates additional risks. Attackers can analyze reports to understand the policy’s structure and identify exploitable gaps. OWASP advises sending violation reports to secure endpoints and restricting access to authorized personnel.
https://owasp.org/www-project-cheat-sheets/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
Improper configuration of nonce-based policies is another frequent issue. Reusing nonces across requests or allowing predictable nonces undermines the security of the CSP. OWASP advises generating unique, unpredictable nonces for each request to ensure robust protection.
https://owasp.org/www-project-top-ten/
Lastly, failing to integrate CSP with other security headers, such as `X-Content-Type-Options` and `Strict-Transport-Security`, weakens the overall security posture. OWASP recommends implementing a layered defense strategy, combining CSP with other headers for comprehensive protection.
https://owasp.org/www-project-cheat-sheets/cheatsheets/Secure_Headers_Cheat_Sheet.html
To mitigate these risks, developers should define precise CSP rules, test configurations thoroughly, and monitor violation reports for anomalies. Adhering to OWASP Top Ten guidelines ensures robust and effective implementation of Content-Security-Policy to safeguard web applications.