Learn · CSP fundamentals

What is a Content Security Policy?

A Content Security Policy is a browser-enforced allowlist that tells the browser which origins are permitted to serve scripts, styles, frames, fonts, images, and other subresources for a given page. It is one of the highest-impact, lowest-cost defenses you can add to a modern web application.

The short version

A CSP is delivered as an HTTP response header (or a <meta> tag) that lists rules per resource type. When the browser parses the page, it checks every subresource request against the policy. If the request doesn't match an allowed source, the browser blocks it and — if you configured a reporting endpoint — sends back a structured violation report.

The policy is a defense-in-depth layer. Even when application code or a third-party dependency contains a vulnerability, the browser refuses to execute or load resources outside the allowlist. That refusal is what turns a would-be cross-site scripting incident into a logged violation you can investigate.

Authoritative references: W3C Content Security Policy Level 3 · MDN CSP guide

What CSP actually stops

CSP is not a silver bullet — it does not patch the underlying bug — but it dramatically raises the cost of exploiting common browser-side weaknesses.

  • Cross-site scripting (XSS)

    Attackers inject script into a page that the browser then executes with full access to the user's session. CSP blocks unauthorized script origins and disables inline execution unless you explicitly allow it.

  • Supply-chain compromise

    A trusted third-party tag — analytics, a chat widget, an A/B testing snippet — is silently swapped or hijacked. CSP narrows the set of origins permitted to load executable code so a compromised vendor can't pivot to your users.

  • Clickjacking and frame abuse

    An attacker embeds your site inside a hostile iframe to trick users into clicking actions they didn't intend. The frame-ancestors directive controls who is allowed to render your pages.

How a Content Security Policy works

  1. 1

    Server sends the policy

    Your origin server (or CDN, edge worker, or framework) attaches a Content-Security-Policy response header to each HTML response.

  2. 2

    Browser parses and enforces

    Each directive maps to a resource class. As the page loads scripts, styles, images, and frames, the browser compares each origin against the matching directive.

  3. 3

    Disallowed loads are blocked

    Anything outside the allowlist is refused at the network layer — before script execution, before pixel rendering, before frame navigation.

  4. 4

    Violations report back

    If a report-to or report-uri endpoint is configured, the browser POSTs a structured JSON report describing the directive, the blocked URI, the document URL, and the source line. Consepo ingests these into grouped, reviewable streams.

The directives you'll touch most often

A CSP is a series of directives separated by semicolons. Each directive controls one resource class. Below are the ones that appear in nearly every real-world policy.

default-src
Fallback for any fetch directive you don't explicitly set. Most policies start with default-src 'self' and then loosen specific directives.
script-src
Controls where executable JavaScript can come from. The single most important directive for XSS prevention.
style-src
Controls stylesheet origins and whether inline style attributes are allowed.
img-src
Restricts image origins. Useful for blocking tracking pixels you don't intend to allow.
connect-src
Controls fetch, XHR, WebSocket, and EventSource targets — i.e. where your code is allowed to talk to.
frame-ancestors
Controls which origins are permitted to embed your site in a frame. Replaces the older X-Frame-Options header.
report-to / report-uri
Tells the browser where to send violation reports. Without this you get no visibility into what your policy is blocking.

Want the full directive reference? Read the directive guide.

What a real header looks like

Here's a minimal but useful starter policy for an application that serves its own scripts, loads fonts from Google, and reports violations back to Consepo:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data:;
  frame-ancestors 'none';
  report-to csp-endpoint;

Real applications almost always need more. The point of starting small is to deploy in Report-Only mode, watch what breaks, and grow the allowlist with evidence rather than guesswork.

Why CSP matters for the business, not just the browser

A Content Security Policy is one of the few security controls that produces visible, auditable evidence on every page load. That makes it a useful artifact well beyond the security team.

  • Reduce breach blast radius

    When a vendor is compromised or a developer ships an unsafe inline script, a strict CSP narrows the impact from a full account takeover to a single blocked request.

  • Document your security posture

    Auditors, SOC 2 reviewers, and security-rating tools like BitSight and SecurityScorecard expect explicit control over executable content. A deployed CSP is concrete evidence.

  • Catch drift before users do

    Report-Only mode plus monitoring turns silent third-party changes into actionable signal — you find out when a tag manager pushes a new pixel, not when a customer reports a console error.

14-day Pro trial

Try Consepo Pro free for 14 days

Real-time violation monitoring, multi-platform exports, team collaboration, and unlimited scans. No credit card required to start.

Start your 14-day trialCompare plans

Keep reading