Web Security, the browser-enforced standards reference
The browser-enforced web security standards, from security policies to the Reporting API that carries their reports, HTTP security headers, and Subresource Integrity.
Last update:
Web Security is the standards reference behind CentralCSP: the client-side security mechanisms a browser enforces on your pages, and the API that reports on them. It is vendor-neutral. Each page explains one standard, what it protects against, how to configure it, and, where it applies, how it reports.
The tab covers four areas:
- Policies the browser enforces from a response header: Content Security Policy, COOP, COEP, Permissions-Policy, and the rest. Most can report what they would block before you enforce it.
- The Reporting API, the shared transport that queues those reports and delivers them out of band to an endpoint you control.
- Security headers, the one-line response headers that harden a page but emit no
reports: HSTS, cookie attributes,
nosniff, Referrer-Policy. - Subresource Integrity (SRI), which pins the exact bytes of a script or stylesheet so a tampered file will not load.
CentralCSP is built on these standards. It collects every report type at one endpoint and turns the stream into client-side security monitoring and PCI DSS v4 evidence, with Content Security Policy as the deepest use case.
In this section
Reporting API
The delivery standard: concepts, the reporting headers, and one page per report type.
Policies
The browser security policies you configure and report on. CSP is the deepest sub-tree.
Security headers
HSTS, cookie attributes, nosniff, Referrer-Policy and the rest, with the value to ship for each.
Subresource Integrity (SRI)
Verify a fetched script or stylesheet with the integrity attribute.
How policies and the Reporting API relate
Two of the four areas work as a pair. A policy is the producer of a report: it flags an event (a blocked script, a framed page, a network failure) and names a reporting endpoint. The Reporting API is the transport: the browser queues that report and delivers it, batched and on its own schedule, independently of the page. You set both on the same HTTP response.
Security headers and SRI stand on their own: they harden the page directly and do not flow through the Reporting API.
Start here
- New to the standard? Read how the Reporting API works.
- Setting up reporting? Follow Get started, then confirm a live site with the Reporting API configuration checker.
- Locking down a page? Start with Content Security Policy.
- Hardening the basics? Scan with the security headers scanner and work down the security headers list.