Who Got In Versus What Is Running: Two Integrity Problems One Control Cannot Solve

Access control and client-side script monitoring both get filed under "integrity", and they answer unrelated questions. One asks whether the party making a request should be allowed to make it. The other asks whether the code running in your visitor's browser is still the code you intended. A team can be excellent at the first and completely blind to the second, and attackers who skim payment and login forms count on exactly that.

Problem one: is this requester who they claim to be?

The older model of access trusted location. If a request came from inside the network, by office cable or VPN, it was allowed to reach whatever the network could reach. The flaw is well understood by now: one stolen laptop or one phished VPN credential gives an intruder the same broad reach as an employee.

Zero Trust replaces location with a per-request decision. Each application sits behind a policy check. To get through, the requester has to prove identity, and often more than identity.

In Cloudflare's stack the main pieces are:

• An access proxy in front of each application. It sends the user to your identity provider, receives the result, and evaluates a policy before any request reaches the application. The application itself can be an internal tool with no login of its own.
• Policies written per application. Typical conditions: membership of a group in the identity provider, a specific authentication method (a hardware key for the finance system, say), country, and device posture.
• Device posture. An agent on the device reports facts such as disk encryption, operating system version and the presence of endpoint protection. A valid password from an unmanaged laptop can then be refused.
• Outbound-only tunnels. A small connector inside your network dials out to the edge. The application needs no inbound firewall opening and no public address, which removes it from internet scans altogether.
• Non-human identities. Service tokens and mutual TLS let machines authenticate under the same policy engine, so CI jobs and partner systems are not a side door.
• Short sessions and a log of every decision. Access is re-evaluated regularly, and each allow or deny is recorded with the identity attached.

What you gain is narrow, attributable access. A contractor sees the one tool they need and cannot even resolve the others. Removing someone from a group in the identity provider removes their access everywhere at once.

Where Zero Trust is commonly left half done

• The policy says "anyone with a company email", which is identity without authorization.
• The origin is still reachable directly by IP, so the proxy can be bypassed.
• Service tokens never expire and are shared between systems.
• The break-glass account is exempt from every control and nobody reviews its use.
• Decision logs are collected and never read.

Problem two: is this page still what we shipped?

Now consider a different scene. A customer opens your checkout page. They are a real person on their own phone. Every access control you have is satisfied, because the page is public and they are welcome.

The page loads your own JavaScript, plus an analytics tag, a chat widget, an A/B testing snippet, a consent banner, a fraud tool and a tag manager that loads four more. Each one runs with full access to the page. Any of them can read what is typed into the card number field and send it anywhere.

One of those vendors gets compromised, or a domain it once used lapses and is bought by someone else, or a dependency deep in its build changes. The script served to your visitors now contains a few extra lines. Your servers never see it. Your WAF never sees it, because the malicious code is delivered from a third party directly to the browser and the stolen data leaves from the browser directly to the attacker. Your deployment pipeline shows no change, because you did not deploy anything.

This is the client-side supply chain problem, widely known through payment skimming attacks on online stores. Its defining property is that the page changed without your release process being involved.

What script monitoring adds

Cloudflare's client-side monitoring product, long known as Page Shield, addresses this from the edge. Described generally, it works by having visitors' browsers report what they loaded. The edge adds a reporting-only content security policy header to your pages, browsers send back reports of scripts and connections, and the service builds an inventory from them. No change to your application is needed to start.

From that inventory you get:

• A list of every script actually running, including the ones loaded by other scripts, which is almost always longer than the list anyone has written down.
• The pages each script appears on, so you can ask why a marketing tag is on the payment page.
• Alerts on change: a new script, a new domain, and on higher tiers a change in a known script's content or a match against threat intelligence.
• Outbound connections, which is where a skimmer reveals itself by sending data to an unfamiliar host.

Be clear about what this is. In its basic form it is detection, not prevention. It does not stop a vendor from changing their script. It shortens the time between the change and your knowing about it, from "a researcher emailed us months later" to "we were alerted that day and pulled the tag". On higher tiers, the same product can enforce an allowlist by generating a blocking policy, which moves it toward prevention.

The browser-native controls it complements

