Explain the concept of Content Security Policy (CSP) and how it enhances security
TL;DR
Content Security Policy (CSP) is a browser-enforced defense-in-depth policy for controlling script execution, resource loading, framing, and other capabilities. A modern XSS-resistant policy typically authorizes scripts with a fresh per-response nonce or hashes rather than trusting every script at an origin. Prefer an HTTP response header; a <meta> policy supports only a subset of CSP and cannot provide directives such as frame-ancestors.
Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0m'; object-src 'none'; base-uri 'none'
Browser-enforced resource policy
The server sends a policy with the document, and the browser checks relevant loads and execution against its directives.
Use nonces or hashes for controlled scripts and start with a report-only rollout when appropriate; CSP limits exploit impact but does not repair the underlying injection bug.
What is Content Security Policy (CSP)?
Content Security Policy (CSP) lets a site constrain browser behavior with an allowlist and other directives. It can reduce the impact of an injection flaw, report violations, prevent framing, and restrict outbound connections. It complements rather than replaces safe output handling.
How CSP works
CSP works by allowing developers to define a set of rules that specify which sources of content are considered trustworthy. These rules are delivered to the browser via HTTP headers or meta tags. When the browser loads a page, it checks the CSP rules and blocks any content that does not match the specified sources.
Example of a CSP header
Here is a minimal nonce-based example. Generate an unpredictable nonce for each response and apply the same value to authorized <script nonce="..."> elements:
Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0m'; object-src 'none'; base-uri 'none'
This policy allows scripts carrying the matching nonce, blocks plugin content, and prevents injected <base> elements. A production policy should also cover framing, connections, styles, images, reporting, and any application-specific sources.
Common directives
default-src: Serves as a fallback for other resource types when they are not explicitly defined.script-src: Specifies valid sources for JavaScript.style-src: Specifies valid sources for CSS.img-src: Specifies valid sources for images.connect-src: Specifies valid sources for AJAX, WebSocket, and EventSource connections.font-src: Specifies valid sources for fonts.object-src: Specifies valid sources for plugins like Flash.
Benefits of using CSP
- Mitigates XSS attacks: By restricting the sources from which scripts can be loaded, CSP helps to prevent the execution of malicious scripts.
- Prevents data injection attacks: CSP can block the loading of malicious resources that could be used to steal data or perform other harmful actions.
- Improves security posture: Implementing CSP is a proactive measure that enhances the overall security of a web application.
Implementing CSP
CSP can be delivered in an HTTP header or, with limitations, a meta tag. The HTTP header applies before the document is processed and supports the full directive set. A meta policy starts only where the tag appears and cannot express every directive.
Using HTTP headers
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com
Using meta tags
<metahttp-equiv="Content-Security-Policy"content="default-src 'self'; script-src 'self' https://trusted.cdn.com" />
Further reading
- MDN Web Docs: Content Security Policy (CSP)
- OWASP: Content Security Policy
- web.dev: Content Security Policy