# Overview (/en/docs/web-security)



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](/en/docs/platform/monitoring) and turns the stream into
client-side security monitoring and PCI DSS v4 evidence, with
[Content Security Policy](/en/docs/web-security/policies/content-security-policy) as
the deepest use case.

## In this section [#in-this-section]

<Cards>
  <Card title="Reporting API" href="/en/docs/web-security/reporting-api" description="The delivery standard: concepts, the reporting headers, and one page per report type." />

  <Card title="Policies" href="/en/docs/web-security/policies" description="The browser security policies you configure and report on. CSP is the deepest sub-tree." />

  <Card title="Security headers" href="/en/docs/web-security/security-headers" description="HSTS, cookie attributes, nosniff, Referrer-Policy and the rest, with the value to ship for each." />

  <Card title="Subresource Integrity (SRI)" href="/en/docs/web-security/other/subresource-integrity" description="Verify a fetched script or stylesheet with the integrity attribute." />
</Cards>

## How policies and the Reporting API relate [#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.

```mermaid
flowchart LR
  A["Policies<br/>(CSP, COOP, COEP, NEL, ...)"] -->|flag events, name an endpoint| B["Reporting API<br/>browser queue + delivery"]
  B -->|batched JSON| C["Your reporting<br/>endpoint"]
```

Security headers and SRI stand on their own: they harden the page directly and do not
flow through the Reporting API.

## Start here [#start-here]

* New to the standard? Read [how the Reporting API works](/en/docs/web-security/reporting-api/concepts/how-the-reporting-api-works).
* Setting up reporting? Follow [Get started](/en/docs/web-security/reporting-api/get-started), then confirm a live site with the [Reporting API configuration checker](/tools/reporting-api).
* Locking down a page? Start with [Content Security Policy](/en/docs/web-security/policies/content-security-policy).
* Hardening the basics? Scan with the [security headers scanner](/tools/security-headers) and work down the [security headers list](/en/docs/web-security/security-headers).

## Sources [#sources]

* [W3C, Reporting API](https://www.w3.org/TR/reporting-1/)
* [MDN, Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API)