Learn & bypass Content Security Policy HTTP Response Header

Content Security Policy (CSP) plays a crucial role in securing websites by restricting where resources can be loaded from. However, developers often face challenges when testing or debugging sites due to CSP restrictions.

This article discusses the importance of CSP, common bypass techniques, and practical ways to bypass CSP for testing purposes

What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a browser security feature that helps protect websites from attacks like XSS and clickjacking. It specifies trusted sources for content such as scripts, images, and styles, ensuring only safe resources are executed.

A CSP can be set using either a HTTP header or a meta tag in the HTML document. When implemented, it tells the browser which sources are trusted for loading resources, and any content that doesn’t meet these conditions is blocked.

For example, a CSP header might look like this:

Content-Security-Policy: script-src 'self' https://trustedscript.com; object-src 'none';

This directive tells the browser to:

• Allow scripts only from the same origin (‘self‘) and from trustedscript.com.
• Block all object resources (e.g., Flash, Java applets) by setting object-src to ‘none‘.

Why is CSP Important?

CSP is crucial for improving the security posture of web applications by:

• Mitigating XSS Attacks: By preventing the execution of unauthorized scripts from unknown sources, CSP reduces the risk of cross-site scripting vulnerabilities.
• Blocking Inline Scripts: CSP can block inline scripts (e.g., those in HTML <script> tags), making it harder for attackers to inject malicious code.
• Enhancing Site Integrity: By defining trusted sources for content, CSP ensures that the integrity of the web page is maintained and unauthorized changes are prevented.

CSP is a defense layer that helps secure websites against common client-side attacks, making it an essential tool in modern web application security.

Example of Content Security Policy

A Content Security Policy (CSP) is typically implemented via an HTTP response header or a meta tag. It defines which content is allowed to be loaded on a web page and from which sources.

For example, the following CSP header allows scripts only from the same origin and from a trusted domain, while blocking inline scripts and external styles:

Content-Security-Policy: script-src 'self' https://trustedscript.com; object-src 'none'; style-src 'self';

In this example:

• script-src ‘self’: Allows scripts only from the same origin and trustedscript.com.
• object-src ‘none’: Disables all embedded objects (like Flash or Java applets).
• style-src ‘self’: Restricts styles to the same origin only, preventing external style loading.

By enforcing a policy like this, CSP helps mitigate common attacks such as XSS by preventing the execution of unauthorized scripts.

Key CSP Directives

Content Security Policy uses several directives to define what types of content are allowed and from where. The most commonly used CSP directives include:

1. script-src: Specifies valid sources for JavaScript. It can restrict inline scripts or define allowed domains for loading scripts.
2. style-src: Specifies valid sources for stylesheets. It controls where styles can be loaded from, such as from the same domain or trusted external sources.
3. default-src: Sets the default source for content like images, frames, and fonts. This is the fallback when no specific directive is provided.
4. object-src: Defines allowed sources for plugins or embedded content, such as Flash or Java applets. Often set to ‘none‘ for security.
5. img-src: Specifies where images can be loaded from.
6. connect-src: Defines valid sources for AJAX requests, WebSockets, or Fetch API calls.
7. frame-ancestors: Specifies which sources can embed the page in an iframe, protecting against clickjacking.

Some Common CSP Misconfigurations

While Content Security Policy (CSP) is a powerful security feature, improper configuration can leave a website vulnerable to attacks. Some common CSP misconfigurations include:

1.  Allowing inline scripts (‘unsafe-inline‘) in a CSP rule can open the door to Cross-Site Scripting (XSS) attacks. It enables attackers to inject malicious scripts directly into the page, bypassing the restrictions.

Example:

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

2.  Wildcards like * in directives can make the policy too permissive, potentially allowing malicious resources to be loaded from untrusted sources. It’s important to avoid broad rules and define specific trusted domains.

Example:

Content-Security-Policy: script-src *;

3. The default-src directive sets a fallback for content not explicitly defined in other directives. Using a broad source, like *, weakens the policy by allowing content from untrusted sources.

Example:

Content-Security-Policy: default-src *;

Allowing styles from untrusted domains can open up a vector for CSS-based attacks. It is important to only allow styles from trusted sources or from the same origin.

Example:

Content-Security-Policy: style-src 'self' https://untrustedstyles.com;

5. CSP allows the specification of a reporting endpoint to collect violation data. Not using this feature means missing out on important security alerts that can help identify and mitigate issues early.

Example:

Content-Security-Policy: report-uri /csp-violation-report-endpoint;

Techniques for Bypassing CSP

Content Security Policy (CSP) is a critical security mechanism used to prevent attacks like Cross-Site Scripting (XSS) and data injection. However, in some testing scenarios, web developers may need to bypass CSP restrictions to test changes, troubleshoot issues, or work with third-party services.

Below are several techniques for bypassing CSP:

1. Exploiting JSONP Endpoints

