content security policy

Overview

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that allows web developers to define a whitelist of sources from which a browser will load resources such as scripts, stylesheets, images, and other content. It is used to prevent a wide range of attacks, particularly Cross-Site Scripting (XSS) and data injection vulnerabilities, by controlling where resources can be loaded from.

Developers use CSP primarily in the context of web application security and obfuscation strategies. It is a core part of a defense-in-depth approach, often implemented alongside other security controls such as input sanitization, secure headers, and runtime protections. CSP is not a standalone solution but rather a component that helps mitigate risks when combined with secure coding practices.

content security policy developer glossary illustration

Why It Matters

CSP is crucial for developers because it provides a robust line of defense against malicious code injection. It helps prevent attackers from executing unauthorized scripts, which could otherwise steal session cookies, redirect users to malicious sites, or perform other harmful actions. When properly configured, CSP significantly reduces the attack surface of a web application.

From a production standpoint, CSP can also impact how content is rendered in the browser. Misconfigured policies can lead to broken functionality, as legitimate resources might be blocked. It is important to test CSP policies in staging environments before deploying them to production. Additionally, CSP headers are not supported in all browsers, and developers must account for browser compatibility when designing policies.

How It Works

CSP operates by defining a set of directives in an HTTP header that the browser enforces. These directives control where resources can be loaded from, what types of content can be executed, and how violations are reported. The policy is enforced by the browser itself, without requiring server-side processing or complex logic.

CSP is implemented via the Content-Security-Policy HTTP header.
Directives such as script-src, style-src, and img-src control specific resource types.
Violations can be reported using the report-uri or report-to directives.
Default policies can be set using the default-src directive.
Some directives support keywords like 'self', 'unsafe-inline', and 'unsafe-eval' to define source control.

Quick Reference

Item	Purpose	Notes
`Content-Security-Policy` header	Enforces CSP directives	Must be sent by server
`script-src`	Controls script loading sources	Can include `'self'`, `'unsafe-inline'`, or specific domains
`default-src`	Sets default policy for unspecified directives	Acts as fallback for missing directives
`report-uri`	Reports policy violations to a specified URL	Deprecated in favor of `report-to`
`report-to`	Specifies a group for violation reports	Used with `Report-To` header

Basic Example

This example shows a basic CSP header that allows scripts to be loaded only from the same origin and disables inline scripts and eval.

Content-Security-Policy: script-src 'self';

The directive script-src 'self' restricts script loading to the same origin as the document. Inline scripts and the use of eval are blocked by default, which prevents common XSS vectors.

Production Example

This example demonstrates a more comprehensive CSP policy suitable for a production environment. It allows resources from trusted domains, enables reporting, and blocks unsafe practices.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; report-uri /csp-report;

This policy sets a default source restriction to the same origin, allows scripts from a CDN, permits inline styles for legacy compatibility, allows images from the same origin and via data URLs or HTTPS, restricts network requests to the same origin, and sends violation reports to a dedicated endpoint.

Common Mistakes

Overly restrictive policies that break legitimate functionality, such as blocking inline scripts needed for legacy components.
Using 'unsafe-inline' or 'unsafe-eval' without proper justification, which undermines security.
Not testing policies in staging environments, leading to broken features in production.
Ignoring browser compatibility issues, particularly with older browsers that do not support CSP.
Failing to implement reporting mechanisms, which makes it difficult to detect and fix policy violations.

Security And Production Notes

Always test CSP policies in a staging environment to avoid breaking legitimate functionality.
Use report-to and Report-To headers for better violation reporting than the deprecated report-uri.
Do not include 'unsafe-inline' unless absolutely necessary, and always audit its usage.
Ensure that all domains in script-src and other directives are secure and trusted.
Monitor CSP violation reports to identify potential issues or misconfigurations in real-time.

Related Concepts

Content Security Policy is closely related to several other web security concepts. HTTP headers provide the mechanism through which CSP is delivered to the browser. Input sanitization helps prevent injection attacks that CSP can mitigate. Secure cookies and SameSite attributes work in tandem with CSP to protect session integrity. Subresource Integrity (SRI) adds another layer of control over resource loading by verifying checksums. XSS protection is a broader category that includes CSP as one of its tools.