How CSPs get bypassed

A policy is only as strong as its weakest source. This lab replays the five bypass patterns that show up most often in real engagements, with editable policy text and a concrete payload under test.

How this works. Pick a real bypass class, edit the CSP and the attacker payload, and the lab decides whether the bypass lands, is blocked, or is merely invisible to operations.

Bypass catalog

Host allowlists trust the entire origin. If that origin serves attacker-controlled JS, the bypass lands.

Reference: PortSwigger, 'Bypassing CSP with JSONP endpoints'

Policy under test

Attacker payload

Bypass lands

Lab findings (1)

criticalBYP01 — JSONP endpoint trusted by host allowlist

The payload host is explicitly or implicitly trusted, so CSP sees it as legitimate script even though the endpoint returns attacker-controlled JavaScript.

fix: Move away from host allowlists for script execution. Prefer nonce + strict-dynamic and remove JSONP-capable hosts.

Baseline CSP analyzer findings

lowCSP11 — No CSP reporting configured

Without report-uri or report-to, CSP violations happen silently. You won't see in-the-wild XSS attempts or accidental policy breakage.

fix: Add a report-to endpoint (modern) or report-uri (legacy). Even logging to your own server is a huge upgrade.

infoCSP12 — upgrade-insecure-requests not set

Optional. If your app may load from a mix of http:// and https:// origins, this directive auto-upgrades requests, blocking mixed content.

fix: Add upgrade-insecure-requests if you serve over HTTPS and may have legacy http:// references.