Security Headers – Content Security Policy (CSP)

Content Security Policy (CSP) is a web security standard that helps protect websites against various types of attacks, such as Cross-Site Scripting (XSS) and data injection.

CSP enables website administrators to define and enforce a set of rules specifying which resources (e.g., scripts, stylesheets, images) can be loaded and executed by a web page. This enhances the security of web applications by reducing the risk of code injection and other malicious activities.

How CSP Works

Content Security Policy (CSP) protects websites by defining and enforcing a set of rules regarding the sources from which various types of content can be loaded and executed.

Here’s how CSP works:

Defining a Security Policy	Website administrators configure a Content Security Policy by including a Content-Security-Policy header in the HTTP response sent by the web server. This header contains directives and source expressions that define the allowed sources for different types of resources.
Limiting Script Execution	The script-src directive is crucial for controlling the execution of JavaScript. By specifying allowed sources, administrators can prevent the execution of scripts from unauthorized or potentially malicious locations.
Controlling Stylesheets and Images	Similar to scripts, the style-src and img-src directives control the sources from which stylesheets and images can be loaded.
Preventing Inline Scripts and Styles	CSP allows administrators to minimize the risk of inline code injection by disallowing the use of 'unsafe-inline'.
Mitigating Data Injection	The data: source expression in img-src allows data URIs, but other directives can restrict data injection vectors.
Handling Network Requests	The connect-src directive controls the sources to which the browser can make network requests, helping prevent malicious communication with unauthorized servers.
Blocking Untrusted Sources	When a web page attempts to load content or execute scripts from a source not explicitly allowed by the CSP policy, the browser blocks these requests and executions, preventing potential security risks.
Reporting Violations	Administrators can include a report-uri or report-to directive in the CSP header to receive reports on policy violations. This helps in identifying and addressing security issues.
Dynamic Policy Updates	CSP allows for dynamic policy updates using the Content-Security-Policy-Report-Only header. This allows administrators to test and monitor policy changes without enforcing them immediately.
Enforcing Least Privilege	By explicitly specifying the allowed sources, CSP follows the principle of least privilege, limiting the attack surface and reducing the impact of potential security vulnerabilities.

Anatomy of the CSP Header

The Content Security Policy (CSP) header has a specific syntax, here are the basic elements:

Content-Security-Policy: directive1 value1; directive2 value2;

Here is what each part means:

Directive	Description	Example
default-src	Specifies the default source for content that doesn’t have a specific directive. It acts as a fallback.	default-src ‘self’ example.com;
script-src	Specifies the allowed sources for JavaScript.	script-src ‘self’ example.com;
style-src	Specifies the allowed sources for stylesheets.	style-src ‘self’ example.com;
img-src	Specifies the allowed sources for images.	img-src ‘self’ data:;
connect-src	Specifies the allowed sources for network requests (e.g., AJAX, WebSocket).	connect-src ‘self’ api.example.com;
font-src	Specifies the allowed sources for fonts.	font-src ‘self’ fonts.gstatic.com;

Source Expression Options

Sources can be specified using various expressions:

Expression	Description
self	Allows resources from the same origin.
unsafe-inline	Allows inline scripts/styles (not recommended for security).
unsafe-eval	Allows the use of eval() and similar functions (not recommended for security).
data	Allows data URIs.

Example CSP Configurations

Basic CSP Header

Here’s an example CSP header that allows scripts and styles only from the same origin and images from the same origin and data URIs:

Content-Security-Policy: script-src 'self'; style-src 'self'; img-src 'self' data:;

CSP Header Reporting Violations

Administrators can include a report-uri or report-to directive in the CSP header to receive reports on policy violations.

Content-Security-Policy: script-src 'self'; report-uri /csp-report-endpoint/;

Allowing Specific Domains for Scripts and Styles

This example allows scripts from 'self', example.com, and cdn.example.com, and styles from 'self' and fonts.googleapis.com.

Content-Security-Policy: script-src 'self' example.com cdn.example.com; style-src 'self' fonts.googleapis.com;

Allowing Data URIs for Images

This example allows images from the same origin and data URIs.

Content-Security-Policy: img-src 'self' data:;

Restricting Inline Scripts and Styles

This example restricts the use of inline scripts and styles.

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

Allowing Connections to Specific Domains

This example allows connections (e.g., AJAX requests) to the same origin and api.example.com.

Content-Security-Policy: connect-src 'self' api.example.com;

Enforcing HTTPS with HSTS

Combining Content Security Policy with HTTP Strict Transport Security (HSTS) to enforce the use of HTTPS.

Content-Security-Policy: default-src 'self'; upgrade-insecure-requests;
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Testing and Reporting Only

Using the Content-Security-Policy-Report-Only header for testing policy changes without enforcing them.

Content-Security-Policy-Report-Only: script-src 'self'; report-uri /csp-report-endpoint/;

Allowing Frames from Specific Domains

This example allows the web page to be embedded in frames on the same origin and trusted-site.com.

Content-Security-Policy: frame-ancestors 'self' trusted-site.com;