JSONP (JSON with Padding) is a technique for overcoming same-origin policy restrictions in web browsers. It allows a script to be loaded from an external domain, bypassing CSP restrictions.

• How it works: JSONP exploits a script tag to load data from a different domain and then wraps the data in a function call. Since the data is wrapped in a script, it can bypass many CSP policies.
• Common Usage: Used by some APIs for cross-origin requests, but can be exploited if not properly secured.

Example:

<script src="http://example.com/data?callback=myFunction"></script>

2. Leveraging Open Redirects

Open redirects are vulnerabilities where a website allows users to redirect to any URL, including malicious ones. Attackers can exploit this feature to load scripts from unauthorized sources, bypassing CSP restrictions.

• How it works: Attackers can manipulate URLs or form parameters to redirect to malicious scripts.
• Mitigation: Ensure proper validation of URLs and restrict redirect sources to trusted domains.

3. Using Form Hijacking

Form hijacking occurs when an attacker gains control of a form submission, causing the form to send data to an external or malicious server. This technique can be used to bypass CSP policies that restrict where forms can submit data.

• How it works: By manipulating the form action URL, attackers can redirect form submissions to external domains.
• Mitigation: Proper validation of form action URLs and usage of CSP’s form-action directive can prevent this.

4. Bypassing CSP with iframe and srcdoc

CSP can restrict the loading of content in iframes by specifying allowed sources. However, certain vulnerabilities can allow attackers to use iframes with the srcdoc attribute, bypassing these restrictions.

• How it works: The srcdoc attribute allows you to define an HTML document directly in the iframe tag, potentially bypassing CSP restrictions on loading external content.
• Mitigation: Restrict iframe sources using the frame-ancestors directive and use sandbox attributes for additional security.

5. Bypassing CSP Using Requestly

Requestly provides a simple solution for developers needing to bypass CSP headers during testing. It allows users to intercept and modify network requests directly in the browser, making it easier to test local changes on live websites or bypass CSP without permanent configuration changes.

How Requestly helps:

1. Modify Headers: Use Requestly’s Modify Headers Rule to remove or modify the CSP header from the response, allowing unrestricted script loading during testing.
2. Inject Scripts: Easily inject custom scripts into live websites for testing without triggering CSP errors.
3. Redirect Requests: Swap production scripts with local scripts using Requestly’s Redirect Rule, effectively bypassing CSP restrictions.

Example:

1. Install Requestly on your browser.
2. Open Rules and create a Modify Headers Rule to remove the CSP header.
3. Reload the page to bypass the CSP restriction and proceed with testing.

By using Requestly, developers can speed up their testing process by bypassing CSP without needing to modify server configurations or deal with CSP issues during development.

Testing and Identifying CSP Vulnerabilities

To ensure CSP is properly configured, it’s essential to test for vulnerabilities using tools and techniques:

• CSP Evaluator: A Google tool to identify weaknesses in CSP configurations and suggest improvements.
• Burp Suite: A security testing tool that scans CSP misconfigurations and potential bypasses.
• Manual Testing: Inspect CSP configurations in browser developer tools to find permissive policies.
• Automated Scanners: Use tools like ZAP Proxy and Qualys to detect CSP vulnerabilities.

Best Approach:

• Regularly audit CSP configurations for misconfigurations or overly permissive policies.
• Test in real user conditions to ensure effective protection against attacks like XSS and clickjacking.

Best Practices for Strengthening CSP

Strengthening Content Security Policy is essential to ensure web applications are secure and protected from attacks.

The following best practices can help strengthen your CSP configuration:

1. Disallow unsafe-inline and unsafe-eval: Avoid allowing inline scripts and unsafe evaluations, as these make your site vulnerable to XSS attacks. Always prefer external scripts and use nonces or hashes for inline scripts.

Example:

Content-Security-Policy: script-src 'self' 'nonce-<random>';

2. Define a Strict default-src Directive: The default-src directive is a fallback for all types of content. Restrict it to trusted domains and avoid using wildcards (*), which can allow content from untrusted sources.

Example:

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

3. Block External Content from Untrusted Sources: Always specify trusted sources for all content types, such as images, scripts, and styles, by using specific domains rather than allowing wildcard access.

Example:

Content-Security-Policy: img-src 'self' https://trustedimages.com;

4. Regularly Update and Review CSP:  Regularly review your CSP configuration and adapt it based on new threats. Implement a report-uri or report-to directive to collect violation reports and monitor potential CSP issues in real-time.

Example:

Content-Security-Policy: report-uri /csp-violation-report-endpoint;

Talk to an Expert

Conclusion

CSP is a powerful defense against threats like XSS and clickjacking, but it’s only effective when configured correctly. Regular testing, updating policies, and using best practices like disallowing unsafe-inline scripts and using nonces or hashes are essential.

Tools like Requestly can speed up testing by bypassing CSP restrictions, allowing for efficient development while maintaining security. Regular audits and real-time monitoring ensure CSP remains robust against emerging threats.