Content Security Policy (CSP)

Content Security Policy (CSP) is a security feature designed to prevent malicious content from being executed on websites by controlling which resources can be loaded and executed. By specifying approved sources for content such as JavaScript, CSS, images, and other media, CSP helps mitigate security risks such as Cross-Site Scripting (XSS) attacks, code injection, and other content-based threats. Implemented through HTTP headers, CSP allows website administrators to define rules that govern content access and execution across web applications.

Core Characteristics and Components of Content Security Policy

1. Policy Directives: CSP directives are rules that define where resources can be loaded from. Each directive corresponds to a specific type of content and establishes restrictions on how it can be sourced. Common directives include:
   • default-src: Specifies the default policy for all resource types not explicitly defined by other directives.  
   • script-src: Defines sources from which JavaScript can be loaded.  
   • style-src: Specifies permissible sources for CSS files.  
   • img-src: Controls allowed sources for images.  
   • connect-src: Defines allowable sources for HTTP connections, commonly used for APIs.  
   • font-src: Controls sources for web fonts.  
   • frame-src: Determines allowed sources for iframes and embedded content.
2. Source Expressions: CSP directives use source expressions to define acceptable resource locations. Common expressions include:
   • 'self': Refers to the same origin as the document, allowing resources to load only from the site’s domain.  
   • 'none': Denies all sources, blocking any content of that type from loading.  
   • 'unsafe-inline': Permits inline resources (e.g., JavaScript or CSS written directly in HTML), although this weakens security.  
   • 'unsafe-eval': Allows dynamic code evaluation methods, such as `eval()`, though this is generally discouraged.  
   • Specific URL or domain: Lists specific trusted sources, such as `https://example.com`, for loading content from external domains.
3. Policy Enforcement and Reporting: CSP supports two primary modes of enforcement:
   • Enforcement Mode: Blocks any content that violates the specified directives. When a policy is violated, the content is blocked, and errors are logged in the browser’s developer console.  
   • Report-Only Mode: Instead of blocking content, this mode sends violation reports to a specified URI, allowing administrators to assess policy effects without enforcing them. Reports include details on policy violations and are commonly used for testing and refining CSP settings before full enforcement.
4. HTTP Header Specification: CSP policies are delivered through HTTP headers, primarily the `Content-Security-Policy` header for enforcing policies and `Content-Security-Policy-Report-Only` for non-blocking reports. Each header lists directives and source expressions that together form a complete policy.  
   
   Example CSP header:

   Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self' https://images.example.com

Mathematical Representation of CSP Policy Restriction

CSP restrictions can be formulated by mapping resource requests to allowable sources. Let `R` be a set of resource requests and `S` a set of allowable sources. The function `f(r)` defines whether a resource `r` in `R` complies with CSP:

• `f(r) = 1` if `r ∈ S`  
• `f(r) = 0` if `r ∉ S`

Thus, if `Σ f(r) = n` for `n` requests, then all requests are CSP-compliant. Any result where `Σ f(r) < n` signals that certain resources are blocked due to non-compliance with CSP.

CSP Levels of Restriction and Security

The strength of CSP depends on the specific directives and source expressions used. Policies that restrict external sources, avoid `unsafe-inline`, and enforce strict rules on JavaScript and CSS sourcing provide robust protection. Adding `'nonce-'` (random tokens) or `'sha-'` (hashes) to CSP policies for inline scripts and styles adds another layer of control, allowing inline content only if it matches a pre-defined cryptographic hash or nonce value, mitigating XSS risks even further.

1. Strict CSP Example:

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

This policy only permits content from the same origin (`'self'`) and embedded image data (`data:`), blocking all external content by default.

2. Looser CSP Example with Inline Scripts:

   Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src *; connect-src https://api.example.com

This policy allows inline JavaScript (`'unsafe-inline'`) and permits images from any source (`*`), though this weaker policy increases vulnerability to XSS attacks.

CSP is essential in modern web application security, addressing common vulnerabilities related to content loading and execution. By defining strict content sources and limiting the use of inline scripts and dynamic code evaluation, CSP reduces the attack surface of web applications. Implementing CSP effectively involves balancing security with functionality, as overly restrictive policies can block legitimate content, while overly permissive policies may reduce protection. As a security control, CSP plays a critical role in safeguarding user data and application integrity against XSS and other injection-based attacks.