How to Inspect and Debug Content Security Policy (CSP) Violations in Google Chrome DevTools

Modern web security relies heavily on the Content Security Policy (CSP) HTTP response header to restrict the scripts, styles, images, and frames a web browser can execute or load. When a webpage violates its declared CSP directives, Google Chrome blocks the offending resource and registers diagnostic telemetry. Google Chrome DevTools provides purpose-built panels to inspect these violations, test policy overrides, and trace directive failures directly back to source lines.

Understanding CSP Directives and Violation Types

A Content Security Policy consists of one or more directives sent by the origin server via the Content-Security-Policy or Content-Security-Policy-Report-Only HTTP header. Each directive governs specific resource categories:

• script-src: Governs executable scripts, inline event handlers, and web workers.
• style-src: Restricts external stylesheets, inline <style> blocks, and style attributes.
• connect-src: Regulates outbound network connections initiated by fetch(), XMLHttpRequest, WebSockets, and EventSource endpoints.
• img-src and media-src: Limits image formats, data URIs, audio files, and video streams.
• frame-src and frame-ancestors: Controls child iframe rendering and prevents clickjacking attacks by dictating which parent domains may embed the site.

When code breaches a directive—such as attempting to run an inline <script> tag without a valid cryptographic nonce or hash—Chrome halts the execution and emits a structured violation event.

Inspecting CSP Violations in the Console Panel

The Console panel represents the first diagnostic surface for CSP errors in Chrome DevTools:

1. Open Google Chrome and navigate to the webpage you wish to evaluate.
2. Press Ctrl + Shift + I (Windows/Linux) or Cmd + Option + I (macOS) to launch DevTools.
3. Select the Console panel from the primary tab bar.
4. Examine incoming red warning blocks starting with Refused to load the script... or Refused to execute inline script because it violates the following Content Security Policy directive....
5. Review the specific directive identified in the error string (for example, script-src 'self' https://trustedscripts.example.com).
6. Click the source link displayed on the far right of the console entry to jump directly to the offending inline code block or external network request in the Sources panel.

Auditing CSP Warnings Using the DevTools Issues Panel

While the Console presents raw error logs, the dedicated Issues panel groups CSP violations by severity, aggregates multiple identical instances, and provides remediation guidance:

1. In DevTools, switch to the Issues tab (if hidden, press Esc to toggle the drawer, click the three-dot drawer menu, and choose Issues).
2. Locate the Content Security Policy (CSP) Violation category header and expand it.
3. Review the nested breakdown:
   • Inline Violation: Triggered when inline scripts or styles lack a matching SHA-256 hash or nonce.
   • Eval Violation: Triggered when scripts call eval(), Function(), or setTimeout("string", ...) without the 'unsafe-eval' directive.
   • URL Violation: Triggered when an asset attempts to load from an unlisted third-party domain.
   • Trusted Types Violation: Triggered when DOM-based injection sinks receive untyped string values instead of policy-approved TrustedHTML wrappers.
4. Click the link under Resource to view the exact blocked URL, DOM element, or initiator script stack trace.

Verifying CSP Response Headers in the Network Panel

To confirm whether the active document enforces or merely monitors CSP rules:

1. Navigate to the Network panel in DevTools and refresh the page (Ctrl + R or Cmd + R).
2. Select the primary document request (typically the HTML root file listed first).
3. In the right-hand inspection drawer, select the Headers sub-tab.
4. Scroll down to the Response Headers section.
5. Locate either:
   • content-security-policy: Active enforcement mode where violations are actively blocked.
   • content-security-policy-report-only: Reporting mode where violations are logged and transmitted to reporting endpoints without interrupting user page execution.
6. Inspect the report-to or report-uri parameters to identify the backend log collector ingesting live client violations.

Testing Policy Changes with Local Header Overrides

Chrome DevTools allows web developers and system administrators to test proposed CSP modifications locally without altering web server configuration:

1. In the Network panel, right-click the primary document request and choose Override headers.
2. Select a local directory on your disk when prompted and click Allow in the top security banner to grant Chrome write permissions.
3. Under the document’s Response Headers, hover over the existing content-security-policy header and click the pencil edit icon (or click Add header if none exists).
4. Adjust your directive string—such as appending a new content distribution domain or introducing a cryptographic hash.
5. Reload the webpage. DevTools will substitute the local header override and instantly validate whether the CSP violation clears cleanly.