How CSP Protects JavaScript from Malicious Injections

Content Security Policy (CSP) is an essential HTTP security standard designed to prevent Cross-Site Scripting (XSS), clickjacking, and other data injection attacks in modern web applications. By establishing a strict set of rules that dictate which dynamic resources are allowed to load and execute, CSP creates a defensive boundary that blocks unauthorized scripts from running, even if an attacker successfully injects malicious code into the application’s Document Object Model (DOM).

The Core Problem: JavaScript Injection Attacks

In traditional JavaScript applications, browsers execute any code delivered inside a <script> tag or via dynamic functions like eval(). Malicious injection occurs when an attacker exploits input vulnerabilities to insert untrusted scripts into the application. Once executed, these scripts run with the privileges of the victim’s session, allowing attackers to steal session tokens, log keystrokes, or manipulate page content.

How Content Security Policy Mitigates Injections

CSP addresses injection vulnerabilities by removing the browser’s implicit trust in the content served by the application. Delivered via the Content-Security-Policy HTTP response header, it enforces several critical protective mechanisms.

1. Restricting Execution Sources (Whitelisting)

CSP allows administrators to declare approved domains from which JavaScript files can be fetched using the script-src directive.

Content-Security-Policy: script-src 'self' https://trustedscripts.example.com;

With this policy, the browser immediately rejects any script originating from unauthorized third-party domains, neutralizing attacks that attempt to load remote malicious payloads.

2. Disabling Inline Scripts

By default, robust CSP implementations block inline scripts (such as <script>alert('xss')</script> or inline event handlers like onload="..."). Because injection attacks predominantly rely on injecting inline code into HTML responses, blocking inline execution eliminates the primary vector for reflected and stored XSS attacks.

To allow legitimate inline scripts, developers must use cryptographic mechanisms rather than opening global permissions:

Nonces (Number Used Once): A cryptographically strong, random token generated per request. The browser only executes inline scripts matching the nonce declared in the CSP header.
```
Content-Security-Policy: script-src 'nonce-rAnd0m123';
```
```
<script nonce="rAnd0m123">
  // This script executes safely
</script>
```
Hashes: The CSP header specifies the SHA-256, SHA-384, or SHA-512 hash of the approved inline script’s content. Any modification by an attacker alters the hash, causing the browser to block execution.

3. Neutralizing Dynamic Code Evaluation

Attackers often leverage native JavaScript functions that convert strings into executable code, such as eval(), Function(), setTimeout(String), and setInterval(String).

A standard CSP automatically disables these evaluation mechanisms. Unless explicitly allowed with the dangerous 'unsafe-eval' keyword, the browser throws an error whenever dynamic string-to-code execution is attempted.

4. Enforcing Strict Context for Data Ingestion

CSP goes beyond script files by controlling other vectors that can be abused to execute malicious code or exfiltrate data:

connect-src: Limits the endpoints to which scripts can send data via fetch(), XMLHttpRequest, or WebSockets, preventing attackers from exfiltrating stolen data.
object-src: Restricts plugin execution (such as Flash or Java applets), preventing legacy object-based injection.
base-uri: Restricts the URLs that can be used in a document’s <base> element, preventing attackers from redirecting relative script paths to malicious servers.

Monitoring and Policy Enforcement

CSP provides built-in reporting capabilities via the report-to or report-uri directives. When a policy violation occurs, the browser sends a JSON payload detailing the blocked URI, the violated directive, and the context of the attempted injection.

Developers can also deploy policies in Content-Security-Policy-Report-Only mode. In this mode, the browser logs violations without breaking application functionality, enabling teams to refine their rules before enforcing strict blocking in production environments.