Client-side security

What client-side security is

Client-side security is the practice of knowing what code runs in your visitors' browsers, controlling it with the policies browsers already enforce, and proving afterwards that those policies held.

It covers the machine in your architecture that you do not run: your visitor's browser.

The browser is part of your environment

A service you run sits behind a firewall and a WAF. Its certificates are watched, its dependencies scanned, its code analysed and its secrets audited. Its logs go to a SIEM, and nothing reaches production without a review. No single layer is trusted to hold.

Then the same code runs in a browser on a machine nobody on your team has seen, next to scripts from four vendors, one of which loaded two more after the page rendered. For most teams the controls around that are a TLS certificate and hope.

The browser is not your infrastructure, but it is part of your environment. Your code runs there, your customers type their data there, and a compromise there is a compromise of your product.

So run that layer the way you run the others. With payment data it is required: PCI DSS 4.0 requirements 6.4.3 and 11.6.1 ask for an inventory and authorization of the scripts on payment pages, and for the integrity of those pages to be monitored. The PCI page maps both requirements, including the halves no reporting tool covers.

What the layers you already have cannot see

Each of these tools sits somewhere the browser is not, and an attack that never touches your infrastructure never reaches them.

A WAF reads requests on their way in: A skimmer reads the card field in the browser and posts a copy to a host of its own. That request goes from your visitor to the attacker and never reaches your edge, so a WAF has nothing to inspect.
A SIEM reads logs from systems you run: Your servers logged a normal page render. The malicious part ran afterwards, in the browser, and wrote to nothing you collect. The transaction completed, so no business metric moved either, and these breaches run for months.
SAST and SCA read the code you wrote and the packages you chose: A third-party tag is not in your lockfile. It is fetched at run time from a host the vendor controls, and it can change between two page loads without a deploy on either side.
A DAST run or a header scan reads one fetch of one page: A good way to find a missing header. But it sees one request from one address at one moment. It misses the tag your tag manager serves to signed-in visitors in another country, and the vendor file that changed after the scan finished.

Only the browser saw what ran, and it tells you when the page carries a policy and an endpoint to report to.

The controls browsers already enforce

None of these needs code on your pages. Each is a response header, and they all report to the same endpoint.

The last line of each card says whether HeaderHawk receives that control's reports.

Content Security Policy

Content-Security-Policy

Decides which scripts, styles, frames, images and network destinations a page may use, by origin, nonce or hash. It is the broadest control and reports in the most detail: the directive that refused, the source it refused, and the file, line and column of the code that asked.

In HeaderHawk: Yes. Violation reports, grouped by directive, blocked source and page, on every plan.

Trusted Types

Content-Security-Policy: require-trusted-types-for 'script'

Stops a string reaching a DOM sink that would execute it, such as innerHTML, script.src or eval, unless it has been through a policy your own code wrote. The other controls act when something loads; this one acts at the point of injection.

In HeaderHawk: Yes. They are CSP directives, so a violation arrives as a CSP violation report.

Integrity-Policy and Subresource Integrity

Integrity-Policy, and integrity= on the tag

An integrity attribute pins a file to a hash, so the browser refuses a changed file instead of running it. Integrity-Policy requires one: scripts may not load without integrity metadata at all, which covers the tag that leaves the attribute out.

In HeaderHawk: Integrity-Policy, yes. Integrity violation reports, and the Subresource Integrity coverage they add up to: which of a site's scripts a browser checks against a hash, and which it does not. A plain SRI mismatch has no report of its own. The browser refuses the file and logs it.

Permissions-Policy

Switches off the powerful features a page and its frames may reach, such as the camera, microphone, geolocation and payment request. A vendor script that starts asking for one is asking for something you never granted.

In HeaderHawk: Yes. Violations, and potential violations: a feature a frame would have been refused if it had asked.

COOP and COEP

Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy

Cut the window references and embedded resources that let another document reach into yours. Together they give cross-origin isolation, and they are the controls most likely to break an embed you forgot was there.

In HeaderHawk: Yes, both, as their own report types.

Connection allowlists

Connection-Allowlist

Names every origin a page may connect to in one list, covering the images, scripts, fetches and frames it loads and the requests a skimmer would use to send card data away. Chrome enforces it from version 152.

In HeaderHawk: Yes, as connection allowlist reports. Chrome holds each one until the visitor loads another page on your site, and sends it then.

The Reporting API

Reporting-Endpoints

The channel the others report through. One header names the endpoints, and every policy above points at one of them, so adding the second and third control costs no more integration than the first. It also carries the browser's own reports: deprecated APIs your pages still call, interventions the browser made, requests that failed before a response arrived, and tabs that crashed.

In HeaderHawk: Yes. Every type, on every plan, each with its own switch and sample rate.

Every CSP directive has a reference page on the docs site, with the report it produces and what it does not govern, including require-trusted-types-for and connect-src, which reports exfiltration.

How each one is rolled out: report-only, then enforced

Every control above has a report-only twin: Content-Security-Policy-Report-Only, Integrity-Policy-Report-Only, Permissions-Policy-Report-Only and the rest. A report-only header changes nothing about how the page behaves. The browser notices what the policy would have refused and posts a report instead of refusing.

So the layer is safe to add to a site already in production. Ship the report-only header, read its reports for a week or two, and fix what they find. On a first pass that is mostly your own: an image URL still on http://, an inline handler in a template, a vendor host nobody remembered. When the reports go quiet, rename the header to the enforcing one. The policy now blocks, and the reports keep arriving, so you hear about what it blocks.

A policy enforced before anyone read its reports causes an outage, and one left in report-only for good is a log nobody acts on. Most teams take one control at a time and get each one quiet before starting the next.

The three things a team needs

Everything in the category comes down to these, in this order.

See

What runs

What executed in a real session: the scripts, the hosts they reached, and the policies that refused something. Everything after this depends on it, and most teams have nothing for it.

Control

With policies the browser enforces

Write the policy, ship it in a header, and the browser applies it to every visitor. Nothing sits in the request path and nothing runs on the page, so the control adds no latency and cannot fail open.

Prove

That the controls held

An assessor, a customer's security review and your own next quarter all ask you to show them. That takes a dated record of what ran, who reviewed it, what was allowed and what changed since.