Content Security Policy, Subresource Integrity, and Outbound Telemetry Against Browser Supply-Chain Attacks

Browser supply-chain risk has multiple control points

A browser can execute code assembled from many sources. The initial document, external scripts, inline scripts, frames, styles, and application programming interface responses combine into one user experience. A weakness in any delivery or authorization path can alter what the browser executes and where data travels.

No single browser control observes the entire problem. Content Security Policy constrains classes of resource and execution behavior. Subresource Integrity verifies selected external resource content before execution. Outbound telemetry records scripts, destinations, and page behavior that actually appear. Each control answers a different question.

Using them together creates a stronger model: define what should be allowed, bind stable external content where practical, observe what happens, and investigate drift. Using one alone leaves predictable gaps.

Content Security Policy defines permitted browser behavior

Content Security Policy is delivered through a Hypertext Transfer Protocol response header or, in constrained cases, document markup. It provides directives that tell the browser which sources and behaviors are permitted for scripts, connections, frames, forms, styles, images, and other resource types. The OWASP Secure Headers Project provides an additional technical reference for response-header behavior and deployment.

A strong policy begins with a restrictive default and adds the smallest required sources. Script policy should avoid broad wildcards and unsafe execution allowances. Connection policy should limit fetch, asynchronous requests, event streams, and related browser connections. Frame and form directives constrain embedded content and submission targets. Object loading can often be disabled.

Nonces or hashes can authorize specific inline scripts without permitting every inline block. A unique nonce should be unpredictable and generated per response. Hash-based authorization can suit stable inline content. Host allowlists are easier to deploy but can be weaker when an allowed host can serve attacker-controlled content.

Report-only deployment allows teams to observe violations before enforcement. It is useful for discovery and tuning, but it does not block prohibited behavior. A mature rollout moves justified directives into enforcement and keeps reporting for visibility.

Content Security Policy can be present and still weak

A header's existence does not prove meaningful protection. A policy can allow every network source, permit unsafe inline execution, omit critical directives, or define a narrow default while overriding it with broad script and connection rules. Duplicate or conflicting policies can also produce behavior that operators misunderstand.

Policy evaluation should therefore inspect directive semantics. Does script execution have a restrictive source model? Are forms constrained? Can frames load from unexpected origins? Are outbound connections broader than the application's documented integrations? Are reporting endpoints configured and functioning?

Violation reports also need context. A browser extension, stale page, malicious attempt, or legitimate application behavior can generate a violation. Reports are evidence of blocked or report-only behavior, not automatically confirmed attacks. Aggregation should preserve page, directive, blocked address category, and time without collecting sensitive document data.

Subresource Integrity binds a resource to expected content

Subresource Integrity allows markup to declare one or more cryptographic digests for a resource. The browser fetches the resource and verifies the body against an accepted digest before execution or application. This is valuable when an external script is expected to remain stable and the page owner can update the digest through a controlled release.

The integrity attribute should be paired with correct cross-origin behavior where required. Algorithms and digests must be current and generated from the exact delivered bytes. A changed resource will stop loading until the page's expected digest is updated.

This failure behavior is both the strength and operational cost of the control. If an external resource changes frequently without version pinning, integrity verification can break the application. Teams may respond by omitting the control, automatically updating digests, or authorizing overly broad versions. Each shortcut reduces the security value.

Subresource Integrity also covers only resources referenced with the mechanism. It does not inventory every dynamically loaded script, constrain all outbound connections, or protect the page markup that declares the digest. A compromised first-party page can replace both the resource address and its expected fingerprint.

Outbound telemetry observes delivered and executed behavior

Outbound telemetry records what the browser or edge actually observes: script sources, inline content fingerprints, authorization state, content changes, cross-origin destinations, form targets, frames, and response posture. It can reveal a changed script even when Content Security Policy allows the source, or a new destination hidden inside a broadly permitted connection policy.

Observation supports inventory and investigation. First-seen and last-seen time show persistence. Baseline comparison reveals change. Page attribution identifies where the resource appeared. Destination counts show whether behavior is isolated or recurring. Alert lifecycle records acknowledgement, accepted risk, reopening, and technical resolution.

Telemetry is not automatic prevention. A browser agent that reports a request generally observes behavior that the browser already attempted or completed. Marking a destination as disallowed in an inventory does not retroactively block the network call. Enforcement belongs in Content Security Policy, application design, routing, or another preventive control.

This boundary should be visible in the interface. Terms such as allow and block can be misleading if they only change triage state. Operators need to know whether an action updates an inventory classification or changes runtime behavior.

