They should see suspicious execution blocked or alerted on, tampering attempts detected in real time, and unauthorized script changes prevented from persisting into user sessions. If the controls only report after compromise or cannot distinguish approved code from altered code, they are not providing meaningful assurance.
How client-side integrity controls prove they are working
Teams should look for live enforcement, not just telemetry. A control is doing real work when it stops suspicious script execution, detects tampering as it happens, and prevents altered code from becoming the version a user actually runs. If the only signal arrives after compromise, the control is closer to reporting than protection.
That distinction matters because client-side integrity controls often sit in the execution path of web sessions. Their job is to preserve trust in the browser-delivered code path, so the evidence of success should be visible in blocked behavior, trustworthy alerts, and code state that stays consistent from delivery through runtime.
For teams validating these controls, the practical question is whether the control can still distinguish approved code from modified code under realistic conditions. If a benign update, injected snippet, or tampered resource all look the same to the detector, the control will either miss abuse or generate noise that weakens operator confidence.
What to observe during validation and testing
Validation should focus on what happens when code integrity is challenged. Good controls trigger when a script hash changes, a source is replaced, a browser resource is rewritten, or execution is diverted from an approved path. In SLSA terms, the strongest assurance comes from traceable provenance plus runtime checks that make unauthorized changes harder to hide.
Teams should also test failure modes, not only happy paths. That means confirming whether the control still detects tampering after a rollout, after cache refresh, after dependency injection, and after a content delivery change. If the integrity mechanism only works in one deployment pattern, it may be too fragile to trust at scale.
Evidence should include both alert fidelity and enforcement fidelity. A useful control does not merely flag an event, it separates approved from altered code in a way operators can act on. That is why frameworks and implementation guidance around software and artifact integrity, including the CISA Known Exploited Vulnerabilities Catalog and secure build practices, are often part of the broader assurance story.
Why teams still get false confidence
Client-side integrity controls fail when teams confuse visibility with prevention. A tool that logs a suspicious change but lets the altered script continue running has not protected the session. A tool that blocks only after the user interaction is complete may still leave room for credential capture, UI manipulation, or data exfiltration.
Another common failure is treating all tampering as equal. Some changes are expected, such as approved releases and sanctioned third-party updates. Others are hostile, such as inline script injection, DOM rewriting, or unauthorized dependency replacement. If the control cannot make that distinction consistently, it creates either blind spots or alert fatigue.
For browser-delivered applications, supply-chain and delivery trust also matter. If approved content can be swapped upstream, the client-side control may simply be measuring the wrong boundary. That is why integrity testing should include the code source, delivery channel, and runtime enforcement point as one chain, not as separate checks.
Risk and Threat Considerations
Client-side integrity controls are exposed to evasion, race conditions, and late detection. An attacker only needs a brief window to alter page behavior, rewrite a form, or inject malicious logic if the control validates too late or only observes after execution.
Failure mechanism: The control either checks integrity after the browser has already executed altered code, or it cannot reliably differentiate an approved resource from a modified one across caching, dynamic rendering, and third-party script loading.
Impact: Users can interact with untrusted code, which can lead to session abuse, data theft, form manipulation, or silent compromise of the client-side trust boundary even when an alert is eventually generated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Client-side integrity depends on trusted artifact provenance and verified delivery. |
| Recommendation — Use SLSA provenance and verification to reduce unauthorized code modification before runtime. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Client-side integrity relies on secure code handling and resistance to unauthorized modification. |
| Recommendation — Apply application software security practices to verify code integrity before release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Runtime integrity controls depend on secure architecture that resists script tampering. |
| Recommendation — Design client-side code paths to detect and resist unauthorized modification. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity controls must detect and respond to unauthorized code changes. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Validation needs evidence that suspicious execution is detected and reviewable. | |
| Recommendation — Implement integrity checks that detect and block unauthorized software changes. Review integrity alerts promptly and tie them to enforcement outcomes. | ||
Practitioner Guidance
What to verify: Prove that the control blocks or quarantines altered code before it can influence user actions, and confirm that the alert path is distinct from the enforcement path. If the same event is merely logged for later review, treat the control as monitoring, not integrity enforcement.
What good looks like: Approved code loads cleanly, unexpected changes fail closed or are explicitly challenged, and operators can show evidence that the control is sensitive to real tampering but stable during normal releases. For OpenSSF aligned programs, that usually means pairing code provenance and verification with runtime checks that reflect the browser execution model.
Practitioner takeaway: A client-side integrity control is working only if it changes the outcome of tampering, not just the visibility of tampering. If it cannot prevent modified code from becoming the live session state, it is not providing meaningful assurance.
Related resources from NHI Mgmt Group
- How do security teams know whether update integrity controls are actually working?
- How can security teams know if cache integrity controls are actually working?
- How do teams know whether release integrity controls are actually working?
- How do teams know if identity security controls are actually working?