Learn the vocabulary of restricting which sources a browser is allowed to load a script or resource from.
0 / 5 completed
1 / 5
At standup, a dev mentions a response header that tells the browser exactly which sources scripts, styles, and other resources are allowed to load from, blocking anything outside that allowlist. What is this header called?
A Content Security Policy, or CSP, is a response header that tells the browser exactly which sources scripts, styles, and other resources are allowed to load from, blocking anything outside that allowlist. The Content-Type header only tells the browser how to interpret the response body, which is an entirely different purpose from restricting resource origins. This source restriction is what makes CSP an effective defense against a malicious script being injected and executed from an untrusted origin.
2 / 5
During a design review, the team wants to allow one specific inline script to execute while still blocking any other injected inline script an attacker might insert. Which capability supports this?
A nonce-based script-src directive allowlists only a script tagged with a matching, randomly generated nonce value, so a legitimate inline script executes while an injected script, which won't have that nonce, is blocked. A script-src directive permitting unsafe-inline lets every inline script execute, including one an attacker managed to inject, which defeats the purpose of having a CSP at all. This nonce-based allowlisting is what lets a page keep some inline scripts while still meaningfully restricting which ones can run.
3 / 5
In a code review, a dev notices the CSP header is initially deployed with report-uri set and Content-Security-Policy-Report-Only used instead of the enforcing header, so violations are observed without actually blocking anything yet. What does this represent?
Report-only mode lets the team observe what a new CSP would have blocked, via a violation report, without actually enforcing that blocking yet, catching a policy that's too strict or missing an allowed source before it breaks real functionality. Deploying the enforcing header directly, with no report-only validation, risks breaking a legitimate resource the policy didn't anticipate. This staged rollout is a standard way to introduce a CSP safely on an existing, already-complex page.
4 / 5
An incident report shows an attacker successfully executed an injected script that stole session cookies, because the page served no Content-Security-Policy header at all, leaving the browser with no restriction on which script sources it would execute. What practice would prevent this?
Deploying a Content Security Policy that restricts script sources to a trusted allowlist blocks an injected script from executing, since it won't come from, or carry the nonce or hash of, a source the policy actually trusts. Serving no CSP header at all is exactly what left the browser free to execute the attacker's injected script in this incident. This restriction is one of the most effective, broadly applicable defenses against a cross-site scripting attack succeeding even after malicious content has been injected into a page.
5 / 5
During a PR review, a teammate asks why the team uses a nonce-based CSP allowlist instead of just permitting unsafe-inline so every existing inline script keeps working without modification. What is the reasoning?
Permitting unsafe-inline lets any injected script execute just as freely as a legitimate one, since the directive draws no distinction between the two at all. A nonce-based allowlist blocks an injected script that lacks the matching, unpredictable nonce, while still letting the page's own legitimate inline scripts run. The tradeoff is the added build-time or server-side work needed to generate and inject a fresh nonce into every legitimate inline script on each page render.