Why Content Security Policy without runtime visibility still fails
Content Security Policy (CSP) is one of the strongest browser security controls available.
It is also one of the most misunderstood.
Many organizations believe:
“We have a strong CSP, so client-side attacks are covered.”
This blog explains why CSP alone is not sufficient, how real-world attacks bypass its intent, and what must exist alongside CSP for actual protection.
What CSP Is Very Good At
CSP is excellent at:
- Restricting where scripts load from
- Blocking inline JavaScript
- Preventing obvious XSS injection
- Enforcing high-level execution boundaries
When deployed correctly, CSP eliminates entire classes of basic attacks.
But CSP was never designed to be a complete detection system.
Where CSP’s Protection Ends
CSP controls sources, not behavior.
Once a script is allowed:
- CSP does not inspect what it does
- CSP does not detect logic changes
- CSP does not alert on malicious behavior
- CSP does not validate runtime intent
Trusted code can still behave badly.
Common Real-World CSP Bypass Scenarios
1. Compromised Trusted Script
If a script is:
- Hosted on an allowed domain
- Already permitted by
script-src
CSP will happily allow it — even if the content changes maliciously.
This is the most common breach pattern today.
2. Over-Permissive Exceptions
To “fix” breakages, teams add:
unsafe-inline- Wildcard domains
- Broad
connect-srcrules
CSP still exists — but no longer protects.
This erosion is gradual and rarely revisited.
3. Browser Extensions
Extensions:
- Inject scripts outside CSP
- Operate with elevated privileges
- Bypass page-defined policies
CSP cannot stop extension-driven attacks.
4. DOM-Based Attacks Inside Trusted Code
Even with strict CSP:
- Trusted scripts can misuse DOM APIs
- Unsafe sinks can still be reached
- Tokens can still be exposed
CSP does not enforce data safety.
Why Auditors Are Pushing Back
Auditors increasingly ask:
- How do you know CSP is effective?
- What happens when trusted scripts change?
- How do you detect runtime abuse?
- What evidence shows ongoing control?
A CSP header alone rarely satisfies these questions.
CSP Is Preventive, Not Detective
CSP:
- Prevents some attacks
- Reduces attack surface
- Raises attacker cost
But it does not:
- Detect compromised trust
- Alert on execution drift
- Provide incident timelines
- Prove continuous effectiveness
Modern threats require both prevention and detection.
What Needs to Exist Alongside CSP
A modern CSP strategy must include:
- Strict CSP configuration
No wildcards, no inline exceptions - Trusted Types
To control DOM-based execution - Runtime monitoring
To detect when allowed scripts misbehave - Change detection
To catch drift in script behavior
Without these, CSP becomes a paper control.
How BreachFin Complements CSP
BreachFin does not replace CSP.
It makes CSP meaningful.
BreachFin:
- Monitors what actually executes under CSP
- Detects script behavior changes
- Surfaces execution paths CSP allows but shouldn’t
- Provides evidence when CSP assumptions fail
This closes the gap between policy and reality.
The Most Dangerous CSP State
The worst-case scenario is not:
- No CSP
It is:
- A CSP that exists
- But is silently ineffective
- And creates false confidence
Attackers love this state.
Final Takeaway
CSP is necessary.
CSP is powerful.
CSP is not enough on its own.
If your security posture assumes:
“CSP will stop it”
Without asking:
“What happens when CSP doesn’t?”
Then your most critical attack surface remains unmonitored.
Modern browser security requires:
- Strong preventive controls
- Continuous runtime visibility
- Proof that trust has not been abused
That is where CSP ends —
and where BreachFin begins.
