What is the "CSP Unblock" extension and how do I use it?

The "CSP Unblock" add-on is designed to simplify the execution of inline and remote JavaScript on web pages restricted by Content-Security-Policy (CSP) headers. By removing CSP-related headers, it also eliminates restrictions on cross-origin resource access. To use it, enable the extension from the toolbar and refresh the page to apply the changes.

By default, the extension is disabled. To bypass Content-Security-Policy during website testing, activate it by clicking the action button once. When enabled, it applies network rules to strip all CSP-related headers from main-frame and sub-frame requests, removing CSP restrictions from web pages.

What's new in this version?

Please check the Logs section.

Which CSP-related headers does the extension support?

At this moment, the extension supports the following headers that control the CSP or reporting API of the web pages:

• Content-Security-Policy
• Content-Security-Policy-Report-Only
• X-Content-Security-Policy
• X-Content-Security-Policy-Report-Only
• X-WebKit-CSP
• X-WebKit-CSP-Report-Only
• Report-To
• Reporting-Endpoints

What is the Content Security Policy (CSP) header, and why do websites implement it?

The Content Security Policy (CSP) header is an extra security layer designed to detect and prevent certain types of attacks, such as Cross-Site Scripting (XSS) and data injection. It helps safeguard websites by defining which resources are trusted and controlling how content is loaded.

CSP is fully backward compatible. Browsers that don't support CSP can still interact with servers that implement it, and servers can function with browsers that lack CSP support. If a browser doesn't recognize CSP, it ignores the header and applies the standard same-origin policy for web content. Similarly, if a website doesn't provide a CSP header, browsers default to the traditional same-origin policy.

What is the "Content-Security-Policy-Report-Only" HTTP header?

The HTTP Content-Security-Policy-Report-Only response header enables web developers to test security policies by observing their effects without enforcing them. Violation reports, formatted as JSON documents, are sent via an HTTP POST request to a designated URI for analysis.

What is the "X-Webkit-CSP" HTTP header?

The X-Webkit-CSP header is a deprecated HTTP response header that was used to define a Content Security Policy (CSP) specifically for WebKit-based browsers, such as older versions of Safari and Chrome. It served as an early, vendor-specific implementation of CSP before the standardized Content-Security-Policy header became widely adopted.

It allowed web developers to specify a set of rules to control which resources (e.g., scripts, images, stylesheets, or iframes) a browser could load or execute on a webpage. Its primary purpose was to enhance security by mitigating risks like cross-site scripting (XSS), clickjacking, and other code injection attacks.

By defining a policy, the header restricted the sources from which content could be loaded, ensuring only trusted resources were allowed. For example, it could:

• Restrict scripts to run only from the same domain as the website.
• Block inline JavaScript or CSS unless explicitly allowed.
• Limit external resources (e.g., images or fonts) to specific trusted domains.

Example

A server might include a header like this:

X-Webkit-CSP: default-src 'self'; script-src 'self' https://trusted.example.com; img-src 'self' https://images.example.com;

This policy would:

• Allow resources (default-src) only from the same origin ('self').
• Permit scripts (script-src) from the same origin and trusted.example.com.
• Allow images (img-src) from the same origin and images.example.com.

What is the meaning of "Reporting API" and why they are grouped under a sub-menu?

These are often confused as CSP headers but are separate (related but not CSP itself):

• Report-To: Used by CSP via report-to directive
• Reporting-Endpoints: Newer replacement for Report-To (Reporting API v1)