Monitoring is strongest alongside two standards you can adopt on any platform:

• Content Security Policy in enforcing mode restricts which sources may run scripts and where the page may send data. A strict connect-src and script-src on payment and login pages is the most direct defense against exfiltration. It takes work to build without breaking features, which is why starting from a monitored inventory helps.
• Subresource Integrity pins a third-party file to a hash. If the file changes, the browser refuses it. It suits versioned libraries and does not suit vendor tags that update constantly by design.

And one non-technical control beats all three: fewer scripts. Every tag on a sensitive page is a party you have chosen to trust with that page. Payment fields hosted in the processor's own iframe keep card data out of reach of your page's scripts altogether.

If you take card payments, this is also a compliance matter. PCI DSS version 4 added requirements to keep an inventory of scripts on payment pages with a justification for each, to ensure their integrity, and to detect unauthorized changes to those pages.

Side by side

A simple way to hold it in mind is a grid of two questions. Was the requester legitimate? Was the code legitimate? Bad requester and good code is the case access control exists for. Good requester and bad code is the case it can never catch, because from the access point of view nothing went wrong. That second cell is where script-based breaches live.

The third meaning of integrity: correct and available

There is a quieter sense of the word that matters just as much: the system gives correct answers, consistently, and can be put back when it does not. The classic security triad lists integrity next to availability for a reason. A system that is secure and down, or secure and serving corrupted data, has failed its users.

At the edge this is built from a few unglamorous parts:

• Health checks that probe each origin with a request that exercises something real (a path that touches the database, not a static file) and that expect a specific response.
• Load balancing with failover, so traffic moves away from a failing origin or region without waiting for a human.
• Sensible timeouts and retries, so a slow origin fails over instead of stalling everyone.
• Backups with a tested restore. A backup that has never been restored is a hope. The test that counts is restoring to a clean environment and timing it.
• Rollback for configuration, since an edge rule change can take a site down as surely as a bad deploy.

The trap here is the control that has never been exercised. Until a probe has reported a real failure and a failover has actually fired, neither one has been verified. Schedule the drill: on a quiet weekday, take one origin out on purpose and watch what happens. You will learn whether the check detects it, how long traffic takes to move, whether the second origin can carry the load, and whether sessions survive. Finding that out on your own schedule is the entire point.

Three owners, and the gaps between them

In most companies these three concerns belong to different people. IT owns identity and access. Marketing owns the tag manager, and with it most of the third-party scripts. Infrastructure owns failover and backups. Each group can pass its own review while the seams stay open:

• A new marketing tag goes onto the checkout page through the tag manager, with no engineering review, because tag changes are not deployments.
• An admin panel is protected by a strong access policy, and it loads a third-party script that can read everything on the screen once the administrator is in.
• The failover origin was built a year ago and is missing the access rules that protect the primary.
• A restore procedure brings back data and not the access policies around it.

Treating integrity as one practice means asking all three questions about each important system at the same time: who can reach it, what code runs in it, and how it recovers. The same habit applies during modernization work. When a legacy system is being replaced piece by piece, each piece that moves needs its access policy, its script inventory and its failover to move with it, or the migration quietly lowers the bar.

A starting checklist

• Every internal application is behind a per-application policy, and none is reachable by direct IP.
• Policies require group membership and strong authentication, not only a company email domain.
• Service tokens have owners and expiry dates.
• Break-glass access exists, is logged and is reviewed after each use.
• A current inventory of scripts exists for login and payment pages, with a named owner and reason per script.
• Alerts fire on new scripts and new outbound domains on those pages, and reach a person.
• Tag manager changes on sensitive pages require review.
• An enforcing content security policy is in place, or scheduled, for sensitive pages.
• Health checks test a meaningful path, and failover has been triggered on purpose in the last six months.
• A restore has been performed and timed in the last six months.

Could you list, today, every script that runs on your login and payment pages?

Most teams cannot, and the real list is usually longer than the guess. Trivo implements Zero Trust access, client-side monitoring and failover as one piece of work, starting with an inventory of what is actually running before anything changes. Bring your access policies and your list of third-party scripts, and you will get back a map showing which parts are checked today and which have gone unreviewed for too long.