A strict Content-Security-Policy (CSP) is one of the best defenses against cross-site scripting — until an attacker finds a scheme your policy forgot about. The blob: URI is a classic one.

TL;DR

CSP restricts where scripts can load from, but a loose policy can still permit blob: URLs, which an attacker can generate in the page and turn into script execution or a data-exfiltration channel. Lock script-src to 'self' (plus explicit hosts), never allow blob: there, constrain connect-src, and treat CSP as one layer — not the whole wall.

How CSP is supposed to help

CSP tells the browser which sources are allowed for scripts, styles, images, and network calls. A good policy blocks inline scripts and unknown origins, so even if an attacker injects HTML, their script will not run.

Where blob: slips through

blob: URLs are created in the browser from in-memory data. If a policy allows blob: — or is loose enough that a blob can be used as a script source or navigation target — an attacker who already has a limited injection can escalate it into a working exfiltration channel, sending data out despite a "restrictive" policy.

The fix

• Keep script-src to 'self' plus explicit hosts; do not add blob:.
• Constrain connect-src so data cannot be posted to arbitrary origins.
• Remember CSP is defense-in-depth: fix the injection itself (output encoding, framework escaping) rather than relying on the header alone.

We test exactly these bypasses in our web application penetration testing, and Faseel Suite checks your headers and injection surfaces automatically.