Content Security Policy (CSP) in Pen Testing: Importance & Fixes

Why CSP Is a Major Concern in Penetration Testing

Improve web security with a strong Content Security Policy (CSP). Learn how to detect, fix, and monitor CSP vulnerabilities to prevent XSS attacks.

When conducting a security audit or penetration test, one of the most common findings is a missing or weak Content Security Policy (CSP) directive. CSP acts as a client-side security control that restricts which resources, such as scripts, styles, and images, can be loaded by a web application.

If CSP is not properly configured, attackers can inject malicious scripts, hijack user sessions, or steal sensitive data. During penetration testing, security professionals assess whether CSP is implemented and how easily it can be bypassed. A typical penetration testing report might highlight CSP issues such as the absence of a CSP header, an overly permissive CSP that allows inline scripts, or the inclusion of third-party scripts from untrusted sources.

Understanding CSP and Its Functionality

CSP is defined through an HTTP response header that specifies the allowed sources for various types of resources. For example, a basic CSP configuration might look like:

add_header Content-Security-Policy "default-src 'self'; script-src 'self';";

Key directives include:

• default-src 'self' which restricts all resources to the same origin unless specifically overridden.
• script-src 'self' which allows JavaScript execution only from the same domain, blocking inline scripts.

When a browser encounters CSP, it blocks any non-compliant resource and logs a violation, reducing the attack surface for Cross-Site Scripting (XSS) and other injection attacks.

Evaluating CSP During Penetration Testing

The first step is to check if CSP is implemented. This can be done using browser developer tools by navigating to the Network tab and checking response headers or by using the command:

curl -I https://target-website.com | grep Content-Security-Policy

If no CSP is present, it represents a critical security finding. The next step is to analyze weak directives, such as the following example:

add_header Content-Security-Policy "script-src 'self' 'unsafe-inline' 'unsafe-eval';";

The presence of 'unsafe-inline' allows inline scripts, making XSS attacks trivial, while 'unsafe-eval' enables execution of JavaScript through eval(), facilitating code injection. To further assess the effectiveness of CSP, penetration testers can attempt to inject scripts through input fields or URL parameters, such as:

<script>alert('XSS Attack!')</script>

If the script executes, the CSP configuration is ineffective. If the browser blocks execution, checking the console for CSP violation errors helps identify potential weaknesses.

Fixing CSP Issues and Implementing a Strong Policy

Before enforcing CSP, a good practice is to start with a report-only mode. This allows security teams to detect potential breakages without blocking resources. A report-only CSP header can be implemented as follows:

add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report;";

Once tested, a stricter CSP policy should be enforced:

add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' 'nonce-randomNonce';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
";

This policy ensures that all resources are loaded from the same origin unless specified, JavaScript is only allowed from the site itself and a trusted CDN, inline styles are controlled using a nonce, Flash and other outdated technologies are blocked, and protections against clickjacking and unauthorized form submissions are in place.

Verifying and Monitoring CSP

After enforcing CSP, testing is essential to ensure that legitimate resources are not blocked. Browser developer tools can be used to check for blocked resources, and the CSP policy can be verified with:

curl -I https://yourwebsite.com | grep Content-Security-Policy

To continuously monitor CSP violations, a reporting endpoint should be configured:

add_header Content-Security-Policy "default-src 'self'; report-uri /csp-report;";

This allows for logging and analyzing potential violations, ensuring that CSP remains effective as the website evolves.

The Role of CSP in Web Security

CSP is a crucial security control that significantly reduces the risk of XSS attacks. During penetration testing, weak CSP policies are one of the most common vulnerabilities found.

To maximize security, it is essential to start with a report-only mode to identify potential breakages before enforcement, use nonces and hashes instead of allowing inline scripts, monitor CSP violations for continuous improvement, and avoid unsafe directives such as 'unsafe-inline' and 'unsafe-eval'. Regular reviews and updates to CSP are also necessary to accommodate changes in website content while maintaining strong security controls.

By implementing a well-structured CSP policy, web applications can effectively mitigate a major attack vector, significantly enhancing their security against XSS and other injection-based threats.

Ensuring your web application has a robust CSP policy is crucial for protecting against modern threats. If you need help with penetration testing or strengthening your CSP implementation, our security experts are ready to assist. Contact us now to schedule a consultation and safeguard your digital assets against cyber attacks.