How the three controls complement each other

The overlap is intentional. Content Security Policy provides browser enforcement but can be configured broadly. Subresource Integrity provides byte-level verification but only for declared resources. Telemetry provides inventory and drift evidence but may observe behavior after it occurs. Together, they turn trust into a constrained and monitored state.

A secure rollout sequence

1. Inventory current behavior. Observe scripts, frames, forms, and destinations across representative page states.
2. Assign ownership. Identify why each resource exists and who approves changes.
3. Remove unnecessary sources. A smaller browser dependency set is easier to constrain and review.
4. Create a report-only policy. Start from a restrictive target, collect violations, and classify legitimate requirements.
5. Pin stable external scripts. Add Subresource Integrity where the resource lifecycle supports controlled versioning.
6. Enforce policy by page sensitivity. Prioritize authentication, payment, account, and administrative flows.
7. Baseline approved content. Record script fingerprints and response-surface state after review.
8. Alert on drift. Investigate new scripts, changed content, destinations, frames, forms, and weaker headers.
9. Test failure behavior. Confirm that a bad digest prevents execution, a prohibited destination is constrained, and telemetry creates usable evidence.
10. Review continuously. Remove expired sources, rotate approved baselines after investigation, and monitor collection health.

A controlled incident scenario

Consider an authorized script on a checkout page. Its source remains on the Content Security Policy allowlist, but the delivered content changes. The page does not use Subresource Integrity because the script had historically changed without versioned addresses.

Content Security Policy permits the script because the source is allowed. Outbound telemetry detects that the current digest differs from the approved baseline. Browser observations also report a new cross-origin form destination. These two changes raise the investigation priority.

The team confirms there was no approved release, removes the script reference, constrains form targets through policy, restores the prior response, and invokes incident procedures. A later successful observation shows the old baseline and no external form destination, allowing the technical findings to resolve. The team then introduces a versioned resource and Subresource Integrity so future unapproved byte changes fail before execution.

The scenario shows why source allowlisting alone was insufficient, why telemetry alone did not prevent the first attempt, and why byte verification could strengthen the next design.

Metrics for browser control quality

Useful metrics include observed pages, collection freshness, total and authorized scripts, changed authorized scripts, new resources, external destinations, form submissions to external origins, Content Security Policy findings, violation trends, Subresource Integrity coverage, and mean time to disposition.

Always include denominators. Seven scripts with integrity controls is meaningful only alongside the total eligible script count. Zero changed scripts is meaningful only when monitored pages have recent observations. A high violation count may reflect a new attack, an overly strict report-only policy, a broken application release, or one noisy client.

Posture scores can summarize direction, but the calculation and missing inputs must be explainable. If browser telemetry is unavailable, the score should not silently treat the module as clean.

Operational checklist

• Use a restrictive Content Security Policy target rather than copying observed behavior into a broad allowlist.
• Prefer nonces or hashes for justified inline execution.
• Constrain connection, frame, and form destinations, not only scripts.
• Use Subresource Integrity for stable external resources with controlled versioning.
• Inventory dynamic and inline scripts in addition to static external tags.
• Keep authorization separate from observation and preserve approved baselines.
• Do not describe inventory classification as network blocking.
• Test policy, digest, alert, and recovery behavior in a controlled environment.
• Show stale or unavailable collection explicitly.
• Review accepted risk and broad policy sources on a schedule.

Limitations

Content Security Policy can be difficult to deploy on applications with extensive inline code or dynamic resource loading. Subresource Integrity can disrupt resources that change without stable versioning. Browser telemetry can be incomplete because of privacy controls, blocked agents, caching, execution paths, or network failure.

These controls do not protect a compromised browser, every extension, the underlying build pipeline, or insecure application logic. They also do not determine whether an observed destination is legitimate without ownership and business context.

Conclusion

Browser supply-chain defense needs both a rule and a record. Content Security Policy defines where and how the browser may act. Subresource Integrity binds selected resources to reviewed content. Outbound telemetry records the scripts, destinations, and changes that appear in real page behavior.

None is complete alone. Used together, they make browser trust narrower, observable, and reviewable, while giving teams evidence to move from unexpected change to preventive improvement.

Where Vorpcel Fits

Vorpcel Outbound Control evaluates Content Security Policy and response posture, inventories scripts and approved baselines, observes browser destinations, and detects response-surface drift. Its enforcement boundary remains explicit: browser headers constrain behavior, while telemetry and triage records explain what was observed and what requires investigation.