Content Security Policy (CSP)
An HTTP security header that controls which resources (scripts, styles, images, fonts, etc.) a browser is allowed to load for a given page, mitigating cross-site scripting (XSS) and data injection attacks.
CSP works by specifying allowed sources for each type of resource via directives. For example, script-src 'self' https://cdn.example.com allows scripts only from the same origin and a specific CDN. Any script from another source is blocked by the browser and reported.
Implementing CSP often breaks functionality initially because inline scripts, eval(), and third-party resources may violate the policy. QA teams play a critical role in testing a new or updated CSP by verifying that all legitimate functionality still works while the policy effectively blocks unauthorized resources. The Content-Security-Policy-Report-Only header is useful for testing without enforcement.
Why It Matters for QA Teams
CSP misconfigurations can silently break analytics, chat widgets, payment forms, or embedded media. QA teams need to test thoroughly when CSP policies change to ensure nothing legitimate is blocked.
Example
After tightening the CSP to block inline scripts, QA discovers that the third-party live chat widget stops loading because it injects inline JavaScript. The team works with the vendor to use a nonce-based approach (script-src 'nonce-abc123') that allows the chat script while still blocking unauthorized inline code.