Content Security Policy (CSP)
How a Content Security Policy Limits What Browsers Load
A content security policy (CSP) is an HTTP response header that lists the sources a browser is allowed to load scripts, styles, images and other resources from. Anything outside that list is blocked before it can run. This header is one of several described in HTTP security headers.
Consider a page that has been tampered with so that it loads a script from an unknown domain. Without a policy, the browser runs that script with full access to the page and its visitors. With a policy that allows only the website's own domain and a few trusted partners, the browser refuses the foreign script.
Key Directives and How They Are Written
A policy is made of directives, each controlling one type of resource. The most useful ones are:
- default-src, a fallback that applies when a more specific directive is missing.
- script-src, which controls where JavaScript may come from.
- style-src and img-src, which control stylesheets and images.
- frame-ancestors, which controls which sites may embed the page, overlapping with the framing header.
A simple example looks like this: Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com. The keyword 'self' means the site's own origin. Inline scripts, which are written directly inside the page, are blocked unless they are allowed by a nonce or hash. Allowing 'unsafe-inline' weakens the protection considerably.
Where CSP Helps and Where It Has Limits
CSP is especially effective against cross-site scripting, because most injected attacks rely on inline code or on loading a script from an attacker's server. Blocking those routes reduces what an attacker can do even when the injection itself succeeds.
CSP is not a replacement for fixing the injection point. Developers still need to escape output and validate input. Sites that use many third-party tools, such as analytics, chat widgets and advertising, can find a strict policy hard to maintain, and older pages with large amounts of inline code may need rewriting.
Because a wrong policy can break a working site, browsers support a report-only mode, sent with the header Content-Security-Policy-Report-Only. It logs what would have been blocked without blocking it, so the policy can be tuned before it is enforced.
Rolling Out a Policy on an Online Shop
An online shop uses a payment widget and a review service, both loaded from outside domains. The team first deploys a report-only policy and notices violation reports for a script that the review service loads from a second domain. They add that domain to the list, watch the reports settle, and only then enforce the policy. Had they enforced immediately, checkout buttons would have stopped working.
Frequently asked questions
Does CSP replace input validation and output escaping?
No. CSP is a second layer of defence. Developers still need to validate input and escape output so that malicious content is never treated as code in the first place. CSP limits what injected code can do, but it does not fix the flaw that allowed the injection.
Why does my site break after adding a content security policy?
Usually because a script, stylesheet or image is loaded from a source that is not in the list, or because an inline script runs without permission. Report-only mode shows these violations before they cause problems, so the policy can be adjusted first.