CSP vs. SRI vs. Monitoring: Which Third-Party Script Control Do You Need?
By CellWall Security Research | Published September 29, 2026 | Client-Side Security | 14 min read
On this page
- The Three Controls in One Table
- What CSP Prevents—and What It Does Not
- What SRI Prevents—and What It Does Not
- What Monitoring Detects—and What It Does Not
- Which Control Handles Each Failure?
- CSP Hashes and SRI Hashes Are Related, Not Interchangeable
- Five Common Deployment Patterns
- A Practical Layered Example
- Deploy the Layers in Eight Steps
- Control Selection Checklist
- Where SiteWall Fits
- Frequently Asked Questions
- Layer Prevention, Integrity, and Visibility
Reading Progress
0%
14 min left
Use CSP, SRI, and monitoring for different jobs. CSP restricts which code and connections the browser permits. SRI verifies that an eligible external script or stylesheet exactly matches approved bytes. Monitoring observes what loads, changes, fails, and behaves unexpectedly over time. They overlap at the edges, but none replaces the other two.
The wrong question is, “Which one is best?” The useful question is, “Which failure are we trying to prevent or detect?” A strong browser supply-chain program maps each control to a specific failure mode, then combines them around sensitive journeys.
That distinction matters because an allowed origin can serve changed code, an integrity-pinned file can still perform dangerous approved behavior, and a monitoring alert can arrive after affected sessions have already run. These gaps often connect a JavaScript supply chain compromise to website data exfiltration. Start with a complete JavaScript inventory, then choose layers deliberately.
The Three Controls in One Table
| Dimension | Content Security Policy | Subresource Integrity | Runtime monitoring |
|---|---|---|---|
Primary job | Restrict browser actions and permitted sources or destinations | Verify fetched content matches expected bytes | Observe availability, resources, relationships, destinations, and behavior over time |
Control type | Preventive enforcement, with optional reporting | Preventive integrity check | Detective; response may trigger separate containment or enforcement |
Decision granularity | Directive, nonce, hash, scheme, host, path, or policy expression depending on the directive | Exact resource representation matched to integrity metadata | Observed resource, provider, journey, dependency, destination, content, or behavior |
Best fit | Controlling executable entry points and browser destinations across a site | Stable, versioned external scripts and stylesheets | Dynamic providers, indirect dependencies, behavior drift, failures, and coverage validation |
Browser blocks? | Yes, when an enforced policy disallows the action | Yes, when eligible content fails integrity verification | Not by monitoring alone |
Handles legitimate updates | Usually continues to allow updates from an allowed source | Requires new integrity metadata when bytes change | Detects and helps teams assess the change |
Main blind spot | Allowed code or destinations can still be harmful | Matching code can still be insecure or over-privileged | Detection does not guarantee prevention |
Operational risk | A narrow or inaccurate policy can break required journeys | A legitimate provider update can be blocked | Poor coverage or noisy alerts can hide meaningful changes |
CSP answers may this load or connect? SRI answers are these the expected bytes? Monitoring answers what actually happened, and did it change? Treating those questions as interchangeable creates predictable gaps.
What CSP Prevents—and What It Does Not
Content Security Policy is delivered through an HTTP response header and enforced by the browser. Directives can restrict script execution, connections, frames, form destinations, workers, styles, images, and other resource types. Nonces and hashes can create narrowly trusted script entry points instead of relying only on broad host allowlists.
| CSP can | CSP cannot prove |
|---|---|
Block scripts from sources or execution paths that the policy does not authorize | That an allowed script is unchanged, secure, necessary, or privacy-compliant |
Reject many inline scripts, inline handlers, and string-to-code patterns under a strict policy | That the application has no XSS or dangerous DOM data flow |
Restrict outbound browser connections with | That data sent to every allowed endpoint is appropriate |
Generate violation reports in Report-Only or enforcement mode | That a reported violation is an attack or that unreported behavior is harmless |
Reduce the usable paths available to injected code | That a trusted script cannot misuse the privileges it already has |
A hostname allowlist is not an integrity guarantee. If https://vendor.example is allowed, CSP normally permits the content that origin serves within the policy's rules. Use narrower trust expressions where practical and add integrity or monitoring for content change.
What SRI Prevents—and What It Does Not
Subresource Integrity places cryptographic integrity metadata on supported resource elements. The browser hashes the fetched representation and compares it with the expected value before using the resource. If the strongest supported metadata does not match, the resource is rejected.
<script
src="https://cdn.example.com/library-4.2.1.min.js"
integrity="sha384-BASE64_DIGEST_FROM_YOUR_RELEASE_PROCESS"
crossorigin="anonymous"
defer
></script>| SRI can | SRI cannot |
|---|---|
Block an eligible resource when its fetched bytes differ from the approved digest | Decide whether the approved bytes are safe or perform an acceptable purpose |
Reduce exposure to a compromised CDN or provider serving altered content at a pinned URL | Protect scripts that were not given integrity metadata |
Make a reviewed version explicit in markup | Automatically approve legitimate vendor changes; the digest must be updated deliberately |
Protect supported external script and stylesheet fetches | Inventory every dynamically loaded dependency or destination introduced by that code |
Work alongside CSP | Replace HTTPS, CSP, secure development, vendor review, or monitoring |
SRI is most practical when a resource is versioned and immutable. Cross-origin integrity-protected fetches use CORS, so the provider must return an appropriate Access-Control-Allow-Origin response. A vendor that changes bytes at one stable URL creates either outages or pressure to bypass the control.
What Monitoring Detects—and What It Does Not
Third-party JavaScript monitoring compares delivered browser activity with an approved or expected baseline. Depending on the implementation, it can observe availability, response changes, initiator chains, new resources, destinations, browser access, errors, timing, and behavior across tested or real sessions. For the detective layer in detail, compare JavaScript hash monitoring with behavioral monitoring.
| Monitoring can | Monitoring cannot guarantee |
|---|---|
Reveal that an allowed provider changed code, dependencies, destinations, or behavior | That a harmful change was blocked before execution |
Detect failures and performance degradation that CSP and SRI do not explain | Complete visibility into every user, browser state, frame, worker, or encrypted payload |
Find indirect and fourth-party resources introduced at runtime | That every observed resource has a valid business purpose or lawful basis |
Correlate change with pages, journeys, providers, and time | That every deviation is malicious or every unchanged script is safe |
Support investigation, approval, and containment workflows | Effective response without owners, severity rules, evidence retention, and a tested disablement path |
CSP violation reports describe actions that conflict with a policy. They do not provide a complete inventory of allowed activity, prove that approved scripts are unchanged, measure business-function availability, or explain every dependency and data flow. Combine policy telemetry with broader runtime observation.
Which Control Handles Each Failure?
| Failure scenario | CSP | SRI | Monitoring |
|---|---|---|---|
Injected inline script without an authorized nonce or hash | Can block under an enforced strict policy | Does not cover the injected inline code | May observe the resulting resources or behavior, depending on visibility |
Unknown external script from a disallowed origin | Can block | Only applies if the script element has integrity metadata | Can detect the attempted or delivered resource where observable |
Allowed CDN serves modified bytes at a pinned URL | Usually allows the origin | Blocks when the digest does not match | Can alert on content or behavior change |
Vendor legitimately updates a mutable URL | Usually continues to allow it | Blocks until integrity metadata is updated | Can surface the update for review |
Approved script sends data to a new disallowed endpoint |
| Does not govern runtime destinations | Can reveal the new destination or behavior where observable |
Approved script sends inappropriate data to an allowed endpoint | Usually cannot distinguish appropriate from inappropriate payload use | Matching bytes still execute | May identify behavioral or data-flow signals, but privacy review is still required |
Trusted loader adds a new fourth party | May block it, depending on policy design and trust propagation | The loader's valid hash does not pin every resource it later requests | Can reveal the loading relationship and new resource |
Provider is slow, unavailable, or throws an error | May report a violation only when policy is involved | May reject a mismatch but does not measure general service health | Can measure availability, latency, initialization, errors, and journey impact |
First-party bundle contains a compromised dependency | May allow the same-origin bundle | Could pin a separately loaded file, but does not validate internal source provenance | Can help detect delivered content or behavior drift; build security remains essential |
CSP Hashes and SRI Hashes Are Related, Not Interchangeable
Both mechanisms can contain cryptographic hashes, but they answer different policy questions. An SRI digest on a resource element declares which fetched representation is acceptable. A CSP hash source authorizes matching script or style content under the policy's processing rules. Their syntax may look similar while their placement, purpose, and browser processing differ.
Use CSP when you need to
Restrict which script entry points, frames, workers, forms, and network destinations the browser permits.
Reduce exposure to inline injection and dangerous execution patterns.
Apply a page-wide policy with staged reporting and enforcement.
Use SRI when you need to
Pin a stable external script or stylesheet to exact reviewed bytes.
Prevent altered content from a CDN or provider from executing at an expected URL.
Make resource updates an explicit release decision.
Use monitoring when you need to
Observe mutable integrations, runtime dependencies, destinations, performance, errors, and change over time.
Validate whether CSP and SRI coverage matches real journeys and delivery variants.
Investigate drift and drive authorization, response, and removal workflows.
Five Common Deployment Patterns
| Pattern | What it achieves | Remaining gap |
|---|---|---|
CSP only | Blocks disallowed sources and actions | Allowed resources can change or behave unexpectedly without being noticed |
SRI only | Pins selected static resources | Unpinned, inline, dynamic, first-party, and indirectly loaded code remain outside the check |
Monitoring only | Creates visibility into delivered behavior and change | Risk may be detected only after execution unless coupled to prevention or response |
CSP + SRI | Restricts execution paths and pins eligible high-risk assets | Availability, legitimate updates, runtime dependencies, and allowed behavior still need observation |
CSP + SRI + monitoring | Combines policy enforcement, exact-resource integrity, and operational visibility | Still requires secure code, consent and privacy governance, testing, ownership, and incident response |
A Practical Layered Example
For a stable external library, the page can combine a versioned URL and SRI with a CSP that restricts scripts and destinations. The nonce must be unpredictable and unique for each response; the digest must come from a trusted release process rather than from the resource being accepted at runtime.
Reporting-Endpoints: csp-endpoint="https://reports.example.com/csp"
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{RANDOM_PER_RESPONSE}' https://cdn.example.com;
connect-src 'self' https://api.vendor.example;
frame-src https://checkout.vendor.example;
object-src 'none';
base-uri 'none';
report-to csp-endpoint<script
src="https://cdn.example.com/library-4.2.1.min.js"
integrity="sha384-BASE64_DIGEST_FROM_YOUR_RELEASE_PROCESS"
crossorigin="anonymous"
defer
></script>Your required directives and trusted endpoints depend on the application. Test authentication, checkout, consent, support, locale, device, experiment, error, and recovery states in Report-Only before enforcement. Preserve privacy when collecting reports, and do not copy placeholder origins or digests.
Deploy the Layers in Eight Steps
Inventory real browser activity
Map scripts, styles, frames, workers, initiators, dependencies, destinations, owners, purposes, and approved states across representative journeys.
Prioritize by consequence
Start with checkout, authentication, account, payment, and other pages where scripts can reach sensitive data or actions.
Separate stable from mutable resources
Identify versioned assets suitable for SRI and integrations whose content or configuration changes independently.
Design the CSP
Prefer narrow script trust, restrict destinations and frames, remove unnecessary unsafe patterns, and document every exception.
Generate integrity metadata
Create digests from trusted reviewed artifacts, confirm cross-origin CORS behavior, and update markup through the normal release process.
Observe before blocking
Run CSP in Report-Only, baseline resources and behavior, and test required journeys, failure modes, regions, devices, and consent states.
Enforce progressively
Move proven directives and resources into enforcement in bounded stages with owners, rollback, and a tested provider kill switch.
Operate continuously
Review CSP reports, SRI failures, provider drift, dependencies, performance, and inventory mismatches; investigate and tune without silently broadening trust.
Control Selection Checklist
Before implementation
Can the resource be removed, self-hosted, isolated, or replaced with a server-side data flow?
Who owns it, who can change it, where does it execute, and which data and destinations can it reach?
Is the content versioned and immutable enough for SRI, or intentionally mutable?
Which CSP directives govern its execution, connections, frames, workers, forms, styles, and media?
Before enforcement
Have representative journeys and variants been exercised under Report-Only and monitoring?
Are SRI digests generated from trusted artifacts and tested against actual CDN responses?
Are reports deduplicated, privacy-reviewed, retained appropriately, and routed to accountable owners?
Can the team disable the integration or roll back the policy without weakening unrelated protections?
During operation
Reconcile observed resources and behavior with the approved inventory.
Investigate new origins, dependencies, destinations, integrity failures, and meaningful behavior changes.
Review exceptions and remove stale allowlist entries, hashes, nonces, scripts, and vendor access.
Measure business-function health as well as HTTP availability and security telemetry.
Where SiteWall Fits
SiteWall can help teams observe browser-delivered resources, providers, loading relationships, destinations, and behavioral change across captured sessions where browser visibility and application architecture permit. That evidence supports inventory reconciliation, CSP design and validation, investigation of mutable scripts, and detection of gaps that a static configuration review may miss.
SiteWall does not replace CSP enforcement, SRI verification, secure development, privacy and consent analysis, vendor review, or incident ownership. Monitoring is valuable because preventive controls are selective—not because observation turns every allowed action into a safe one.
Validate the Controls Against Real Browser Behavior
Evaluate SiteWall on representative journeys to connect scripts, providers, dependencies, destinations, and behavioral change with your CSP, integrity, and governance decisions.
Frequently Asked Questions
Is CSP better than SRI?
No. CSP restricts permitted execution paths and browser destinations, while SRI verifies that an eligible fetched resource matches expected bytes. Use CSP broadly and add SRI where stable external resources can be pinned.
Does CSP detect when an allowed third-party script changes?
Not generally. CSP can continue allowing changed content from an authorized source. Violation reports describe policy conflicts, not every content change. Use SRI for exact eligible resources and monitoring for broader change visibility.
Does SRI replace CSP?
No. SRI applies only where integrity metadata is provided and supported. It does not restrict inline injection, runtime network destinations, frames, or unpinned resources. CSP provides broader page-level restrictions.
Does monitoring prevent malicious JavaScript from running?
Monitoring alone is detective. It can reveal change or unexpected behavior, but prevention requires controls such as CSP, SRI, isolation, secure development, or a separate enforcement mechanism. Fast alerts and a tested kill switch reduce response time.
Can SRI be used when a vendor updates the same URL frequently?
Technically the integrity metadata can be updated whenever the bytes change, but frequent uncoordinated changes make SRI operationally difficult. Prefer versioned immutable URLs, controlled self-hosting, a different architecture, or strong monitoring and containment for mutable services.
Are CSP hashes the same as SRI hashes?
They may use similar digest syntax, but they serve different mechanisms. SRI verifies the bytes fetched for a resource element. CSP hash sources authorize matching content under CSP processing rules. Configure and test each according to its specification.
Is CSP Report-Only the same as runtime monitoring?
It is one useful form of policy telemetry. It reports CSP violations without enforcing the report-only policy, but it does not provide a complete inventory of allowed resources, provider uptime, all dependencies, or every behavior and destination.
Where should we start?
Start with a browser-derived inventory of scripts on sensitive journeys. Remove unnecessary resources, classify stable assets for SRI, design CSP in Report-Only, baseline runtime behavior, test failure modes, and then enforce progressively with owners and rollback.
Layer Prevention, Integrity, and Visibility
CSP, SRI, and monitoring are strongest when each is assigned the job it can actually perform. CSP narrows permission. SRI pins eligible content. Monitoring exposes operational reality and change. Together they reduce both the opportunity for unauthorized code and the time that allowed-but-dangerous behavior can remain unexplained.
Apply the combination according to risk rather than uniformly. A stable library on checkout may justify CSP, SRI, and close monitoring. A mutable support widget may require CSP, isolation, constrained data access, and monitoring instead. The durable principle is simple: every script needs an owner, an explicit trust boundary, a suitable preventive control, and evidence that the delivered behavior remains acceptable.
Authoritative Sources and Related Guides
Continue exploring
Read the practical guides that clarify the surrounding risks, controls, and evidence.
Explore the client-side security hub
Supply Chain Security
OWASP Subresource Integrity (SRI) Guide: Securing the Supply Chain
An authoritative primer on implementing Subresource Integrity (SRI) to prevent third-party script injection, Magecart attacks, and unauthorized CDN modifications.
Client-Side Security
Third-Party JavaScript Monitoring: Uptime, Updates, and Behavioral Drift
Learn how to monitor third-party script availability, performance, update frequency, dependency changes, and unexpected behavior in the browser.
Client-Side Security
Types of Client-Side Attacks: 12 Browser Threats to Know
Explore 12 common client-side attacks, how they reach the browser, what warning signs to investigate, and which controls can reduce the risk.