CSP
Content Security Policy (CSP) is a browser security standard that prevents cross-site scripting (XSS), clickjacking, and other code injection attacks by controlling which resources a page can load and execute.
§ 1 Definition
Content Security Policy (CSP) is a defense-in-depth security mechanism that lets you control exactly which resources a browser is allowed to load on your website. CSP is delivered via an HTTP header (Content-Security-Policy) or a meta tag. The policy is a set of directives that define allowed sources for different resource types: scripts, styles, images, fonts, frames, connections, and more. If a page attempts to load a resource that violates the policy, the browser blocks it. For inline scripts and event handlers, CSP can require cryptographic nonces or hashes to prove the script was intentionally included by the developer, not injected by an attacker. CSP is the single most effective defense against XSS attacks. XSS is the vulnerability, CSP is the mitigation. CSP cannot prevent XSS vulnerabilities in your server code, but it can prevent the browser from executing injected scripts even if an XSS vulnerability exists. CSP should be deployed in Report-Only mode (Content-Security-Policy-Report-Only header) first to discover violations without blocking them, then hardened to enforcement mode once the policy is validated.
§ 2 CSP Directives
CSP directives control specific resource types. The most important directives: default-src (fallback for all resource types), script-src (scripts), style-src (stylesheets), img-src (images), connect-src (XHR, fetch, WebSocket), font-src (fonts), frame-src (iframes), object-src (plugins: Flash, Java), media-src (audio, video), base-uri (base URLs), and form-action (form submission targets). Each directive specifies allowed sources: 'self' (same origin), specific domains (https://analytics.example.com), 'none' (block all), 'unsafe-inline' (allow inline scripts/styles - avoid this), 'unsafe-eval' (allow eval() - avoid this), nonces (nonce-random123), and hashes (sha256-abc123...). A strict CSP uses 'self', nonces for inline scripts, and hashes for inline styles, with no 'unsafe-inline' or 'unsafe-eval' directives.
§ 3 Strict CSP vs Allowlist CSP
Allowlist CSP (specifying domain allowlists like script-src 'self' https://cdn.example.com https://www.google-analytics.com) was the original approach. It is difficult to maintain, easy to get wrong, and often ineffective because attackers can bypass it by finding a whitelisted domain that hosts user-generated content. Strict CSP (using nonces or hashes) is the modern recommended approach. Instead of listing trusted domains, you generate a unique nonce (number-used-once) for each page load and include it in the script tag. The CSP header includes that nonce. Only scripts with the matching nonce execute. This approach is simpler, more secure, and works regardless of where the script is hosted. Google's CSP evaluator recommends strict CSP over allowlist CSP. Migrate to strict CSP with nonces if you are maintaining an allowlist-based policy.
§ 4 CSP in Practice: Deployment and Monitoring
Deploying CSP requires a careful, incremental approach. Start in Report-Only mode: Content-Security-Policy-Report-Only header, with a report-uri or report-to directive that sends violation reports to your logging service. Monitor reports for legitimate resources being blocked. Adjust the policy. Once the policy is clean (no legitimate violations), switch to enforcement mode (Content-Security-Policy header). Continue monitoring enforcement reports for missed resources and potential attacks. CSP can be complex for sites that load many third-party scripts (analytics, ads, widgets). Each third-party script must be accounted for in the policy. For ads and untrusted third-party content, consider using sandbox directives to restrict what those iframes can do. Most CDNs and hosting platforms support adding custom HTTP headers, making CSP configuration straightforward.
§ 5 Note
§ 6 In code
```http
# Strict CSP header (recommended approach)
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{random}' 'strict-dynamic';
style-src 'self' 'unsafe-inline';
img-src 'self' https://images.example.com data:;
connect-src 'self' https://api.example.com;
font-src 'self' https://fonts.example.com;
frame-src 'none';
object-src 'none';
base-uri 'self';
form-action 'self';
report-uri https://example.report-uri.com/r/d/csp/enforce;
# In HTML, reference the nonce on allowed inline scripts
<script nonce="{random}">
// This script will execute because it has the matching nonce
console.log('Safe inline script');
</script>
# An injected script without the nonce will be blocked
```§ 7 Common questions
- Q. Do I need CSP if my site has no user-generated content?
- A. Yes. XSS can come from reflected parameters, URL fragments, and third-party scripts. CSP protects against all of these, even if your site does not accept user content.
- Q. What is the difference between CSP Report-Only and enforcement mode?
- A. Report-Only logs violations but does not block resources. Use it during development and testing. Enforcement mode blocks violating resources. Start with Report-Only, fix legitimate violations, then switch to enforcement.
- Q. Does CSP affect site performance?
- A. Negatively in practice. CSP blocks resources that violate the policy, but a well-configured CSP has minimal performance impact. The report-uri directive can generate network traffic for violation reports, but this is manageable.
- CSP is a browser security standard that controls which resources a page can load, preventing XSS and injection attacks.
- Strict CSP with nonces is the modern recommended approach, simpler and more secure than allowlist CSP.
- Deploy CSP in Report-Only mode first to discover violations before enforcing.
- CSP is defense-in-depth. It mitigates XSS impact but does not replace secure coding practices.
Atomic Glue implements Content Security Policy for every website and web application we build. We use strict CSP with nonces for modern applications and provide a migration path for legacy sites on allowlist-based policies. We deploy CSP in Report-Only mode, monitor violations, and harden to enforcement mode once validated. CSP is a standard part of the security hardening in our Web Development services. Get in touch to secure your website with Content Security Policy.
Get in touchContent Security Policy (CSP) is a browser security standard that prevents cross-site scripting (XSS), clickjacking, and other code injection attacks by controlling which resources a page can load and execute.
Category: Backend (also: Security, Front End, Software Engineering, Performance)
Author: Atomic Glue Development Team
## Definition
Content Security Policy (CSP) is a defense-in-depth security mechanism that lets you control exactly which resources a browser is allowed to load on your website. CSP is delivered via an HTTP header (Content-Security-Policy) or a meta tag. The policy is a set of directives that define allowed sources for different resource types: scripts, styles, images, fonts, frames, connections, and more. If a page attempts to load a resource that violates the policy, the browser blocks it. For inline scripts and event handlers, CSP can require cryptographic nonces or hashes to prove the script was intentionally included by the developer, not injected by an attacker. CSP is the single most effective defense against XSS attacks. XSS is the vulnerability, CSP is the mitigation. CSP cannot prevent XSS vulnerabilities in your server code, but it can prevent the browser from executing injected scripts even if an XSS vulnerability exists. CSP should be deployed in Report-Only mode (Content-Security-Policy-Report-Only header) first to discover violations without blocking them, then hardened to enforcement mode once the policy is validated.
## CSP Directives
CSP directives control specific resource types. The most important directives: default-src (fallback for all resource types), script-src (scripts), style-src (stylesheets), img-src (images), connect-src (XHR, fetch, WebSocket), font-src (fonts), frame-src (iframes), object-src (plugins: Flash, Java), media-src (audio, video), base-uri (base URLs), and form-action (form submission targets). Each directive specifies allowed sources: 'self' (same origin), specific domains (https://analytics.example.com), 'none' (block all), 'unsafe-inline' (allow inline scripts/styles - avoid this), 'unsafe-eval' (allow eval() - avoid this), nonces (nonce-random123), and hashes (sha256-abc123...). A strict CSP uses 'self', nonces for inline scripts, and hashes for inline styles, with no 'unsafe-inline' or 'unsafe-eval' directives.
## Strict CSP vs Allowlist CSP
Allowlist CSP (specifying domain allowlists like script-src 'self' https://cdn.example.com https://www.google-analytics.com) was the original approach. It is difficult to maintain, easy to get wrong, and often ineffective because attackers can bypass it by finding a whitelisted domain that hosts user-generated content. Strict CSP (using nonces or hashes) is the modern recommended approach. Instead of listing trusted domains, you generate a unique nonce (number-used-once) for each page load and include it in the script tag. The CSP header includes that nonce. Only scripts with the matching nonce execute. This approach is simpler, more secure, and works regardless of where the script is hosted. Google's CSP evaluator recommends strict CSP over allowlist CSP. Migrate to strict CSP with nonces if you are maintaining an allowlist-based policy.
## CSP in Practice: Deployment and Monitoring
Deploying CSP requires a careful, incremental approach. Start in Report-Only mode: Content-Security-Policy-Report-Only header, with a report-uri or report-to directive that sends violation reports to your logging service. Monitor reports for legitimate resources being blocked. Adjust the policy. Once the policy is clean (no legitimate violations), switch to enforcement mode (Content-Security-Policy header). Continue monitoring enforcement reports for missed resources and potential attacks. CSP can be complex for sites that load many third-party scripts (analytics, ads, widgets). Each third-party script must be accounted for in the policy. For ads and untrusted third-party content, consider using sandbox directives to restrict what those iframes can do. Most CDNs and hosting platforms support adding custom HTTP headers, making CSP configuration straightforward.
## Note
Common misunderstanding: CSP prevents XSS attacks. More precisely, CSP mitigates the impact of XSS vulnerabilities. It does not prevent the vulnerability in your server code, but it blocks the browser from executing injected scripts. CSP is defense-in-depth, not a replacement for secure coding practices. Another misconception: CSP is too complex to implement. Strict CSP with nonces is simpler than allowlist CSP and can be implemented incrementally using Report-Only mode. Start with a restrictive policy, monitor violations, and adjust. Also: CSP headers must be set on every HTML page, not just the initial load. SPAs that use HTML5 routing must ensure CSP headers are present on all routes.
## In code
## Common questions Q: Do I need CSP if my site has no user-generated content? A: Yes. XSS can come from reflected parameters, URL fragments, and third-party scripts. CSP protects against all of these, even if your site does not accept user content. Q: What is the difference between CSP Report-Only and enforcement mode? A: Report-Only logs violations but does not block resources. Use it during development and testing. Enforcement mode blocks violating resources. Start with Report-Only, fix legitimate violations, then switch to enforcement. Q: Does CSP affect site performance? A: Negatively in practice. CSP blocks resources that violate the policy, but a well-configured CSP has minimal performance impact. The report-uri directive can generate network traffic for violation reports, but this is manageable.
## Key takeaways
- CSP is a browser security standard that controls which resources a page can load, preventing XSS and injection attacks.
- Strict CSP with nonces is the modern recommended approach, simpler and more secure than allowlist CSP.
- Deploy CSP in Report-Only mode first to discover violations before enforcing.
- CSP is defense-in-depth. It mitigates XSS impact but does not replace secure coding practices.
## Related entries
- [CORS](atomicglue.co/glossary/cors-backend)
- [Security Headers](atomicglue.co/glossary/security-headers)
- [API](atomicglue.co/glossary/api)
- [REST](atomicglue.co/glossary/rest)
Last updated June 2026. Permalink: atomicglue.co/glossary/csp-backend