# CentralCSP
> Client-side security monitoring: see what runs in your users' browsers, catch threats in real time, and turn visibility into protection.
Full Markdown of every English page (per-page siblings live at each route + ".md").
```yaml
title: "Client-side security & CSP monitoring - CentralCSP"
description: "Monitor Content Security Policy and every client-side threat from real browser traffic. One header, no agent, EU-hosted. Start a free 14-day trial."
url: "https://centralcsp.com/en/"
lang: "en"
```
Client-side security
# Your server is locked down. What about your users' browsers?
CentralCSP is a client-side security platform for security and engineering teams. One response header, no agent, collects every signal browsers report, turned into live monitoring, a script inventory, and real-time alerts.
[Start free trial](https://app.centralcsp.com) [Book a demo](https://centralcsp.com/en/contact/?topic=demo)
The threats
## The attacks run also in your users' browser.
These threats execute client-side, after the page has left your servers. At that layer you have almost no visibility and nothing watching.
1. ### Magecart and formjacking
A skimmer slips onto your checkout and quietly copies card data as customers type it.
2. ### Supply-chain script compromise
A trusted vendor gets hijacked and starts serving malicious code from a source you allowed.
3. ### Cross-site scripting (XSS)
Injected code runs in your users' session, stealing data and rewriting the page in front of them.
4. ### Malicious redirects
Tampered code sends users to a fraudulent page or fake payment form, away from your site.
5. ### Data exfiltration
User data is quietly shipped to an attacker's server, with no trace of where it went.
6. ### Clickjacking
A hidden overlay tricks users into clicking something they never intended to.
Why CentralCSP
## Client-side doesn't have to be the blind spot.
Without CentralCSP
Server-side defenses like WAF and SIEM can't see what runs in the browser after the page is delivered.
- No client-side visibility
- Third-party scripts uninventoried
- Tampered scripts go unnoticed
- Dependency CVEs invisible
- Nothing watching, no alerts
- No protection against client-side attacks
With CentralCSP
We monitor your policy and reports to give you the clearest overall view, and the actions to improve your security posture.
- Full client-side visibility
- Every script inventoried and sourced
- Alerts on potential issues
- Known CVEs flagged as they appear
- Real-time monitoring
- Effective protection against client-side attacks
Real time
## See what real browsers report, as it happens.
We collect signals from your clients' browsers, in real time, so you get alerted when something goes wrong.
### Real-user coverage
Reports come from actual browser traffic, continuous monitoring from your production traffic.
### All browser signals
Full Reporting-API support, every signal on one endpoint.
### Live in minutes
Add one header and reports start flowing. No agent, no code changes.
## One dashboard for every signal coming from your pages.
Every script loaded, every browser report type, in one place.
## Trusted by teams across the world
From e-commerce checkouts to healthcare and SaaS, teams rely on us for their client-side security.
1.5B
reports ingested
580k+
websites scanned
1000+
websites monitored
Full
Reporting-API support
The platform
## Every layer of client-side security, covered.
Six capabilities on one platform: collect the signals, understand them, enforce a policy, and prove it.
### Monitoring
Every report type browsers can send, collected from your real visitors on one endpoint.
- 12 report types, one endpoint
- Real production traffic
- Zero performance impact
- Live violation feed
[See CSP monitoring](https://centralcsp.com/en/platform/monitoring/)
### Alerting
Custom rules watch your reports and ping the right channel the moment something changes.
- 6 channels including webhooks
- Custom alert rules
- New origins and spikes
- Routing per website
[See real-time alerts](https://centralcsp.com/en/platform/alerting/)
### CSP builder
Stop hand-writing policies. We build an enforceable CSP from what your traffic actually loads.
- Generated from real reports
- Report-only first, enforce when clean
- Directive-by-directive control
- Catches what a crawler misses
[See the CSP builder](https://centralcsp.com/en/platform/csp-builder/)
### PCI DSS evidence
Auditor-ready evidence for requirements 6.4.3 and 11.6.1, sourced from real browser traffic.
- Payment-page script inventory
- Justification workflow
- Auditor-ready exports
[See PCI DSS evidence](https://centralcsp.com/en/platform/pci-dss/)
### Supply-chain
Know every script you ship and every dependency it pulls in, with advisories the moment one gains a CVE.
- Script SBOM per site
- Known-CVE detection
- New-script alerts
- Hash-change tracking
[See supply-chain protection](https://centralcsp.com/en/platform/supply-chain/)
### API and MCP
Everything in the dashboard is available to your own tooling, or to your AI agents over MCP.
- Full REST API
- Built-in MCP server
- Exports and reports
- Automate site onboarding
[See the API and MCP server](https://centralcsp.com/en/platform/api-mcp/)
[Compare plan features](https://centralcsp.com/en/pricing/)
How it works
## From browser signal to hardened front end
The reports are already coming from every browser. We collect them, show them live, turn them into an enforced policy, and flag the moment something changes.
1. Collect
2. 2 Monitor
3. 3 Protect
4. 4 Detect
1. Collect Gather every browser report
2. 2 Monitor See it live on one dashboard
3. 3 Protect Harden your configuration
4. 4 Detect Get alerted on what matters
### Collect the signals browsers already send
Point one Reporting-API endpoint at CentralCSP and browsers start streaming reports from real production traffic. No agent, no SDK, no code change.
- Live in minutes with one response header
- Every report type, from real users
- No agent, SDK, or code change
### Turn raw signals into a realtime picture
Every report lands in a live dashboard that turns the browser's raw signals into insight your team can act on, as it happens.
- A realtime feed of every report
- Insight from real production traffic
- Trends and breakdowns at a glance
### Tighten your policy and headers & configuration
We turn the reports you collect into a tightened Content-Security-Policy and review your security-header configuration, so nothing is left loose.
- A CSP built from real reports
- Security-header gaps surfaced
- Lock the allowlist to what you trust
### Catch changes the moment they happen
CentralCSP keeps a continuous inventory of every script on your pages and alerts you the instant something new or vulnerable appears.
- Alerts when something needs attention
- A live inventory, fed by real traffic
- Known CVEs and new origins flagged
Integrations
## Get alerted where your team already works.
Send client-side alerts straight to the channels your team already lives in.
- Microsoft Teams
- Slack
- Google Chat
- Telegram
- Email
- Webhooks
### For developers
Use our security scanners and tools for free. Fix your configuration and check your Reporting-API setup. When you're ready, turn on continuous monitoring.
- Security headers scanner.
- Content-Security-Policy scanner / evaluator.
- Reporting-API configuration checker.
- Chrome extension, Content-Security-Policy builder.
[See the developer tools](https://centralcsp.com/en/solutions/developers/)
### For agencies
Add client-side monitoring to your care plans and watch every client site from one dashboard. Get alerted before your clients notice, and hand over reports showing your professional client-side security posture.
- One dashboard for every client site, alerted before clients notice.
- Professional reports, priced for a portfolio, not per app.
- Integrate with your existing tools and processes.
[See how agencies use CentralCSP](https://centralcsp.com/en/solutions/agencies/)
Workflow
## Built to run at scale.
The full client-side workflow, across all your sites and teams.
### Detect every script
Everything that runs on your pages, surfaced from real browser traffic across all your sites, not a crawl.
### Triage what matters
Alerts on new origins, hash changes and violation spikes, sent to the channels your team already uses.
### Prove compliance
Auditor-ready PCI DSS v4 evidence, exported from real browser traffic and kept as a continuous archive.
### Govern the policy
Build your policy from real reports, lock it to what you trust, and catch anything new the moment it appears.
### For compliance and PCI DSS v4
Meet PCI DSS v4 6.4.3 and 11.6.1 with continuous monitoring of the scripts on your sensitive pages, sourced from real browser traffic.
- Authorization, make sure everything running on your pages is approved.
- Inventory, keep an authorized list of every script, with its justification.
- Integrity, enforce integrity and get notified the moment a file is tampered with.
- Alert on new scripts, origins, and hashes.
- Detect known CVEs in the libraries you load.
- Export audit-ready evidence.
[See the PCI evidence workflow](https://centralcsp.com/en/platform/pci-dss/)
### For enterprise
Enterprise-grade platform, built to meet the security and compliance requirements of regulated teams.
- SSO, integrate seamlessly with your existing identity provider.
- Support, dedicated support to help you with any question or issue.
- SLA, ensure a high level of availability and performance.
- RBAC, work as a team and ensure colleagues access only what they need.
- EU-hosted, data never leaves the EU, hosted in France on OVH.
- Scalable, the platform evolves with your needs.
[See the enterprise case](https://centralcsp.com/en/solutions/enterprise/)
Recognition · 2026
## Featured in the Wavestone Cybersecurity Startup Radar
Wavestone selected CentralCSP for its 2026 radar mapping the most promising cybersecurity startups in France, a strong signal that client-side security is becoming a priority for the whole industry.
[See the 2026 startup radar](https://www.wavestone.com/en/insight/2026-french-cybersecurity-startup-radar/) [Learn more about us](https://centralcsp.com/en/about/)
Pricing
## Plans and pricing for client-side security.
EU hosting, all report types, and 90-day retention come standard on every paid plan. Pay annually and get two months free.
Monthly Annual
Save 2 months by paying yearly
### Start
For a first production site.
€39.99 / mo
14-day free trial
- Applications 3
- Users 5
- Reports / month 250,000
Plan features
- Full Reporting-API support
- Unlimited scans
- Script inventory
- Team access and RBAC
- Policy builder
[Start free trial](https://app.centralcsp.com/?plan=start&billing=monthly)
Recommended
### Business
Automate it and wire it into your stack.
€129.99 / mo
- Applications 10
- Users 25
- Reports / month 2,000,000
Everything in Start, plus:
- Alerting to six channels
- Unlimited alerts
- API & MCP
[Get started](https://app.centralcsp.com/?plan=business&billing=monthly)
### Scale
PCI DSS v4 evidence, at portfolio scale.
€349.99 / mo
- Applications 30
- Users 100
- Reports / month 10,000,000
Everything in Business, plus:
- CVE detection
- Payment page monitoring
- PCI DSS evidence
- SSO and audit log
- Invoicing and procurement support
[Get started](https://app.centralcsp.com/?plan=scale&billing=monthly)
### Enterprise
For banks, insurers, and large accounts.
Custom
- Applications Custom
- Users Custom
- Reports / month Custom
Everything in Scale, plus:
- Custom quotas and contract
- A contractual uptime SLA
- Priority support and onboarding
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
The platform
## Reports are just the starting point.
Inventory, monitoring and alerting are built on top of them, turning visibility into action.
### One platform, every feature you need
The full client-side security suite, built on the reports browsers already send. Every layer of your client side, covered. One platform for every script, page, and policy you ship.
[Start free trial](https://app.centralcsp.com)
### Script inventory
Every third-party dependency on your pages, mapped to its source and checked for known CVEs.
### Payment-page monitoring
Watch your checkout and payment forms. Continuous monitoring built for PCI DSS 6.4.3.
### Alerts & channels
Route new origins, hash changes, and specific event spikes to the channel your team already lives in.
FAQ
## Frequently asked questions
Everything you need to know about client-side security with CentralCSP.
### What is client-side security, and why does it matter?
Server-side defenses like WAF and SIEM can't see what runs in your users' browsers. Client-side security watches the scripts, requests, and policy violations that happen after your page is delivered, where attacks like Magecart skimming, formjacking, and supply-chain script compromise actually execute.
### How does CentralCSP work without an agent or code changes?
CentralCSP is built on the browser's Reporting API. You add a single response header and reports start flowing from your real visitors' browsers, with no JavaScript agent, no SDK, and no changes to your application code.
### Does CentralCSP help with PCI DSS v4 compliance?
Yes. It continuously inventories the scripts on your payment and checkout pages and exports auditor-ready evidence for PCI DSS v4 requirements 6.4.3 and 11.6.1, sourced from real browser traffic rather than a sampled crawl.
### Where is my data hosted?
All data is hosted in France on OVH and never leaves the EU, so you keep full European data residency.
### Will CentralCSP slow down my site?
No. There's no client-side script to load. Browsers send reports natively through the Reporting API, so there is zero performance impact on your pages.
### How do alerts reach my team?
Route new origins, hash changes, and violation spikes to the channels your team already uses, including Microsoft Teams, Slack, Google Chat, Telegram, and email. A webhook can also be used for anything custom.
## Start monitoring today.
Add one header and reports start flowing. No agent, no code changes. 14-day free trial.
[Start free trial](https://app.centralcsp.com) [Book a demo](https://centralcsp.com/en/contact/?topic=demo)
---
Available in: [en](https://centralcsp.com/en/), [fr](https://centralcsp.com/fr/)
```yaml
title: "About CentralCSP - the client-side security team"
description: "Two cybersecurity engineers making the client side secure, from a first CSP scanner to a platform ingesting billions of browser reports. Meet CentralCSP."
url: "https://centralcsp.com/en/about/"
lang: "en"
```
Our mission
# Help us secure our browsers
At CentralCSP, our goal is to make client-side security something every team can actually reach. Servers are hardened, monitored, and patched, but the browser is where your users meet your code, and it stays the weakest spot. We help companies see, prove, and protect what runs in their visitors' browsers, with no agent and no code changes.
The challenge we faced
## Client-side security is hard to get right
As web security engineers and developers, we lived the complexity of Content Security Policy firsthand. Every project brought broken features, endless policy tweaks, and hours lost debugging violations.
### The client side is a blind spot
WAFs and SIEMs stop at the server. The third-party scripts, trackers, and injected code running in your users' browsers stay invisible.
### CSP is hard to build and maintain
Writing a Content Security Policy by hand takes weeks, and a single strict directive can silently break checkout, analytics, or login in production.
### Supply-chain risk meets PCI DSS v4
Third-party scripts get hijacked to skim data, while PCI DSS v4 now requires you to inventory and monitor every one, hard to meet and to prove.
The solution
## So we built CentralCSP
We created CentralCSP to solve these challenges. The platform automates client-side security: real-time monitoring, real-traffic-based policy recommendations, vulnerable-script detection, and compliance insight. What used to take weeks now takes minutes.
1.5B
reports ingested
580k+
websites scanned
1000+
websites monitored
Full
Reporting-API support
Our story
## An endless evolution
We started small and shipped relentlessly. Every year added a layer, from a first scanner to billions of reports and enterprise-grade protection, always driven by the same mission.
1. 2024
### A scanner for CSP
CentralCSP began as a simple Content-Security-Policy scanner, then grew into a platform to track CSP violations from real browser traffic.
2. 2025
### Growing into a platform
We expanded fast, building for PCI DSS v4 and adding deeper CSP capabilities across the platform.
3. 2026
### Enterprise scale
We scaled to billions of reports, shipped enterprise-grade features, and now ingest every report type the browser Reporting API can send.
4. Now
### The mission continues
We keep making the client side more secure, turning monitoring into strong protection and real security insight.
Recognition · 2026
## Featured in the Wavestone Cybersecurity Startup Radar
Wavestone selected CentralCSP for its 2026 radar mapping the most promising cybersecurity startups in France, a strong signal that client-side security is becoming a priority for the whole industry.
[See the 2026 startup radar](https://www.wavestone.com/en/insight/2026-french-cybersecurity-startup-radar/)
The team
## Meet the founders
Two cybersecurity engineers on a mission to make the client side secure.
TQ
### Théotime Quéré
[](https://www.linkedin.com/in/theotimeq/)
Co-founder · Strategy & Customers
Cybersecurity engineer focused on strategy and customers, making sure CentralCSP solves the problems security teams really face.
TP
### Thomas Poyeton
[](https://www.linkedin.com/in/thomaspoyeton/)
Co-founder · CTO
Cybersecurity engineer leading the technology behind CentralCSP, from the reporting pipeline to the features it delivers.
## Ready to improve your security posture?
See what runs in your users' browsers, prove your compliance, and harden your client side.
[Start free trial](https://app.centralcsp.com) [Book a demo](https://centralcsp.com/en/contact/?topic=demo)
---
Available in: [en](https://centralcsp.com/en/about/), [fr](https://centralcsp.com/fr/about/)
```yaml
title: "Contact CentralCSP - talk to sales or book a demo"
description: "Talk to CentralCSP sales, book a client-side security demo, or reach support. EU-hosted in France on OVH, we usually reply within 24 hours."
url: "https://centralcsp.com/en/contact/"
lang: "en"
```
Get in touch
# Contact us
See how CentralCSP turns the browser's own reports into client-side security you can act on. Tell us what you need and we'll get back to you, usually within 24 hours.
- See every script running on your pages, from real browser traffic.
- Prove PCI DSS v4 compliance with auditor-ready evidence.
- Get alerted instantly on any new script, origin, or violation.
Trusted by teams across the world
First name
Last name
Company email
Topic Select a topic
How can we help?
Send message
We'll only use your details to reply to your request. Read our [privacy policy](https://centralcsp.com/en/legal/privacy/).
Resources
## Looking for something else?
Docs, web-security guides, and our blog, all a click away.
### Platform documentation
Guides, API references, and how-tos for setting up and running CentralCSP.
[Read the docs](https://centralcsp.com/en/docs/platform)
### Web security documentation
How security headers and the browser Reporting API work, and how to set them up and configure them.
[Explore web security](https://centralcsp.com/en/docs/web-security)
### Read our blog
Deep dives on client-side security, CSP, and the browser Reporting API.
[Visit the blog](https://centralcsp.com/en/blog)
FAQ
## Frequently asked questions
Reaching us, security, and where your data lives.
### How fast will I hear back?
We usually reply within 24 hours.
### Can I get a DPA or security documentation?
Yes. Ask sales for our DPA, sub-processor list, and security overview, everything a regulated procurement review needs.
### Where is my data processed?
In the EU. CentralCSP is hosted in France on OVH, and your data never leaves the EU.
### Is there a free trial?
Yes. The Start plan includes a 14-day free trial. See the pricing page for what each plan includes.
### Can I book a live demo?
Yes. Send us a message asking for a demo and we'll schedule a guided walkthrough.
### Do you support SSO and procurement reviews?
Yes. SSO and procurement review support are included on the Scale and Enterprise plans, with a public DPA and help on your security questionnaire. Reach out and we'll walk your team through it.
---
Available in: [en](https://centralcsp.com/en/contact/), [fr](https://centralcsp.com/fr/contact/)
```yaml
title: "Data Processing Agreement - CentralCSP"
description: "The data processing agreement covering how CentralCSP, the EU-hosted client-side security platform, processes personal data on your behalf."
url: "https://centralcsp.com/en/legal/dpa/"
lang: "en"
```
Legal
# Data Processing Agreement - CentralCSP
Last updated: August 9, 2026
If you require a signed copy of this Data Processing Agreement (DPA), please contact us at
[](mailto:contact@centralcsp.com)
[](mailto:contact@centralcsp.com)[contact@centralcsp.com](mailto:contact@centralcsp.com)
This Data Processing Agreement ("DPA") is entered into by and between the Customer (as defined in the Principal Agreement) ("Customer" or "Controller") and CentralSaaS, a _société par actions simplifiée_ incorporated under the laws of France, registered office at 1 Allée des Frênes, 38240 Meylan, France, registered with the _Registre du Commerce et des Sociétés_ of Grenoble under number **927 890 756**, operating the CentralCSP service ("CentralCSP" or "Processor") (each a "Party" and together the "Parties") and is incorporated into and forms an integral part of the Principal Agreement.
This DPA will become effective on the date the Customer electronically accepts or executes the Principal Agreement.
**WHEREAS**
(A) The Customer, acting as a Data Controller, has entered into an agreement for the provision of Services by the Processor (the "Principal Agreement").
(B) The provision of the Services by the Processor to the Customer involves the processing of personal data on behalf of the Customer.
(C) This DPA is intended to ensure the processing of personal data by the Processor is conducted in compliance with the requirements of applicable Data Protection Laws, including Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation or "GDPR").
(D) The Parties wish to lay down their respective rights and obligations concerning the processing of personal data under the Principal Agreement.
## 1\. Definitions and Interpretation
### 1.1. Unless otherwise defined, capitalized terms and expressions used in this DPA shall have the following meaning:
- 1.1.1. **Customer Data** means any data, including Personal Data, that the Customer or its End-Users submit to, or that is generated in relation to the Customer's use of, the Services for processing by the Processor on behalf of the Customer.
- 1.1.2. **Data Protection Laws** means all applicable laws and regulations relating to the processing of personal data and privacy, including but not limited to the GDPR and any national implementing laws, regulations, and secondary legislation.
- 1.1.3. **End-User** means a natural person (Data Subject) who accesses or uses the Customer's websites, applications, or online services that are monitored or protected by the Services.
- 1.1.4. **EEA** means the European Economic Area.
- 1.1.5. **Principal Agreement** means the Terms of Service, Master Services Agreement, or other written or electronic agreement between the Processor and the Customer for the provision of the Services.
- 1.1.6. **Services** means the provision of web security and compliance services by the Processor, including but not limited to the collection and analysis of all browser Reporting-API report types via a reporting endpoint, event-based alerting, script inventory and vulnerability (CVE) detection, PCI DSS evidence generation, on-demand website security scanning, CSP scanning and evaluation, automated CSP policy building, and the API and MCP integrations, as more fully described in the Principal Agreement and in Annex 1.
- 1.1.7. **Standard Contractual Clauses** or **SCCs** means the standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council, as adopted by the European Commission.
- 1.1.8. **Sub-processor** means any third-party processor engaged by the Processor to process Customer Data.
- 1.1.9. **Customer-Directed Destination** means any product, service, endpoint, or recipient outside the Processor's infrastructure to which the Customer configures the Services to transmit Customer Data, including alert delivery channels (for example Slack, Microsoft Teams, PagerDuty, an email address, or a webhook endpoint) and any AI assistant or agent connected through the API or the MCP integration.
- 1.2. The terms **Controller**, **Data Subject**, **Personal Data**, **Personal Data Breach**, **Processing**, and **Supervisory Authority** shall have the same meaning as in the GDPR, and their cognate terms shall be construed accordingly.
- 1.3. In the event of any conflict or inconsistency between this DPA and the Principal Agreement, the terms of this DPA shall prevail with regard to the processing of Personal Data. In the event of any conflict between this DPA and an Order Form executed by both Parties, the Order Form prevails, except that no Order Form may reduce the Processor's obligations below what Data Protection Laws require.
## 2\. Roles and Responsibilities; Processing of Personal Data
### 2.1. Roles of the Parties
The Parties acknowledge and agree that for the purposes of the Data Protection Laws, the Customer is the Controller and the Processor is the Processor of the Customer Data. Each Party will be responsible for its own compliance with its obligations under Data Protection Laws.
This DPA governs only the Customer Data that the Processor processes on the Customer's behalf as a processor. The Processor acts as an independent **controller** for the personal data it processes for its own purposes, in particular account registration and billing, which is governed by the Processor's Privacy Policy rather than this DPA.
### 2.2. Processor's Obligations
The Processor shall process Customer Data only on behalf of the Customer and in accordance with the Customer's documented instructions. The Customer's initial instruction to the Processor for the processing of Customer Data is the Customer's execution of the Principal Agreement and its use of the Services. The subject matter, duration, nature, purpose, types of Personal Data, and categories of Data Subjects for the processing are set forth in Annex 1 (Details of the Processing) to this DPA. The Processor shall not process Customer Data for any other purpose unless required to do so by applicable law to which the Processor is subject. In such a case, the Processor shall inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
### 2.3. Customer's Obligations
The Customer represents and warrants that it has established and will maintain a valid legal basis for the processing of Customer Data as contemplated by the Principal Agreement and this DPA. The Customer is solely responsible for the accuracy, quality, and legality of the Customer Data and the means by which it acquired the Customer Data. The Customer's instructions to the Processor for the processing of Customer Data shall comply with all Data Protection Laws.
### 2.4. Infringing Instructions
The Processor shall immediately inform the Customer if, in its opinion, an instruction from the Customer infringes Data Protection Laws. The Processor may suspend performance of the affected instruction until the Customer confirms, modifies, or withdraws it.
### 2.5. Aggregated and Anonymised Data; Artificial Intelligence
The Processor operates a scanner that analyses publicly accessible websites at the Customer's request. The Processor may compile aggregated and anonymised statistics derived from scans of publicly accessible websites, for example for its periodic "State of the Web" research report. Such aggregated and anonymised data does not identify, and cannot reasonably be used to identify, any individual, and does not constitute Customer Data or Personal Data. The Processor does not use the personal data contained in the Customer's browser reports for this purpose.
The Processor does not use Customer Data to train, fine-tune, or develop artificial intelligence or machine-learning models.
This commitment concerns the Processor's own processing. Where the Customer connects the Services to a Customer-Directed Destination, including an AI assistant or agent connected through the API or the MCP integration, the Customer initiates and directs that transmission in its capacity as Controller. Such a transmission is not a disclosure or a sub-processing by the Processor, is outside the scope of this DPA once the data leaves the Processor's systems, and the Customer is solely responsible for it, including for establishing a legal basis, for the recipient's processing (such as whether the data is used for model training), and for any transfer outside the EEA that results.
## 3\. Security and Confidentiality
### 3.1. Security Measures
Taking into account the state of the art, the costs of implementation and the nature, scope, context, and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the Processor shall implement and maintain appropriate technical and organizational measures to ensure a level of security appropriate to the risk. These measures are designed to protect Customer Data against accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data. The specific technical and organizational measures implemented by the Processor are described in Annex 2 (Technical and Organizational Security Measures).
The Processor may update the measures described in Annex 2 to reflect technological developments and evolving threats, provided that no update materially reduces the overall level of security of the Customer Data.
### 3.2. Confidentiality
The Processor shall ensure that any personnel authorized to process Customer Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Access to Customer Data shall be strictly limited to those individuals who need such access to perform their duties in connection with the Services.
## 4\. Sub-processing
### 4.1. General Authorization
The Customer provides a general written authorization to the Processor to engage Sub-processors to process Customer Data on the Customer's behalf, provided that the Processor complies with the requirements of this Section 4.
### 4.2. List of Sub-processors
The Processor shall maintain a list of its current Sub-processors, as set out in Annex 3 (Authorized Sub-processors), and shall make this list available to the Customer. This list shall include the identities of the Sub-processors, their location, and the purpose of the sub-processing activities.
A Customer-Directed Destination is not a Sub-processor of the Processor. Where the Customer routes Customer Data to such a destination, the Customer engages that recipient directly and is responsible for the corresponding contractual arrangements.
### 4.3. Notification of New Sub-processors
The Processor shall inform the Customer of any intended changes concerning the addition or replacement of Sub-processors. The Processor will provide such notification by a reasonable mechanism (for example by email or through the service portal) at least thirty (30) days in advance of the new Sub-processor beginning to process Customer Data.
### 4.4. Right to Object
The Customer may object to the appointment of a new Sub-processor within fourteen (14) days of receiving the notification from the Processor, provided such objection is based on reasonable grounds relating to data protection. If the Customer objects, the Parties will work together in good faith to find a commercially reasonable solution.
If no such solution is found within thirty (30) days of the objection, the Customer may terminate the affected Services by written notice, and the Processor shall refund, on a pro-rata basis, any prepaid fees covering the period after the effective date of that termination. Termination under this Section is without penalty for the Customer.
### 4.5. Sub-processor Obligations and Liability
In accordance with Article 28(4) of the GDPR, the Processor shall impose on each Sub-processor, by way of a written contract, data protection obligations that are the same in substance as those set out in this DPA, in particular the obligation to provide sufficient guarantees to implement appropriate technical and organizational measures so that the processing meets the requirements of the GDPR. Where a Sub-processor fails to fulfil its data protection obligations, the Processor remains fully liable to the Customer for the performance of that Sub-processor's obligations.
## 5\. Data Subject Rights
Taking into account the nature of the Processing, the Processor shall assist the Customer by implementing appropriate technical and organizational measures, insofar as this is possible, for the fulfillment of the Customer's obligation to respond to requests for exercising the Data Subject's rights laid down in Chapter III of the GDPR. The Processor shall promptly notify the Customer if it receives a request from a Data Subject. The Processor shall not respond to any such request itself, except on the documented instructions of the Customer or as required by applicable law. Given the nature of the Services, where Customer Data primarily consists of technical violation reports, the Processor may not be able to directly identify an End-User from the data it processes. The responsibility to verify and respond to the Data Subject therefore remains with the Customer, with the Processor providing necessary assistance.
## 6\. Personal Data Breach
The Processor shall notify the Customer without undue delay and in any event within seventy-two (72) hours after becoming aware of a Personal Data Breach affecting Customer Data. The Processor shall provide the Customer with sufficient information to allow the Customer to meet its obligations to report the breach to the Supervisory Authority and/or inform Data Subjects. Such notification shall, at a minimum:
- (a) describe the nature of the Personal Data Breach, including, where possible, the categories and approximate number of Data Subjects and Personal Data records concerned.
- (b) communicate the name and contact details of the data protection contact or other contact point where more information can be obtained (see Section 11.5).
- (c) describe the likely consequences of the Personal Data Breach.
- (d) describe the measures taken or proposed to be taken by the Processor to address the Personal Data Breach, including, where appropriate, measures to mitigate its possible adverse effects.
The Processor shall cooperate with the Customer and take such reasonable commercial steps as are directed by the Customer to assist in the investigation, mitigation, and remediation of each such Personal Data Breach.
## 7\. Data Protection Impact Assessment and Prior Consultation
The Processor shall provide reasonable assistance to the Customer with any data protection impact assessments and prior consultations with Supervisory Authorities which the Customer reasonably considers to be required under Articles 35 and 36 of the GDPR or equivalent provisions of any other Data Protection Law. Such assistance shall be provided solely in relation to the processing of Customer Data by the Processor and taking into account the nature of the processing and the information available to the Processor.
## 8\. Retention, Return and Deletion of Data
During the term of the Principal Agreement, browser reports are retained for a rolling period of ninety (90) days, after which they are deleted or irreversibly aggregated into anonymised statistics. Deleting a website or workspace in the dashboard deletes the browser reports associated with it. Scan results are designed to describe the publicly accessible configuration of a website; they are retained indefinitely or aggregated into statistics, and where a scan result incidentally contains personal data (for example an identifier embedded in a URL), the Processor deletes or redacts it on the Customer's request. Free-tool submissions are not retained as individual records; they are aggregated into anonymised statistics. Anonymised statistics derived from browser reports and free-tool submissions contain no personal data and are retained indefinitely.
Upon termination of the Principal Agreement, the Customer has a period of thirty (30) days during which it may export Customer Data through the Services or request its return in a structured, commonly used, machine-readable format, as provided in the Principal Agreement. The Processor shall then, at the choice of the Customer, delete or return all Customer Data, and shall delete all existing copies within ninety (90) days of the termination date, unless applicable law requires continued storage. Scan results are excepted from this deletion obligation and are retained as described above, subject to the same deletion or redaction of incidental personal data on request. Backup copies are deleted on the expiry of the ordinary backup rotation cycle, which does not exceed ninety (90) days. Where the Customer makes no choice within the export window, the Processor will delete the Customer Data.
## 9\. Audit Rights
The Processor shall make available to the Customer, upon request, all information necessary to demonstrate compliance with its obligations under this DPA. In the first instance, the Processor may provide the Customer with copies of relevant third-party audit reports and certifications (e.g., PCI DSS SAQ A). This approach is standard for multi-tenant cloud environments, as it provides robust assurance of compliance without exposing the Processor's infrastructure or the data of other customers to the risks associated with direct, on-site audits by every customer.
Where the information and reports so provided are not reasonably sufficient to demonstrate compliance with this DPA, or where an audit is required by a Supervisory Authority or by mandatory Data Protection Law, the Processor shall, in accordance with Article 28(3)(h) of the GDPR, allow for and contribute to an audit, including an inspection, conducted by the Customer or an independent auditor mandated by the Customer (which may not be a competitor of the Processor), subject to the following conditions: (a) no more than one audit in any twelve (12) month period, except following a Personal Data Breach affecting Customer Data or where required by a Supervisory Authority; (b) at least thirty (30) days' prior written notice; (c) the execution of a confidentiality agreement covering the audit; (d) the audit being conducted during normal business hours, with minimal disruption to the Processor's operations; (e) no access being given to the data of other customers or to systems not relevant to the processing of Customer Data; and (f) each party bearing its own costs, the Customer reimbursing the Processor's reasonable costs of contribution for any audit exceeding one (1) business day.
### 9.1. Payment card data
The Processor does not collect, process, or store cardholder data, including primary account numbers (PAN); all payment card processing is performed by Stripe. The Processor maintains PCI DSS SAQ A compliance, which is a self-assessment concerning that outsourcing of cardholder data handling and does not evidence the security of the browser telemetry processed under this DPA. Compliance with this DPA is evidenced by the measures in Annex 2 and the audit rights in this Section.
## 10\. International Transfers
The Processor hosts and processes all Customer Data within the European Union / EEA, and in the ordinary course of providing the Services it does not transfer Customer Data to any country outside the EEA.
Where a Sub-processor engaged by the Processor may make an onward transfer of limited data outside the EEA (for example, a payment processor transferring billing data to an affiliated entity in the United States), such transfers are governed by that Sub-processor's own appropriate safeguards under Chapter V of the GDPR, namely the Standard Contractual Clauses and/or certification under the EU-US Data Privacy Framework. Should the Processor itself transfer Customer Data outside the EEA in the future, it shall do so only subject to an appropriate transfer mechanism, the Standard Contractual Clauses, which shall be deemed incorporated into this DPA by reference, and, where required, a documented transfer impact assessment.
The Processor's data residency commitment covers the data it holds on its own infrastructure and that of its Sub-processors. It does not cover Customer-Directed Destinations. Where the Customer configures the Services to transmit Customer Data outside the EEA (for example by routing alerts to a channel hosted in a third country, or by connecting an AI assistant through the API or the MCP integration), that transfer is made on the Customer's instruction and in its capacity as Controller. The Customer is solely responsible for identifying and putting in place the appropriate Chapter V transfer mechanism for it, and for carrying out any required transfer impact assessment.
## 11\. General Provisions
- 11.1. **Liability**. Each Party's liability arising out of or related to this DPA shall be subject to the limitations of liability set forth in the Principal Agreement.
- 11.2. **Confidentiality**. The Parties agree that this DPA and any information exchanged in connection with it are confidential and shall be handled in accordance with the confidentiality provisions of the Principal Agreement.
- 11.3. **Notices**. All notices and communications given under this DPA must be in writing and will be delivered in accordance with the notice provisions of the Principal Agreement.
- 11.4. **Severability**. If any provision of this DPA is found by any court or administrative body of competent jurisdiction to be invalid, unenforceable, or illegal, that provision shall be modified to the minimum extent necessary to make it valid and enforceable, or, failing that, severed, and the other provisions shall remain in force.
- 11.5. **Data Protection Contact**. Questions, requests, or notices relating to data protection or this DPA may be addressed to the Processor's data protection contact at [contact@centralcsp.com](mailto:contact@centralcsp.com).
- 11.6. **No waiver**. No failure or delay by either Party in exercising any right under this DPA operates as a waiver of it, and a waiver is effective only if given in writing.
- 11.7. **Language**. This DPA is drafted in English, which is the authoritative and legally binding version. Any translation is provided for convenience only, and in the event of any conflict or divergence between the English version and a translated version, the English version prevails.
## 12\. Governing Law and Jurisdiction
- 12.1. This DPA and any dispute or claim arising out of or in connection with it or its subject matter or formation shall be governed by and construed in accordance with the laws of France.
- 12.2. The Parties irrevocably agree that the _Tribunal de commerce de Grenoble_ (France) shall have exclusive jurisdiction to settle any dispute or claim that arises out of or in connection with this DPA, in accordance with the dispute resolution provisions of the Principal Agreement.
## Annex 1: Details of the Processing
This Annex forms part of the DPA and describes the processing of Personal Data performed by the Processor on behalf of the Controller, as required by Article 28(3) of the GDPR.
| Specification | Details |
| --- | --- |
| Subject-matter of the Processing | The processing of browser-generated security telemetry, reports delivered through the browser Reporting API (including Content Security Policy (CSP), Network Error Logging (NEL), deprecation, intervention, crash, COOP/COEP, Document-Policy, Certificate Transparency, and integrity reports), together with website security scan data and script inventory data generated by, or in relation to, the Customer's websites, applications, and online services. |
| Duration of the Processing | For the term of the Principal Agreement between the Customer and the Processor, and until all Customer Data is deleted in accordance with Section 8 of the DPA. |
| Nature and Purpose of the Processing | To provide web security and compliance services to the Customer, including: - Collecting, storing, and analysing all supported browser Reporting-API report types via a dedicated reporting endpoint to identify security threats and misconfigurations. - Generating alerts on security-relevant events (e.g., new scripts, new origins, hash changes, violation spikes) and transmitting them to the delivery channels the Customer configures. Where the Customer selects a channel operated by a third party (for example Slack, Microsoft Teams, PagerDuty, an email address, or a webhook endpoint), the Customer directs that transmission as Controller and the recipient is a Customer-Directed Destination, not a Sub-processor. - Maintaining an inventory of the scripts loaded on the Customer's pages and detecting known vulnerabilities (CVEs) affecting them. - Producing auditor-ready PCI DSS v4 evidence (e.g., requirements 6.4.3 and 11.6.1) from real browser traffic. - Scanning and evaluating a website page requested by the Customer to analyse its security configuration and identify vulnerabilities, misconfigurations, and compliance gaps. - Using aggregated report data to help the Customer automatically generate and optimise secure CSP policies via a policy builder tool. - Making Customer Data available to the Customer through the API and the MCP integration, where the Customer chooses to enable them. |
| Type of Personal Data Processed | The Services are designed to process technical security telemetry rather than personal data, and the personal data processed is limited and largely incidental. It is contained within the browser reports and scan data, and may include: - **Technical and navigational data:** the URL of the page where an event occurred (document-uri), a blocked or referenced resource (blocked-uri), the referrer URL (referrer), the violated and effective CSP directives, error details, the browser user-agent string, and the operating system. - **Online identifiers:** an IP address may appear where a URL, referrer, or blocked resource is itself an IP address, and other identifiers may appear where they are embedded in a URL or query string. The Processor does not process special categories of personal data and does not process cardholder data. |
| Categories of Data Subjects | The Personal Data processed relates to End-Users of the Customer's websites, applications, and online services. |
## Annex 2: Technical and Organizational Security Measures
This Annex describes the technical and organizational security measures implemented by the Processor to protect Customer Data.
### 1\. Access Control
- **Personnel Access**: Access to systems processing Customer Data is granted on a need-to-know basis according to the principle of least privilege. Access rights are reviewed periodically and revoked upon termination of employment or change in job function.
- **Authentication**: All personnel access to production environments requires multi-factor authentication (MFA).
- **Logging**: Access to production systems is logged and monitored for unauthorized activity.
### 2\. Encryption
- **In Transit**: All Customer Data transmitted over public networks (e.g., from an End-User's browser to the reporting endpoint, or between the Processor's internal services) is encrypted using strong, industry-standard protocols (e.g., TLS 1.2 or higher).
- **At Rest**: All Customer Data stored on the Processor's systems, including backups, is encrypted at rest using AES-256.
### 3\. System Security and Resilience
- **Vulnerability Management**: The Processor conducts regular vulnerability scans of its systems and applications. Critical security patches are applied in a timely manner.
- **Network Security**: The Processor employs firewalls, network segmentation, and other measures to protect its network from unauthorized access.
- **Availability and Resilience**: The Processor utilizes redundant, fault-tolerant infrastructure hosted with leading cloud providers to ensure the ongoing availability and resilience of the Services. Regular backups of Customer Data are performed to enable timely restoration in the event of a physical or technical incident.
### 4\. Incident Response and Management
- **Incident Response**: The Processor detects, contains, investigates, and remediates security incidents.
- **Breach Notification**: The Processor has established procedures to ensure timely and effective notification to Customers in the event of a Personal Data Breach, in accordance with Section 6 of the DPA.
### 5\. Personnel Security
- **Training**: All personnel undergo regular security and data privacy awareness training.
- **Confidentiality**: All personnel are subject to binding confidentiality obligations as a condition of their employment.
### 6\. Data Deletion
- **Secure Disposal**: The Processor utilizes secure data disposal methods to ensure that Customer Data is permanently and irretrievably deleted from its systems upon the expiration of the retention period defined in Section 8 of the DPA.
### 7\. Physical Security
- **Data Centers**: The Processor utilizes data centers provided by major cloud infrastructure providers that maintain high standards of physical security. These data centers are protected by measures including 24/7 security personnel, video surveillance, and strict physical access controls.
- **Certifications**: The Processor's infrastructure provider, OVHcloud, holds third-party certifications including SOC 2 and ISO 27001 covering the data centers and infrastructure services it supplies. These are the provider's certifications, attesting to the controls of the underlying infrastructure. CentralCSP does not itself currently hold SOC 2 or ISO 27001 certification. CentralCSP's own controls are those described in this Annex and are subject to the audit rights in Section 9 of the DPA.
### 8\. Data Residency and Minimisation
- **Data Residency**: All Customer Data is stored and backed up exclusively within the European Union (OVHcloud, France). Website scans requested by the Customer are performed from within the European Union (France). This commitment covers the Processor's own infrastructure and that of its Sub-processors. It does not cover Customer-Directed Destinations: where the Customer configures the Services to send data to a recipient it selects, the location of that recipient is determined by the Customer, and Section 10 of the DPA applies.
- **Data Minimisation**: The Services are designed to process technical security telemetry; the Processor does not deliberately collect End-User identifiers beyond what is incidentally contained in browser reports and scan data.
## Annex 3: Authorized Sub-processors
This Annex lists the Sub-processors authorized by the Customer to process Customer Data.
As of the Effective Date of this DPA, the Processor engages the following Sub-processors:
| Sub-Processor | Purpose | Types of Data Processed | Location |
| --- | --- | --- | --- |
| OVHcloud | Cloud hosting and infrastructure provider for all core platform services and data. | All Customer Data, account data, service configuration, backups. | France (EU) |
| Bunny.net | Content delivery network (CDN) and edge layer, including in front of the reporting endpoint, and delivery of static assets. | IP address, browser/device information, requested URLs, and browser reports in transit through the reporting endpoint edge. | European Union |
| Scaleway | Transactional and notification email delivery. | Name, email address, email content, engagement data. | France (EU) |
The Processor stores all Customer Data within the European Union. Bunny.net processing is restricted to European points of presence. Payment processing (Stripe) is not listed in this Annex: billing is processing that the Processor carries out for its own purposes as an independent controller (see Section 2.1), governed by the Processor's Privacy Policy, and Stripe is therefore not a Sub-processor of Customer Data under this DPA. Bot and abuse protection on public forms is provided by a CAPTCHA that the Processor self-hosts on its own EU infrastructure; it is therefore not a Sub-processor and no CAPTCHA data is shared with any third party.
Destinations the Customer configures itself (alert delivery channels and AI assistants or agents connected through the API or the MCP integration) are not listed here. They are Customer-Directed Destinations engaged by the Customer, not Sub-processors of the Processor, and Sections 2.5, 4.2, and 10 of this DPA apply to them.
---
Available in: [en](https://centralcsp.com/en/legal/dpa/), [fr](https://centralcsp.com/fr/legal/dpa/)
```yaml
title: "Legal Notice - CentralCSP"
description: "Statutory publisher, hosting, and mediation information for centralcsp.com and the CentralCSP service."
url: "https://centralcsp.com/en/legal/mentions-legales/"
lang: "en"
```
Legal
# Legal Notice - CentralCSP
Last updated: August 9, 2026
## 1\. Publisher of the website
| Item | Detail |
| --- | --- |
| Company name | CentralSaaS, operating the CentralCSP service |
| Legal form | Société par actions simplifiée (SAS) |
| Share capital | €1,000 |
| Registered office | 1 Allée des Frênes, 38240 Meylan, France |
| RCS registration | Grenoble 927 890 756 |
| SIRET | 927 890 756 00012 |
| Intra-community VAT number | FR36927890756 |
| Email | contact@centralcsp.com |
## 2\. Director of publication
The director of publication (_directeur de la publication_), within the meaning of Article 1-1 of law no. 2004-575 of 21 June 2004 (_LCEN_), is **Théotime Queré**.
## 3\. Hosting provider
The website centralcsp.com and the CentralCSP service are hosted by:
- **OVH SAS**, a _société par actions simplifiée_ with a share capital of €10,174,560
- Registered office: 2 rue Kellermann, 59100 Roubaix, France
- RCS Lille Métropole 424 761 419
- Telephone: +33 9 72 10 10 07
- Website: [ovhcloud.com](https://www.ovhcloud.com)
In accordance with Article 1-1 of the _LCEN_, OVH SAS also provides the storage of the data processed through the CentralCSP service. All data processed by the CentralCSP service is stored within the European Union. See our [Privacy Policy](https://centralcsp.com/en/legal/privacy/) for details.
## 4\. Intellectual property
The website centralcsp.com, the CentralCSP service, and all of their components (including the structure, source code, texts, graphics, logos, icons, images, and databases) are the exclusive property of CentralSaaS or its licensors, and are protected by French and international intellectual property law.
Any reproduction, representation, modification, publication, adaptation, or exploitation of all or part of these elements, by any means and in any form, is prohibited without the prior written authorisation of CentralSaaS, except as permitted by Article L.122-5 of the French _Code de la propriété intellectuelle_.
The CentralCSP name and logo are trademarks. Third-party trademarks and logos appearing on the website remain the property of their respective owners and are used for identification purposes only.
## 5\. Personal data
CentralSaaS processes personal data as described in our [Privacy Policy](https://centralcsp.com/en/legal/privacy/), which sets out the purposes, legal bases, retention periods, and the rights available to you under the General Data Protection Regulation (GDPR).
Questions and requests relating to personal data may be addressed to our data protection contact at [contact@centralcsp.com](mailto:contact@centralcsp.com).
You may also lodge a complaint with the French data protection authority:
- **CNIL**: 3 Place de Fontenoy, TSA 80715, 75334 Paris Cedex 07, France ([cnil.fr](https://www.cnil.fr))
## 6\. Cookies
The centralcsp.com marketing website is cookieless. We measure audience with a self-hosted, privacy-focused analytics tool that sets no cookies and builds no cross-site profile, so no consent banner is required. Our authenticated services use strictly necessary cookies only. See Section 7 of the [Privacy Policy](https://centralcsp.com/en/legal/privacy/).
## 7\. Applicable law
This website and the CentralCSP service are governed by French law. The CentralCSP service is offered exclusively to businesses and professionals. Disputes are subject to the dispute resolution provisions of our [Terms of Service](https://centralcsp.com/en/legal/terms/).
## 8\. Contact
- Email: [contact@centralcsp.com](mailto:contact@centralcsp.com)
- Postal address: CentralSaaS, 1 Allée des Frênes, 38240 Meylan, France
---
Available in: [en](https://centralcsp.com/en/legal/mentions-legales/), [fr](https://centralcsp.com/fr/legal/mentions-legales/)
```yaml
title: "Privacy Policy - CentralCSP"
description: "How CentralCSP, the EU-hosted client-side security platform, collects, uses, and protects your personal data."
url: "https://centralcsp.com/en/legal/privacy/"
lang: "en"
```
Legal
# Privacy Policy - CentralCSP
Last updated: October 4, 2026
## 1\. Introduction and Scope
This Privacy Policy explains how CentralCSP ("CentralCSP", "we", "us", "our") collects, uses, and protects personal data. CentralCSP provides web security and compliance services centred on client-side monitoring: we collect and analyse the reports that browsers send through the Reporting API, maintain an inventory of the scripts running on our Clients' pages, generate event-based alerts, produce PCI DSS evidence, scan and evaluate website security configurations, and help our Clients build and optimise Content Security Policies (CSP) to defend against threats such as cross-site scripting (XSS) and data injection.
This policy applies to all personal data we process as a Data Controller. This includes data from visitors to our website (centralcsp.com), individuals who use our free tools (the CSP Scanner, CSP Evaluator, CSP Hash Calculator, SRI Hash Calculator, Security Headers Scanner, Reporting-API Checker, Technology & Vulnerability Checker, and Compare tool), registered users of our free trial and paid services, and individuals who contact us. It also explains our separate role as a Data Processor when we handle data on behalf of our Clients.
In line with data protection best practice, including the guidance of the French Data Protection Authority (CNIL) and the European Data Protection Board (EDPB), this policy is layered: summary tables and clear headings let you find what is relevant to you quickly, and each summary is followed by a fuller explanation. Our aim is to be concise, transparent, intelligible, and easily accessible, in keeping with the General Data Protection Regulation (GDPR).
## 2\. Who We Are and How to Contact Us
### 2.1. Identity of the data controller
For the purposes of the GDPR and other applicable data protection laws, the Data Controller responsible for the processing described in this policy is:
- Company: CentralSaaS, _société par actions simplifiée_ (SAS), operating the CentralCSP service
- Registered office: 1 Allée des Frênes, 38240 Meylan, France
- RCS: Grenoble 927 890 756
- Contact: [contact@centralcsp.com](mailto:contact@centralcsp.com)
Full statutory information (share capital, SIRET, VAT number, hosting) is available on our [Legal Notice](https://centralcsp.com/en/legal/mentions-legales/) page.
### 2.2. Contact for privacy matters
For any question, concern, or request relating to your personal data or to the exercise of your rights, contact us at [contact@centralcsp.com](mailto:contact@centralcsp.com), which reaches our data protection contact.
### 2.3. Data protection contact
The GDPR requires a formal Data Protection Officer (DPO) where an organisation's core activities consist of processing operations that require regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special categories of data.
We have assessed our activities against the criteria in Article 37 of the GDPR. Our services are designed to process technical security telemetry rather than personal data: the personal data contained in browser reports and scan data is limited and largely incidental, and we do not profile end-users. On that basis we have determined that the appointment of a formal DPO is not mandatory for us at this time.
We nonetheless take accountability seriously and have designated an internal data protection contact, reachable at [contact@centralcsp.com](mailto:contact@centralcsp.com), to oversee our data protection practices and handle related requests. We keep this determination under review as our services evolve.
## 3\. Key Definitions
- **Personal Data**: any information relating to an identified or identifiable natural person ("Data Subject"), including direct identifiers such as a name or email address, and indirect identifiers such as an IP address, an online identifier, or a URL where it can be linked back to an individual.
- **Processing**: any operation performed on Personal Data, whether automated or not, including collection, recording, storage, analysis, use, disclosure, and erasure.
- **Data Subject**: the individual to whom the Personal Data relates, whether a Client or an End-User.
- **Client**: the individual or entity that registers for and uses CentralCSP's services, including free trials and paid subscriptions. Our contractual relationship is with the Client.
- **End-User**: an individual who visits or interacts with a website or application operated by one of our Clients. We have no direct relationship with End-Users.
- **Data Controller**: the party that determines the purposes and means of the processing of Personal Data.
- **Data Processor**: the party that processes Personal Data on behalf of the Controller.
- **Browser Report**: a report generated by a web browser through the Reporting API and sent to a designated endpoint. This includes Content Security Policy (CSP), Network Error Logging (NEL), deprecation, intervention, crash, Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy (COOP/COEP), Document-Policy, Certificate Transparency, and integrity reports. Such reports typically describe a technical event (for example a blocked resource and the page where it occurred) and may incidentally contain personal data such as an IP address, or identifiers embedded in a URL or query string.
The distinction between "Client" and "End-User" is fundamental to this policy: it lets us explain clearly our different roles and responsibilities for each group's data.
## 4\. Our Two Roles: Controller and Processor
CentralCSP acts in two distinct capacities under the GDPR. Understanding this dual role explains which parts of this policy apply to you.
### 4.1. CentralCSP as a Data Controller
We are the Controller when we determine the "why" and "how" of processing for our own business purposes. This applies to:
- **Client account information**: name, work email, company, and a hashed password, collected when a Client registers, so we can create and manage the account, authenticate the Client, and provide the service.
- **Billing and subscription information**: the information needed to process payments and manage subscriptions, handled by our third-party payment processor.
- **Website visitor data**: technical data such as browser and device information processed when you visit centralcsp.com. Our marketing website is cookieless and our analytics do not identify you (see Section 7).
- **Free tool usage data**: the website URL, CSP policy, or HTTP headers you submit to a free tool (the CSP Scanner, CSP Evaluator, SRI Hash Calculator, Security Headers Scanner, Reporting-API Checker, Technology & Vulnerability Checker, or Compare tool), the results of the analysis, and the IP address of the request, processed to return the requested analysis and kept as described in Section 5.2.
- **Communication data**: your name, contact details, and message content when you contact us through our contact form or by email.
### 4.2. CentralCSP as a Data Processor
We are a Processor when we process personal data on behalf of, and under the instructions of, our Clients. In that scenario the Client is the Controller. This applies primarily to the Browser Reports and related security telemetry ingested through our monitoring service.
- **How it works**: our service provides Clients with a reporting endpoint. The Client configures their website to send Browser Reports to this endpoint, and we collect and analyse the resulting telemetry, maintain a script inventory, detect known vulnerabilities (CVEs), raise alerts, generate PCI DSS evidence, and help build CSP policies.
- **Data processed**: the data within these reports (which may include an End-User's IP address, the page visited, and the blocked or referenced resource) is Personal Data of the End-User. We process it solely to provide our services to the Client.
- **The Client's responsibility**: as the Controller for their End-Users' data, the Client is responsible for having a lawful basis (for example legitimate interest) to collect this data and to instruct us to process it, and for informing their End-Users in their own privacy notice.
- **Data Processing Agreement (DPA)**: our processing on the Client's behalf is governed by our [Data Processing Agreement](https://centralcsp.com/en/legal/dpa/), which sets out our obligations as a Processor, including processing only on the Client's instructions, applying appropriate security measures, and assisting the Client with its own GDPR obligations.
## 5\. What We Process, Why, and On What Lawful Basis
Every processing activity must rest on a lawful basis under Article 6 of the GDPR. As a Controller, we rely principally on:
- **Performance of a contract (Art. 6(1)(b))**: where processing is necessary to provide a service you have requested or to take pre-contract steps.
- **Legitimate interests (Art. 6(1)(f))**: where we have a legitimate business interest that is not overridden by your rights.
- **Consent (Art. 6(1)(a))**: where you have given clear, affirmative agreement for a specific purpose.
### 5.1. Summary of our processing (as a Data Controller)
| When you... | Categories of personal data | Purpose | Lawful basis |
| --- | --- | --- | --- |
| Browse centralcsp.com | Browser/device information, approximate location, pages viewed (cookieless, non-identifying analytics). | To operate, secure, and measure the performance of our website. | Legitimate interest. |
| Use any free tool (CSP Scanner, CSP Evaluator, SRI Hash Calculator, Security Headers Scanner, Reporting-API Checker, Technology & Vulnerability Checker, Compare) | Submitted website URL, CSP policy or HTTP headers, the results of the analysis, and your IP address. | To return the requested analysis, to prevent abuse, and for usage statistics, debugging and troubleshooting of our tools. | Legitimate interest. |
| Register for a free trial or paid account | Name, work email, company, password (hashed). | To create and manage your account, authenticate you, and provide the service. | Performance of a contract. |
| Use our paid services (monitoring, alerting, CSP Builder, PCI DSS, script inventory) | Account and usage data, configuration, generated policies and reports, billing information. | To deliver, maintain, support, and bill for the services you have subscribed to. | Performance of a contract. |
| Contact us | Name, email, company (optional), the content of your message. | To respond to your enquiry and manage our relationship with you, and to protect the form from abuse. | Legitimate interest. |
### 5.2. Free tools
Our free tools (the CSP Scanner, CSP Evaluator, SRI Hash Calculator, Security Headers Scanner, Reporting-API Checker, Technology & Vulnerability Checker, and Compare tool) provide an immediate analysis of a site's security posture. When you submit a URL, policy, or set of headers, we process it on the basis of our legitimate interest: first to provide the analysis you have requested, and second to maintain and improve our tools. The processing is initiated by you and limited to the data you submit.
The CSP Hash Calculator runs entirely in your browser: nothing you enter in it is sent to us.
What you submit is intended to describe a website's configuration rather than a person, and in most cases it contains no personal data. It can nonetheless contain personal data where an identifier is embedded in a URL or query string you submit, for example a session token, a user ID, or an email address in a parameter. We treat any such identifier as personal data, and we ask that you avoid submitting URLs that contain one.
We keep a record of each use of the free tools, without time limit, for usage statistics, debugging and troubleshooting. It includes what was analysed (the submitted URL or policy; for the Technology & Vulnerability Checker, the URL without its query string), when, and the results of the analysis, such as scores, findings, or the number of technologies and vulnerabilities found. The IP address used for each request is recorded with it and deleted after twelve (12) months, as described in Section 11.
The Technology & Vulnerability Checker analyses the public page you submit to identify the technologies it uses, their versions, and publicly known vulnerabilities (CVEs) affecting them. Its results are displayed only in your browser, are not stored for sharing, and are deleted from our servers shortly after the analysis. Exports (PDF, CSV, or CycloneDX JSON) are files you download yourself.
By submitting a URL to a tool that fetches or scans it, you confirm that you own the corresponding website or that you have authorisation from its owner to have it analysed. We use your IP address to apply rate limits and to detect and prevent abuse.
Our browser extension runs entirely in your browser and sends us no data.
### 5.3. Registering for and using our services
When you sign up for a free trial or a paid account you enter into a service agreement with us. Processing your account data (name, email, hashed password) and usage data is necessary for the performance of that contract: to create and authenticate your account, provide the service, manage your subscription, process payments, and send you essential service notices (for example security alerts or billing information).
### 5.4. Contacting us
When you contact our support or sales teams we process the information you provide on the basis of our legitimate interest in responding to enquiries and managing our relationships.
### 5.5. Service communications
We do not send marketing or promotional communications, and we do not use your data to build a marketing profile. We only send communications that are necessary to provide the service, such as security alerts, billing notices, and important changes to our terms or this policy (transactional messages on the basis of performance of a contract).
## 6\. Automated Processing and the CSP Builder
Our services, and the CSP Builder in particular, use automation to simplify security for our Clients. This section explains how that works.
### 6.1. How the CSP Builder works
The CSP Builder generates an optimised Content Security Policy for a Client's website by analysing the Browser Reports the site sends to our reporting endpoint over a chosen period. From these reports it identifies the external domains and resources the site legitimately needs, combines that analysis with security best practice and compliance requirements, and recommends a new, more secure policy.
### 6.2. Automated decision-making under Article 22 GDPR
Article 22 gives individuals the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects on them. The CSP Builder does not fall within Article 22 because:
- **No legal or significant effect on individuals**: its output is a technical policy recommendation delivered to our Client (a developer or administrator), not to the End-User. The policy governs which resources a browser may load; it does not affect an End-User's legal status or deny them a service.
- **Human intervention**: the process is not solely automated. An interactive review and approval workflow requires the Client to review, assess, and approve any recommended policy before it is deployed. The Client remains the decision-maker.
### 6.3. Safeguards
In line with guidance from authorities such as the CNIL, we apply safeguards to our automated processing:
- **Purpose limitation**: report data is processed only to provide the service to the specific Client that is its source, namely generating and optimising CSP policies, delivering security insights, maintaining the script inventory, detecting vulnerabilities (CVEs), and raising alerts. It is not used to profile End-Users or for any unrelated purpose.
- **Data minimisation and aggregation**: the system identifies patterns from aggregated data (for example "domain cdn.example.com was requested 10,000 times") rather than tracking any single End-User.
- **A rule-based engine**: the CSP Builder is a rule-based analysis engine, not a generative large language model, and its recommendations are always subject to the Client's review before deployment.
### 6.4. No AI training on your data
We do not use your data, including account data, browser reports, scan results, and free-tool submissions, to train, fine-tune, or develop artificial intelligence or machine-learning models, and we do not ourselves disclose it to any third-party AI provider or service. Our tools rely on rule-based analysis engines rather than generative AI.
### 6.5. When you connect an AI assistant yourself
This commitment describes what we do with your data. It does not restrict what you choose to do with it.
Our platform offers an API and an MCP (Model Context Protocol) integration, which exist so you can connect your own tools, including an AI assistant or agent, to your CentralCSP workspace. If you enable one of these, the data you request flows from us to the destination you have chosen, on your instruction. That transmission is initiated and controlled by you, not by us. You are responsible for it, including for the terms on which the recipient handles the data, for whether it is used to train a model, and for any transfer outside the European Economic Area that results. The same applies to alerts you route to a channel such as Slack, Microsoft Teams, PagerDuty, an email address, or a webhook endpoint.
## 7\. Cookies and Analytics
Our marketing website centralcsp.com is designed to be cookieless. We do not use advertising or third-party tracking cookies on it, and we do not need a cookie consent banner for our analytics. If you reach us from one of our ads, the click identifier in the link is kept in your browser's session storage (not a cookie) for the duration of the tab only, so that a later sign-up can be attributed to that ad.
- **Analytics**: we measure website performance with a privacy-focused, cookieless analytics tool that we self-host on our EU infrastructure. It does not use cookies, does not collect personal data for advertising, does not build cross-site profiles, and does not track you across websites. Aggregated, non-identifying metrics are processed on the basis of our legitimate interest, consistent with CNIL guidance on audience measurement.
- **Authenticated services**: our sign-in service (auth.centralcsp.com) and dashboard (app.centralcsp.com) are separate from this marketing website and use only strictly necessary cookies (for example a session token to keep you signed in and a routing cookie). They are self-hosted on our EU infrastructure, are essential to provide the service you have requested, and are not used for tracking.
## 8\. Sharing, Service Providers and Sub-processors
We do not sell your personal data. We share it only with carefully selected third-party service providers who help us run our business, under binding data processing agreements that require them to uphold strict security and data protection standards. Our lawful basis for this sharing is the same as for the underlying processing (performance of a contract or legitimate interest).
| Recipient | Purpose | Types of data processed | Location |
| --- | --- | --- | --- |
| OVHcloud | Cloud hosting and infrastructure for all core platform services and data. | All Client and account data, service configuration, browser reports, scan results, backups. | France (EU) |
| Bunny.net | Content delivery network (CDN) and edge layer, including in front of the reporting endpoint, and delivery of static assets. | IP address, browser/device information, requested URLs, and browser reports in transit through the reporting endpoint edge. | European Union |
| Scaleway | Transactional and notification email delivery. | Name, email address, email content, engagement data. | France (EU) |
| Stripe | Payment processing for subscriptions and billing. | Name, email, payment method, billing address, transaction details. | Ireland (contracting entity); limited US transfers governed by DPF + SCC |
OVHcloud, Bunny.net and Scaleway are also Sub-processors of Client Data within the meaning of our [Data Processing Agreement](https://centralcsp.com/en/legal/dpa/), and are listed in its Annex 3. Stripe is not: we engage it for our own billing purposes as an independent controller, so it receives account and billing data but never Client Data, and it is deliberately absent from that Annex.
Stripe processes payments as our processor when facilitating transactions, and additionally acts as an independent data controller for certain purposes inherent to payment processing (such as fraud monitoring, compliance with anti-money-laundering law, and its relationships with banks and card networks), as described in its own privacy documentation.
### 8.1. Destinations you choose
The providers above are ones we engage to run our platform. They are distinct from the destinations you configure yourself: an alert channel (Slack, Microsoft Teams, PagerDuty, an email address, a webhook endpoint) or an AI assistant connected through our API or MCP integration. Those are not our sub-processors: you engage them directly, and data reaches them because you instructed us to send it. We do not control what they do with it. Section 6.5 explains this in more detail.
## 9\. International Data Transfers
Our aim is to keep your data within the European Economic Area (EEA) wherever possible.
### 9.1. Primary storage
All Client data and End-User data processed for our core services (including Browser Reports and all scan results from the Scanner, Evaluator, and CSP Builder) is stored and processed on OVHcloud servers within the European Union. Website scans that a Client requests are performed from within the European Union. This significantly reduces the complexity and risk of international transfers for our core service.
### 9.2. Safeguards for other transfers
Some ancillary sub-processors (for example our payment processor) may transfer limited data outside the EEA, in particular to the United States. Where we or a sub-processor transfers personal data to a country without an adequacy decision, the transfer is protected by a recognised GDPR mechanism, namely the European Commission's Standard Contractual Clauses and, where applicable, certification under the EU-US Data Privacy Framework.
### 9.3. Transfers you initiate
Our EU-residency commitment covers the data we hold on our own infrastructure and that of our sub-processors. It does not cover destinations you choose. If you route alerts to a channel hosted outside the EEA, or connect an AI assistant through our API or MCP integration, that transfer is made on your instruction and under your control. Where you act as a Controller, you are responsible for identifying the appropriate transfer mechanism for it.
## 10\. Data Security
Securing the data we process is central to our mission. We implement appropriate technical and organisational measures to protect personal data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, in line with the GDPR. These include:
- **Encryption**: data is encrypted in transit using industry-standard TLS (1.2 or higher), and all data we store, including backups and generated policies, is encrypted at rest using AES-256.
- **Access control**: access to personal data is restricted to authorised personnel on a need-to-know basis under the principle of least privilege, with multi-factor authentication for production systems.
- **Pseudonymisation**: passwords are stored using irreversible hashing.
- **Resilience and redundancy**: our infrastructure is designed for high availability, with regular backups to enable restoration after an incident.
- **Testing and auditing**: we run regular vulnerability scans and security assessments.
- **Abuse prevention**: automated measures protect our website, forms, and tools against bots and automated abuse. They run on our own EU infrastructure and share no data with any third party.
- **Breach response**: we identify and investigate personal data breaches. Where a breach affects data we process for a Client, we notify the Client (the Controller) without undue delay so it can meet its own notification obligations.
## 11\. Data Retention
In line with the GDPR's storage-limitation principle, we keep personal data in an identifiable form no longer than necessary for the purposes for which it was collected. Retention depends on the type of data and any legal obligations, and we review our schedule periodically.
| Type of data | Retention period | Justification |
| --- | --- | --- |
| Client account data (name, email, company) | Kept until you delete your account; deleted thereafter, subject to legal retention obligations. | Performance of contract; legitimate interest (business records); legal obligations (for example tax and accounting rules require keeping certain records after account deletion). |
| Browser Reports (processed for Clients) | Rolling 90 days maximum (or sooner if you delete the corresponding website or workspace in the dashboard), then deleted or irreversibly aggregated. | Necessary for monitoring, alerting, the CSP Builder, and statistics, which rely on recent historical data. Deleted automatically on a rolling basis. |
| Scan results (on-demand website scans, processed for Clients) | No expiry. Kept indefinitely or aggregated into statistics. | Performance of contract and legitimate interest: so you can track a site's security posture over time and so we can produce security statistics. Scan results are designed to describe a website's publicly accessible configuration; where one incidentally contains personal data (for example an identifier embedded in a submitted URL), we delete or redact it on request. |
| Free tool usage records (what was analysed, when, and the results of the analysis) | No expiry. Kept indefinitely. | Legitimate interest: usage statistics, debugging and troubleshooting of our tools. These records describe websites rather than people; where one incidentally contains personal data (for example an identifier embedded in a submitted URL), we delete or redact it on request. |
| IP address of each free-tool request | 12 months, then deleted. | Legitimate interest: detecting and preventing abuse of our free tools, and troubleshooting. |
| Technology & Vulnerability Checker results | Deleted shortly after the analysis. | Legitimate interest: delivering the analysis you requested to your browser. |
| Website visitor and analytics data (centralcsp.com) | Aggregated, non-identifying metrics retained for 24 months. No individual visitor record is kept. | Legitimate interest: measuring and improving the performance of our website. Our analytics are cookieless and do not identify you. |
| Security, access, and audit logs | 12 months, then deleted. Logs relating to an active security investigation are kept until it closes. | Legitimate interest: detecting, investigating, and responding to security incidents and abuse; and demonstrating accountability. |
| Anonymised / aggregated statistics | Indefinitely. | Used for service improvement, security research, and our periodic 'State of the Web' report. This data is no longer personal data. |
| Contact and support enquiries | 36 months from the last contact, then deleted. | Legitimate interest: context for future communications and quality control. |
| Billing and accounting records | 10 years from the end of the financial year. | Legal obligation: Article L.123-22 of the French Code de commerce. |
## 12\. Your Data Protection Rights
Under the GDPR you have a number of rights over your personal data. This section applies to data for which we are the Controller.
### 12.1. How to exercise your rights
Submit your request in writing to [contact@centralcsp.com](mailto:contact@centralcsp.com). We will respond without undue delay and within one month of receipt at the latest; this may be extended by two further months where necessary given the complexity or number of requests, in which case we will tell you within the first month. We do not charge a fee unless your request is manifestly unfounded or excessive.
### 12.2. Your rights
- **To be informed**: to receive clear, transparent information about how we use your data (which is why we provide this policy).
- **Of access**: to obtain a copy of your personal data and related information.
- **To rectification**: to have inaccurate or incomplete data corrected.
- **To erasure** ("right to be forgotten"): to have your data deleted where there is no overriding reason for us to keep it (this is not an absolute right).
- **To restrict processing**: to have further use of your data suppressed in certain circumstances.
- **To data portability**: to receive and reuse data you provided to us where processing is based on consent or contract and carried out by automated means.
- **To object**: to object to processing based on our legitimate interests, and to object to direct marketing at any time.
- **To withdraw consent**: where a processing operation is based on your consent, to withdraw that consent at any time, without affecting the lawfulness of processing carried out before the withdrawal.
- **To set post-mortem directives**: under Article 85 of the French _Loi Informatique et Libertés_, to define directives on the retention, erasure, and communication of your personal data after your death, and to designate a person responsible for their execution. You may register or update such directives, or designate that person, by contacting us at the address above; absent directives, your heirs may exercise the rights provided by law.
- **In relation to automated decision-making**: not to be subject to a decision based solely on automated processing with legal or similarly significant effects. As explained in Section 6, our services do not carry out such processing.
You also have the right to lodge a complaint with a supervisory authority, in France the CNIL ([www.cnil.fr](http://www.cnil.fr)).
### 12.3. An important note for End-Users
The rights above are exercised against the Data Controller.
- If you are a **Client**, you can exercise your rights directly with us regarding your account and usage data.
- If you are an **End-User** of one of our Clients' websites, the Controller for any data contained in a Browser Report is the owner of that website (our Client).
If your request concerns data collected while you visited a third-party website that uses our services, you must direct it to the owner of that website. As a Processor we are legally bound to act on our Client's instructions and will assist them in responding, in accordance with our DPA.
## 13\. Children's Privacy
Our services are intended for a professional audience and are not directed at individuals under 16. We do not knowingly collect personal data from children under 16. If we learn that we have inadvertently done so, we will delete it as soon as possible.
## 14\. Changes to This Policy
We may update this Privacy Policy to reflect changes in our practices, technology, or legal requirements. When we do, we will update the "Last updated" date above. For material changes we will give notice at least thirty (30) days before the change takes effect, by email to Clients or by a prominent notice on our website.
This policy is a notice, not a contract. Changes to it do not modify the Terms of Service, which are amended only as set out in Section 11.7 of those Terms.
## 15\. Language
This policy is published in English and French. The English version is authoritative; if there is any discrepancy between the two, the English version prevails.
---
Available in: [en](https://centralcsp.com/en/legal/privacy/), [fr](https://centralcsp.com/fr/legal/privacy/)
```yaml
title: "Terms of Service - CentralCSP"
description: "The terms governing your use of CentralCSP, the EU-hosted client-side security platform."
url: "https://centralcsp.com/en/legal/terms/"
lang: "en"
```
Legal
# Terms of Service - CentralCSP
Last updated: October 4, 2026
## Preamble: Acceptance of Terms
These Terms of Service, including all documents, policies, and addenda incorporated by reference (collectively, the "Agreement" or "Terms"), form a legally binding contract between **CentralSaaS**, a _société par actions simplifiée_ incorporated under the laws of France, registered office at 1 Allée des Frênes, 38240 Meylan, France, registered with the _Registre du Commerce et des Sociétés_ of Grenoble under number **927 890 756**, operating the CentralCSP service ("CentralCSP", "we", "us", "our"), and the entity or individual creating an account or using the Services ("Customer", "you", "your").
By creating an account, clicking a button or checkbox indicating acceptance (for example "I Agree"), or using any part of the Service, you confirm that you have read, understood, and agree to be bound by this Agreement in its entirety. If you do not agree to all of its terms, you must not access or use the Service.
If you accept this Agreement on behalf of a company or other legal entity, you represent that you have authority to bind that entity, and "Customer", "you", and "your" refer to that entity. If you lack such authority, you must not accept this Agreement or use the Service.
The Service is offered exclusively to businesses and to professionals acting in the course of their trade, business, craft, or profession. By accepting this Agreement, you represent and warrant that you are acting for purposes falling within your trade, business, craft, or profession, and not as a consumer within the meaning of the preliminary article of the French _Code de la consommation_. If you do not meet this condition, you must not create an account or use the Service.
This Agreement expressly incorporates by reference the CentralCSP Privacy Policy and the CentralCSP Data Processing Agreement (DPA), each of which is an integral part of these Terms.
## 1\. Definitions
- **Service(s)** means the web security and compliance tools and services provided by CentralCSP. This includes, without limitation, the CSP Scanner, CSP Evaluator, CSP Builder, the reporting endpoint (which collects all supported browser Reporting-API report types), event-based alerting, script inventory and vulnerability (CVE) detection, PCI DSS evidence generation, on-demand website security scanning, the hash and Subresource Integrity (SRI) calculators, the security-header checker, the technology and vulnerability checker, the CentralCSP browser extension, the API and MCP integrations, and any related websites (including centralcsp.com), software, documentation, and support. The definition also covers all updates, modifications, and new features introduced from time to time.
- **Customer Data** means all electronic data submitted to or generated by the Service by or for the Customer. It comprises (a) data provided by the Customer, including website URLs, existing Content Security Policies, information entered into forms, and browser reports transmitted to the reporting endpoint; and (b) data generated for the Customer, such as analysis reports, security and compliance scores, script inventories, vulnerability assessments, alerts, PCI DSS evidence, and the recommended Content Security Policies produced by the CSP Builder.
- **Personal Data** means information that constitutes "personal data", "personal information", or a similar term under applicable data protection laws, including the GDPR. This may include Authorized User account information (for example name and email) and personal data incidentally contained in browser reports (for example IP addresses or identifiers embedded in URLs).
- **Authorized User(s)** means an individual (such as an employee, consultant, or contractor of the Customer) authorized by the Customer to use the Service under the rights granted to the Customer.
- **Documentation** means the official user guides, articles, and technical or functional documentation for the Service provided by CentralCSP.
- **Intellectual Property Rights** means all registered and unregistered rights under patent, copyright, trademark, trade secret, database, and other intellectual property laws anywhere in the world.
- **Confidential Information** means non-public information disclosed by one party (the "Disclosing Party") to the other (the "Receiving Party") that is designated as confidential or that should reasonably be understood to be confidential. CentralCSP's Confidential Information includes the non-public aspects of the Service; the Customer's Confidential Information includes Customer Data.
- **Order Form** means an ordering document or online order specifying the Service(s) to be provided, entered into between the Customer and CentralCSP, incorporating this Agreement by reference and detailing the subscription term, fees, and any usage parameters.
- **Plan Limits** means the usage parameters applicable to the Customer's plan, including the maximum number of browser reports ingested per month, the maximum number of Authorized Users, and the maximum number of monitored websites, as published on the CentralCSP website or set out in the applicable Order Form.
- **Third-Party Service** means any product, service, or destination operated by a party other than CentralCSP that the Customer elects to connect to the Service, including alert delivery channels (for example Slack, Microsoft Teams, PagerDuty, email, or a webhook endpoint) and any AI assistant or agent connected through the API or MCP integrations.
- **SLA** means the CentralCSP Service Level Agreement, which sets out the availability commitment for the Services it covers and is negotiated and executed separately with Enterprise customers as an optional addition to their plan, incorporated into this Agreement by reference where agreed.
## 2\. The Service
### 2.1. License grant
Subject to the Customer's compliance with this Agreement and payment of all applicable fees, CentralCSP grants the Customer a limited, personal, non-exclusive, non-transferable, and non-sublicensable right to access and use the Service(s) and Documentation during the subscription term, solely for the Customer's internal business purposes and in accordance with any applicable Order Form. This Agreement grants a right to access and use the Service; it is not a sale of software or any underlying Intellectual Property Rights.
### 2.2. Acceptable use
The Customer shall not, and shall not permit any Authorized User or third party to:
- Reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code, structure, or algorithms of the Service, except to the extent this restriction is prohibited by applicable law.
- Access or use the Service to monitor its availability or performance, or for benchmarking or competitive purposes, including to build a competing product or service.
- Use the Service's scanning or analysis tools (for example the CSP Scanner or Evaluator, or on-demand scanning) on any website or digital property for which the Customer does not hold explicit, verifiable, and lawful authorization to conduct such security assessments. The Customer bears the burden of establishing that authorization, and shall retain evidence of it for the duration of the subscription term and for twelve (12) months thereafter. Breach of this obligation is a material breach and is grounds for immediate termination under Section 10.2.
- Use the Service to store or transmit content that is infringing, libelous, or otherwise unlawful, or that violates third-party privacy rights.
- Use the Service to transmit any viruses, worms, malicious code, or software intended to damage or alter a system or data.
- Attempt to gain unauthorized access to the Service or to any accounts, systems, or networks connected to it.
- Submit false, misleading, or malicious data (including fabricated browser or violation reports) with the intent to disrupt or degrade the Service or its analytical capabilities.
- Exceed the Plan Limits, or circumvent or attempt to circumvent any technical measure applied under Section 4.1.
For the avoidance of doubt, the passive analysis of publicly accessible resources performed by the free tools described in Section 2.5 is a permitted use of the Service. It remains subject to the authorization requirement set out above and in Section 2.5.
### 2.3. Service modifications, updates, and discontinuation
CentralCSP may modify, enhance, or update the Service(s) or any feature. We will make commercially reasonable efforts to ensure that such changes do not materially decrease the core functionality of the Service(s) purchased by the Customer during an active subscription term.
If CentralCSP discontinues the Service, or discontinues a feature that constitutes a material part of the Service(s) purchased by the Customer, during an active subscription term, CentralCSP will give the Customer at least thirty (30) days' prior written notice and will refund, on a pro-rata basis, any prepaid fees covering the period after the discontinuation takes effect. The Customer may terminate the affected subscription without penalty on receipt of such notice.
### 2.4. Customer's implementation
The Customer is solely responsible for the actions required to use the Service. This includes correctly configuring the reporting endpoint on its web properties and correctly deploying any Content Security Policies generated by the Service to its servers, headers, or infrastructure. CentralCSP provides tools and recommendations, but responsibility for implementation, testing, and validation rests with the Customer. CentralCSP is not responsible for damage arising from the Customer's incorrect or incomplete implementation of a policy.
### 2.5. Free trials and free tools
CentralCSP may offer free trials or free tools (such as the CSP Scanner, CSP Evaluator, CSP Hash Calculator, SRI Hash Calculator, Security Headers Scanner, Reporting-API Checker, Technology & Vulnerability Checker, and Compare tool). Any Service provided on a free basis is offered "AS IS", without warranty, support, or indemnification of any kind, and CentralCSP may modify, limit, or withdraw it at any time.
By submitting a URL, policy, or set of headers to a free tool, you represent that you own the corresponding website or digital property, or that you hold explicit, verifiable, and lawful authorization from its owner to have it analysed. This applies equally to the Technology & Vulnerability Checker. CentralCSP may rate-limit, block, or log submissions to protect the Service and to investigate suspected unauthorized use.
Data you enter during a free trial is retained in accordance with our standard retention periods, as set out in the Privacy Policy and in Section 8 of the DPA.
### 2.6. Beta and preview features
CentralCSP may make features available on a beta, preview, early-access, or experimental basis ("Beta Features"). Beta Features are identified as such, are provided "AS IS" and without warranty, support, indemnity, or any availability commitment, and are excluded from the SLA. They may be changed, suspended, or withdrawn at any time and may be less reliable than generally available features. The Customer's use of a Beta Feature is voluntary and at its own risk, and the Customer should not use a Beta Feature in a production-critical workflow without independent validation. Information about Beta Features is CentralCSP's Confidential Information.
### 2.7. Third-Party Services
The Service allows the Customer to connect Third-Party Services. Any such connection is made at the Customer's election and under its own agreement with the provider of that Third-Party Service. CentralCSP does not control, endorse, or assume responsibility for any Third-Party Service, its availability, its security, or its handling of data transmitted to it. Where the Customer directs the Service to transmit Customer Data to a Third-Party Service, Section 5.4 and Section 6.4 apply. CentralCSP may suspend or disable an integration where it poses a security risk or where the provider of the Third-Party Service ceases to make it available.
### 2.8. Suspension
CentralCSP may suspend the Customer's or an Authorized User's access to the Service, in whole or in part, with notice where practicable, if: (a) the Customer materially breaches Section 2.2 (Acceptable Use); (b) the use poses a security risk to the Service, to CentralCSP's systems, or to others; (c) the use is unlawful or exposes CentralCSP to liability; (d) an invoiced amount is overdue as described in Section 4.3; or (e) the Customer materially or repeatedly exceeds the Plan Limits and does not resolve the excess after notice under Section 4.1. CentralCSP will limit any suspension in scope and duration to what is reasonably necessary and will restore access promptly once the cause is resolved. A suspension under this Section does not relieve the Customer of its payment obligations.
### 2.9. Free tool output
The results, reports, and exports produced by the free tools described in Section 2.5, including the technologies, versions, version status, and publicly known vulnerabilities (CVEs) reported by the Technology & Vulnerability Checker, are provided for information only, "AS IS" and without warranty of any kind. They may be incomplete or inaccurate: they are inferred from publicly accessible resources, and a vendor may, for example, fix a vulnerability without changing the version number. A vulnerability listed for a website therefore does not establish that the website is exploitable.
### 2.10. Free tools acceptable use and opt-out
The Customer shall not use the output of a free tool to exploit, attack, or gain unauthorized access to any website or system, or to disparage a third party.
The owner of a website may ask CentralCSP to exclude its domain from analysis by the free tools through our [contact page](https://centralcsp.com/en/contact/). CentralCSP then refuses any further analysis of that domain by the free tools. More generally, CentralCSP may refuse to analyse, or stop analysing, any website at its discretion.
## 3\. Customer Obligations
### 3.1. Account security
The Customer is responsible for all activity under its account(s) and for keeping its passwords and credentials confidential and secure. The Customer shall notify CentralCSP promptly of any unauthorized use of its account or any known or suspected security breach.
### 3.2. Authorized Users
The Customer is responsible and liable for the acts and omissions of its Authorized Users. Any breach of this Agreement by an Authorized User is deemed a breach by the Customer.
### 3.3. Customer Data accuracy and legality
The Customer represents and warrants that it has obtained all rights, consents, and permissions required to provide and use the Customer Data with the Service, and that the Customer Data and its use will not violate any law or infringe any third-party rights.
### 3.4. Compliance with laws
The Customer shall use the Service in compliance with all applicable laws and regulations, including those relating to data privacy and the transmission of technical or personal data.
### 3.5. Sanctions and export control
The Customer represents and warrants that neither it, nor any of its Authorized Users, nor any party controlling or controlled by it, is subject to sanctions or listed on any restricted-party list maintained by the European Union, France, the United Nations, the United Kingdom, or the United States, and that it is not located in, or ordinarily resident in, a territory subject to comprehensive sanctions. The Customer shall not access, use, export, or re-export the Service in violation of any applicable export-control or sanctions law. CentralCSP may suspend or terminate the Service immediately if this Section is or becomes untrue.
## 4\. Fees, Payment, and Subscription
### 4.1. Plans, fees, and usage
The Customer shall pay all fees in the applicable Order Form or as stated on the CentralCSP website. Fees are determined by the plan purchased and its Plan Limits, and are not calculated on metered usage below those limits. Except as otherwise specified, payment obligations are non-cancelable and fees paid are non-refundable.
The Plan Limits are binding. CentralCSP may reject, discard, or decline to ingest browser reports submitted in excess of the applicable monthly limit, and may apply rate limits or other technical measures to enforce the Plan Limits, in each case without liability and without any reduction in fees. Where the Customer's requirements exceed its Plan Limits, CentralCSP will notify the Customer and may require an upgrade to a plan with sufficient capacity as a condition of continued ingestion. Nothing in this Section obliges CentralCSP to retain, process, or restore data that was not ingested.
### 4.2. Billing
Fees are invoiced in advance in accordance with the Order Form. The Customer is responsible for providing complete and accurate billing information. All fees are exclusive of taxes, which the Customer is responsible for paying. Payments are processed by our third-party payment processor; we do not store full card details.
### 4.3. Late payments
If an invoiced amount is overdue, without limiting our other remedies, it accrues interest at 1.5% of the outstanding balance per month, or the maximum permitted by law, whichever is lower, from the day following the due date and without any reminder being required.
Where the Customer is a professional, and in accordance with Articles L.441-10 and D.441-5 of the French _Code de commerce_, a fixed indemnity for recovery costs of forty euros (€40) is also due for each unpaid invoice, without prejudice to additional compensation on supporting evidence where recovery costs actually incurred exceed that amount.
CentralCSP may suspend access to the Service until payment is made, and may pursue recovery of unpaid fees by any available means, including the _procédure d'injonction de payer_ provided for by the French _Code de procédure civile_.
### 4.4. Auto-renewal
Unless otherwise specified in an Order Form, the subscription renews automatically for successive periods equal to the expiring term, unless either party gives written notice of non-renewal at least thirty (30) days before the end of the term. Renewal pricing is CentralCSP's then-current pricing unless otherwise agreed in writing.
## 5\. Intellectual Property and Data Rights
### 5.1. CentralCSP's intellectual property
CentralCSP and its licensors retain all right, title, and interest, including all Intellectual Property Rights, in the Service, the underlying technology, the Documentation, and any modifications or derivative works. This Agreement conveys no ownership in the Service. The CentralCSP name, logo, and product names are trademarks of CentralCSP or third parties; no right to use them is granted.
### 5.2. Customer's intellectual property
As between the parties, the Customer owns all right, title, and interest in the Customer Data, including the Customer's website content and the data generated by it (all types of reports collected and the various policies generated).
### 5.3. License to provide the Service
The Customer grants CentralCSP a worldwide, non-exclusive, royalty-free, limited-term license to host, copy, transmit, display, and otherwise use Customer Data as reasonably necessary to provide, maintain, and support the Service for the Customer.
### 5.4. License for service improvement; artificial intelligence
The Customer grants CentralCSP a perpetual, irrevocable, worldwide, royalty-free, non-exclusive license to use, copy, modify, and create derivative works of Customer Data in aggregated and de-identified (anonymized) form, for the purposes of improving the Service, developing new features, and conducting research and industry reporting (for example our periodic "State of the Web" report). CentralCSP exercises this license consistently with the DPA; in particular, where a browser report incidentally contains personal data, that data is never used for public research reporting, and any conflict between this Section and the DPA is resolved in favour of the DPA.
CentralCSP does not use Customer Data to train, fine-tune, or develop artificial intelligence or machine-learning models.
Where the Customer connects the Service to an AI assistant, agent, or other Third-Party Service, including through the API or the MCP integration, the Customer initiates and directs that transmission and is solely responsible for it. That transmission is not a disclosure by CentralCSP. The Customer is responsible for the terms on which the recipient processes the transmitted data, including whether it is used for model training, and for any transfer outside the European Economic Area that results.
### 5.5. Feedback
If the Customer or an Authorized User provides feedback, comments, or suggestions about the Service ("Feedback"), such Feedback is given voluntarily, and CentralCSP may use, disclose, and exploit it without obligation or restriction.
### 5.6. Publicity
The Customer grants CentralCSP the right to use and display the Customer's name and logo to identify the Customer as a customer of CentralCSP, on CentralCSP's website and in its marketing materials, presentations, and customer lists. CentralCSP will use the logo in accordance with any reasonable trademark usage guidelines the Customer provides, and this right does not otherwise transfer any ownership of the Customer's trademarks. The Customer may opt out at any time by written notice to the contact details in Section 12, after which CentralCSP will cease new use of the Customer's name and logo within a reasonable period.
## 6\. Confidentiality, Privacy, and Security
### 6.1. Confidentiality
The Receiving Party shall protect the Disclosing Party's Confidential Information with at least the same degree of care it uses for its own confidential information of like kind (and no less than reasonable care), shall not use it outside the scope of this Agreement, and shall not disclose it to any third party except as authorized in writing. The Receiving Party may disclose Confidential Information to its employees, contractors, and professional advisers who need it to perform this Agreement and who are bound by confidentiality obligations no less protective than this Section, and remains responsible for their compliance.
### 6.2. Exclusions
The obligations in Section 6.1 do not apply to information that the Receiving Party can demonstrate: (a) is or becomes publicly known through no act or omission of the Receiving Party; (b) was rightfully in the Receiving Party's possession without restriction before disclosure by the Disclosing Party; (c) is rightfully received from a third party without breach of any obligation of confidentiality; or (d) is independently developed by the Receiving Party without use of or reference to the Disclosing Party's Confidential Information.
### 6.3. Compelled disclosure
The Receiving Party may disclose Confidential Information to the extent required by law, regulation, or a valid order of a court or other governmental authority, provided that it (where legally permitted) gives the Disclosing Party prompt written notice so the Disclosing Party may seek a protective order or other remedy, discloses only the portion legally required, and uses reasonable efforts to obtain confidential treatment for the disclosed information.
### 6.4. Duration
The obligations in this Section 6 apply during the term of this Agreement and for five (5) years after its termination or expiration, except that they apply for as long as the information remains a trade secret under applicable law, and except in respect of Personal Data, which remains protected for as long as it is retained.
### 6.5. Privacy Policy
CentralCSP collects, uses, and discloses Personal Data in accordance with its [Privacy Policy](https://centralcsp.com/en/legal/privacy/), which is incorporated by reference and describes how we handle the information you provide when you use the Service.
### 6.6. Data Processing Agreement (DPA)
To the extent CentralCSP processes Personal Data contained in Customer Data on the Customer's behalf, and such processing is subject to data protection laws such as the GDPR, the parties are bound by the CentralCSP [Data Processing Agreement](https://centralcsp.com/en/legal/dpa/), which is incorporated by reference. The DPA sets out the roles and obligations of the parties as required by regulations such as the GDPR and covers the following details of processing:
| Processing detail | Description |
| --- | --- |
| Subject-matter of the processing | Collection and analysis of browser-generated security telemetry and website security data to monitor and enhance the security of the Customer's web properties. |
| Duration of the processing | For the term of the Customer's subscription, and as specified in the data retention section of the DPA (a rolling 90-day maximum for browser reports; scan results contain no personal data and are kept indefinitely or aggregated into statistics). |
| Nature and purpose of the processing | To provide the Services, including collecting and analysing all supported browser Reporting-API report types, generating event-based alerts, maintaining a script inventory and detecting vulnerabilities (CVEs), producing PCI DSS evidence, scanning and evaluating website security, and generating recommended CSP policies. To use aggregated, anonymized data for service improvement. |
| Type of Personal Data processed | Account data: name, email, company, password (hashed). Report data: IP addresses, user-agent strings, URLs, and other technical data incidentally contained in browser reports. Scan results describe a website's publicly accessible configuration and contain no personal data. No special categories of data and no cardholder data. |
| Categories of Data Subjects | The Customer's Authorized Users, and End-Users of the Customer's websites whose browsers submit reports. |
| Obligations and rights of the Controller | The Customer's obligations and rights as data controller are set out in this Agreement and the DPA. |
### 6.7. Security measures and data residency
CentralCSP maintains appropriate administrative, technical, and physical safeguards designed to protect the security, confidentiality, and integrity of Customer Data against unauthorized access, use, modification, or disclosure. These are based on industry standards and include data encryption, access controls, and secure development practices, as further described in the DPA.
CentralCSP hosts and stores all Customer Data within the European Union. This commitment covers the data CentralCSP holds and processes on its own infrastructure and that of its sub-processors, as listed in the DPA.
It does not cover destinations the Customer chooses. Where the Customer configures the Service to transmit Customer Data to a Third-Party Service (including an alert delivery channel such as Slack, Microsoft Teams, PagerDuty, an email address, or a webhook endpoint, or an AI assistant connected through the API or MCP integration), the Customer directs that transmission as controller and is solely responsible for it, including for any resulting transfer outside the European Economic Area and for putting in place any transfer mechanism such transfer requires.
## 7\. Warranties and Disclaimers
### 7.1. Mutual warranties
Each party represents and warrants that it has the legal power and authority to enter into this Agreement.
### 7.2. CentralCSP's service commitment
CentralCSP warrants that, during the subscription term, it will provide the Service with reasonable care and skill, in substantial conformity with the Documentation, and using personnel with the requisite skill and experience. If the Service materially fails to conform to this warranty, the Customer's remedy, and CentralCSP's obligation, is for CentralCSP to use commercially reasonable efforts to correct the non-conformity; if it cannot do so within a reasonable period after written notice, the Customer may terminate the affected subscription and receive a refund of prepaid fees covering the remainder of the term. This Section does not limit any remedy available to the Customer under Section 8.3.
### 7.3. Disclaimer of warranties
Except as expressly provided in Section 7.2 and in any applicable SLA, the Service(s) and all related components and information are provided on an "AS IS" and "AS AVAILABLE" basis. CentralCSP disclaims all other warranties, whether express, implied, statutory, or otherwise, including implied warranties of merchantability, fitness for a particular purpose, title, and non-infringement, to the fullest extent permitted by applicable law.
Except as expressly set out in the SLA, CentralCSP does not warrant that the Service will be uninterrupted, timely, or error-free, or that all defects will be corrected. CentralCSP makes no guarantee regarding the results obtained from the Service, the accuracy of any security or compliance score, or the effectiveness of any generated Content Security Policy. The Customer acknowledges that no security tool provides absolute protection, and CentralCSP does not guarantee that use of the Service will prevent all security vulnerabilities (such as cross-site scripting, click-jacking, or data injection) or that generated policies will be optimal or compliant in all circumstances. The Service is a tool to aid security efforts, not a guarantee of security.
Nothing in this Section 7 excludes or limits any warranty or liability that cannot be excluded or limited under applicable law.
## 8\. Limitation of Liability
### 8.1. Cap on direct damages
Subject to Section 8.3, in no event shall either party's total aggregate liability arising out of or related to this Agreement exceed the total amount paid or payable by the Customer to CentralCSP in the twelve (12) months preceding the event giving rise to the claim. This limitation applies whether the claim is in contract or tort and regardless of the theory of liability.
### 8.2. Exclusion of indirect damages
Subject to Section 8.3, under no legal theory shall either party be liable for any indirect, special, incidental, exemplary, punitive, or consequential damages, including lost profits, losses, or expenses, whether or not the party was advised of the possibility of such damage.
### 8.3. Exclusions from the cap
The limitations in Sections 8.1 and 8.2 do not apply to:
- the Customer's obligation to pay fees due under Section 4, including interest and recovery costs;
- a party's willful and unauthorized disclosure or use of the other party's Confidential Information, made in knowing breach of Section 6. For the avoidance of doubt, liability arising from a security incident or Personal Data Breach affecting Customer Data, or from any other non-intentional breach of Section 6, remains subject to Sections 8.1 and 8.2, except where it results from fraud, _dol_, or _faute lourde_;
- the Customer's breach of Section 2.1 (License grant), Section 2.2 (Acceptable Use), or Section 3.5 (Sanctions and export control);
- fraud, _dol_ (willful misconduct), or _faute lourde_ (gross negligence); or
- death or personal injury caused by a party's negligence, and any other liability that cannot lawfully be excluded or limited.
## 9\. Indemnification
### 9.1. By the Customer
The Customer shall defend, indemnify, and hold CentralCSP and its affiliates, officers, directors, agents, partners, and employees harmless from any third-party claim or demand, and any resulting damages, losses, and reasonable attorneys' fees finally awarded or agreed in settlement, arising out of (a) the Customer Data, (b) the Customer's use of the Service in breach of this Agreement, (c) the Customer's scanning or analysis of a website or digital property without the authorization required by Section 2.2, or (d) the Customer's misuse of the results or output of the free tools, including any use in breach of Section 2.10.
### 9.2. No indemnity by CentralCSP
CentralCSP gives no indemnity under this Agreement. Except where an indemnity is required by mandatory applicable law, CentralCSP has no obligation to defend, indemnify, or hold the Customer harmless against any third-party claim, including a claim that the Service infringes a third party's Intellectual Property Rights.
If the Service becomes, or in CentralCSP's opinion is likely to become, the subject of a third-party claim alleging infringement of Intellectual Property Rights, CentralCSP may at its option procure the right to continue using the Service, replace or modify it so it is non-infringing, or terminate the affected subscription and refund prepaid fees covering the remainder of the term.
### 9.3. Procedure
The indemnified party shall promptly notify the indemnifying party of the claim, give the indemnifying party sole control of the defence and settlement (provided that no settlement imposing a non-indemnified obligation on the indemnified party may be made without its consent, not unreasonably withheld), and provide reasonable cooperation at the indemnifying party's expense. A delay in notice relieves the indemnifying party only to the extent it is prejudiced by the delay.
### 9.4. Sole remedy
Sections 9.1 to 9.3 state the Customer's sole liability and CentralCSP's exclusive remedy for the claims they cover. The Customer's liability under this Section is subject to the limitations in Section 8. The obligations in this Section survive termination of this Agreement.
## 10\. Term and Termination
### 10.1. Term
This Agreement begins on the date the Customer first accepts it and continues for the initial subscription term in the applicable Order Form. The term renews automatically as described in Section 4.4.
### 10.2. Termination for cause
Either party may terminate this Agreement for cause if the other materially breaches it and fails to cure the breach within thirty (30) days of written notice. If the Customer terminates for cause under this Section, CentralCSP will refund any prepaid fees covering the remainder of the subscription term following the effective date of termination.
### 10.3. Termination for convenience
The Customer may terminate its subscription at any time using the cancellation procedures within the Service. Such termination takes effect at the end of the then-current billing period, and the Customer is not entitled to a refund of prepaid fees, except as provided in Section 2.3.
### 10.4. Effect of termination and data export
On termination or expiration, all rights granted to the Customer immediately cease.
For thirty (30) days following the effective date of termination or expiration, CentralCSP will make Customer Data available for export by the Customer through the Service or, on written request, provide it in a structured, commonly used, machine-readable format. This export window does not apply where the Customer's access is terminated for breach of Section 2.2 or Section 3.5, in which case CentralCSP will provide the data on written request only.
After the export window closes, CentralCSP has no obligation to maintain Customer Data and will delete it in accordance with Section 8 of the DPA and applicable law, including the storage-limitation principle under the GDPR. Scan results are excepted: they are designed to describe a website's publicly accessible configuration and are retained as described in Section 8 of the DPA; where a scan result incidentally contains personal data, CentralCSP deletes or redacts it on written request.
### 10.5. Survival
The following survive termination or expiration: Section 1 (Definitions), Section 4 (Fees) for fees owed, Section 5 (Intellectual Property and Data Rights), Section 6 (Confidentiality, Privacy, and Security) subject to the duration in Section 6.4, Section 7.3 (Disclaimer of Warranties), Section 8 (Limitation of Liability), Section 9 (Indemnification), Section 10.4 (Effect of Termination and Data Export), Section 10.5 (Survival), and Section 11 (General Provisions).
## 11\. General Provisions
### 11.1. Governing law
This Agreement is governed by and construed in accordance with the laws of France, without regard to its conflict-of-laws rules and excluding the United Nations Convention on Contracts for the International Sale of Goods.
### 11.2. Dispute resolution and jurisdiction
The parties shall first attempt to resolve any dispute through good-faith negotiation, initiated by written notice describing the dispute, for a period of thirty (30) days.
If the dispute is not resolved within that period, it shall be submitted to the **exclusive jurisdiction of the Tribunal de commerce de Grenoble (France)**, including in the case of multiple defendants, an emergency application, a protective measure, or a third-party claim. Where the Customer is a professional that is not a _commerçant_ and the Tribunal de commerce cannot hear the claim, the competent courts of Grenoble (France) have exclusive jurisdiction instead.
Nothing in this Section prevents either party from applying to any competent court for interim or injunctive relief, or prevents CentralCSP from pursuing recovery of unpaid fees through the _procédure d'injonction de payer_ or any other summary procedure available under French law.
### 11.3. Notices
Legal notices must be in writing and are deemed given on (i) personal delivery; (ii) the second business day after mailing within France, or the fifth business day after international mailing; or (iii) the first business day after sending by email. Notices to CentralCSP are sent to the address in Section 12; notices to the Customer are sent to the email associated with its account.
### 11.4. Assignment
Neither party may assign its rights or obligations without the other's prior written consent, except that either party may assign this Agreement in its entirety in connection with a merger, acquisition, reorganization, or sale of all or substantially all of its assets.
### 11.5. Force majeure
Neither party is liable for any failure or delay in performance (other than payment obligations) caused by events beyond its reasonable control and occurring without its fault or negligence. If such an event continues for more than sixty (60) days, either party may terminate the affected subscription by written notice, and CentralCSP will refund, on a pro-rata basis, any prepaid fees covering the period after termination.
### 11.6. Entire agreement and order of precedence
This Agreement, including the Privacy Policy, the DPA, the SLA, and all Order Forms, is the entire agreement between the parties and supersedes all prior agreements concerning its subject matter. In the event of any conflict among these documents, the order of precedence is: (1) the applicable Order Form, (2) the Data Processing Agreement, which prevails on matters of data protection only, (3) the SLA, which prevails on matters of service availability only, and (4) these Terms of Service.
### 11.7. Modifications to these Terms
CentralCSP may modify these Terms. For material changes we will give the Customer at least thirty (30) (calendar) days' notice before the change takes effect, through the Service's interface, by email to the address associated with the account, or by other reasonable means, and will update the "Last updated" date on this page.
If the Customer does not accept a material change, it may terminate its subscription without penalty by written notice given before the change takes effect, and CentralCSP will refund, on a pro-rata basis, any prepaid fees covering the period after termination. Continued use of the Service after the effective date of a change constitutes acceptance of the modified Terms.
### 11.8. Severability
If any provision of this Agreement is held to be invalid, unlawful, unenforceable, or _réputée non écrite_ by a court or other competent authority, that provision shall be modified to the minimum extent necessary to make it valid and enforceable while preserving the parties' original intent, or, if that is not possible, severed. In either case the remaining provisions of this Agreement remain in full force and effect.
### 11.9. No waiver
No failure or delay by either party in exercising any right or remedy under this Agreement operates as a waiver of it, and no single or partial exercise of any right or remedy prevents any further exercise of it or of any other right or remedy. A waiver is effective only if given in writing and is limited to the specific instance and purpose for which it is given.
### 11.10. Independent contractors
The parties are independent contractors. Nothing in this Agreement creates a partnership, joint venture, agency, franchise, employment, or fiduciary relationship between them, and neither party has authority to bind the other or to incur any obligation on the other's behalf.
### 11.11. Language
These Terms are drafted in English, which is the authoritative and legally binding version. Any translation (for example the French version) is provided for convenience only. In the event of any conflict, ambiguity, or divergence between the English version and a translated version, the English version prevails and governs.
## 12\. Contact Information
For questions about these Terms or for legal notices, contact us at:
- Company: CentralSaaS, _société par actions simplifiée_ (SAS), operating the CentralCSP service
- Registered office: 1 Allée des Frênes, 38240 Meylan, France
- RCS: Grenoble **927 890 756**
- Contact: [contact@centralcsp.com](mailto:contact@centralcsp.com)
Full statutory information (share capital, SIRET, VAT number, hosting) is available on our [Legal Notice](https://centralcsp.com/en/legal/mentions-legales/) page.
---
Available in: [en](https://centralcsp.com/en/legal/terms/), [fr](https://centralcsp.com/fr/legal/terms/)
```yaml
title: "CSP violation & script change alerts in Slack, Teams"
description: "CSP and script-change alerts in Slack, Teams, Telegram, email or a signed webhook, the moment a report lands. Detection and alerting for PCI DSS 11.6.1."
url: "https://centralcsp.com/en/platform/alerting/"
lang: "en"
```
Alerts
# Your site changed. Your team already knows.
Add a rule once. When a real visitor's browser reports the change, the message is already in the channel that owns that page.
[Start free trial](https://app.centralcsp.com) [See what we monitor](https://centralcsp.com/en/platform/monitoring/)
- Fires on ingest
Not a nightly sweep
- Six destinations
Chat, email or webhook
- Routed per site
And per team
- No agent
One response header
[Set up your first alert rule](https://centralcsp.com/en/docs/platform/features/alerting/get-started) takes about ten minutes.
Triggers
## What's worth interrupting someone for.
An alert rule is an event a browser reported, a page scope, one or more channels and a cooldown. New origin, script change detected by hash, payment-page tamper detection: the source is always the browser's own report, never a crawler or an injected agent.
- ### A new origin appears
A script loaded from a host you have never seen. Magecart and formjacking skimmers open exactly here: a new host, then a card form quietly reporting to it.
- ### A script changed
A file you execute no longer matches yesterday's hash. Your build did it, or somebody else did.
- ### Something touched a payment page
Card-data pages get their own rules, because [PCI DSS 11.6.1 asks you to alert on changes to them](https://centralcsp.com/en/platform/pci-dss/).
- ### A known CVE turns up
A library you load has a published advisory. You hear it with the version and the CVE id. [See how the script inventory finds them](https://centralcsp.com/en/platform/supply-chain/).
- ### Reports spike
Violations jumped after the 4pm deploy. Something broke at scale, and the browsers said so first.
- ### A silent signal wakes up
A directive that reported nothing all quarter started talking. Worth a look before it is worth an incident.
These six are the ones worth interrupting someone for. The full event catalogue is larger: [every event a rule can watch, with scope and cooldown](https://centralcsp.com/en/docs/platform/features/alerting/rules).
Channels
## This is what an alert looks like.
The same rule, reaching three teams where they already work. Every rule picks its own destination, so a checkout incident and a marketing-site warning never land in the same thread.
-
-
-
Every destination a rule can reach
- Slack
- Microsoft Teams
- Google Chat
- Telegram
- Email
- Webhooks
Setup
## Configured once, then it runs without you
Channels, rules and delivery history live on one screen. Connect a destination, point rules at it, then check afterwards what actually went out.
### Every rule reaches the team that owns the page
Add a channel, Slack, Teams, Google Chat, Telegram, email or a webhook, then choose which events reach it. A new origin on checkout goes to the payments team, a broken directive on the blog goes to whoever ships the blog.
[Start free trial](https://app.centralcsp.com)
### One message, not four hundred
Reports arrive deduped and grouped, and every rule takes a cooldown, so a bad deploy interrupts someone once.
### Delivery history per channel
Every attempt is recorded with its status and the reason it failed, and transient failures are retried. No guessing whether a message went out.
### API and MCP
Rules are a REST resource, and the same operations run over the built-in MCP server. Onboarding a hundred sites is a loop.
Further reading
## Set up your first rule
Every event a rule can watch, every channel it can reach, and what happens when a delivery fails.
- [Set up your first alert rule](https://centralcsp.com/en/docs/platform/features/alerting/get-started)
- [Events, scope and cooldowns](https://centralcsp.com/en/docs/platform/features/alerting/rules)
- [Every alert channel and the URL it needs](https://centralcsp.com/en/docs/platform/features/alerting/channels)
- [Verify a signed webhook](https://centralcsp.com/en/docs/platform/features/alerting/channels/webhook)
- [Delivery history and retry behaviour](https://centralcsp.com/en/docs/platform/features/alerting/deliveries)
- [How to detect a Magecart skimmer client-side](https://centralcsp.com/en/blog/magecart-formjacking-detection)
FAQ
## Frequently asked questions
Channels, speed, noise and compliance, answered.
### Can I get CSP violation alerts in Slack?
Yes, and in Microsoft Teams, Google Chat, Telegram, email or any webhook you host. Connect the channel once, then point rules at it. A rule can post to more than one channel, and two rules on the same site can reach different teams.
### Why alert instead of just blocking the script?
Magecart and formjacking skimmers are the reason. Blocking is the Content Security Policy's job, and you should have one. What a policy cannot do is tell a good change from a bad one inside a vendor you already approved, which is how British Airways was breached. The policy closes the doors; alerts tell you when something moved in a room you already let someone into.
### How fast does an alert arrive?
Rules are evaluated as reports arrive, and browsers send reports shortly after a page loads. In practice you hear about a new script on the next page view that loads it, not on a nightly sweep. For comparison, Cloudflare Page Shield batches its new-resource alerts daily and its code-change alerts up to every 24 hours.
### Won't I drown in CSP noise?
That is the usual failure mode, and it comes from alerting on raw reports. Yours arrive deduped, grouped by directive and origin, and with browser-extension false positives already flagged. You can also scope any rule to the pages that matter, so the checkout and the blog never share the same rule. On top of all that, every rule takes a cooldown: tell it how long to stay quiet after it fires and a bad deploy produces one message, not four hundred.
### What happens if Slack or my webhook is down?
The delivery is retried, and every attempt is recorded in the delivery history with its channel, its status and the reason it failed. Transient failures, such as a timeout or a 5xx from your endpoint, are retried. Permanent ones are not: a webhook URL that has been revoked, a Slack channel that no longer exists, or a 4xx that says the request itself is wrong will not succeed on a second attempt, so the history shows it as failed rather than retrying forever. You read the outcome per rule, per channel, rather than guessing whether a message was ever sent.
### Does this satisfy PCI DSS 11.6.1?
It is the detection and alerting half of it. Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of payment pages and their HTTP headers, as received by the consumer browser, at least once every seven days. CentralCSP's reports come from the consumer browser and its rules fire on arrival. Pair it with the script inventory for 6.4.3 and export both as evidence.
### Do I need an agent or a script on the page?
No. Alerting rides the same response header as monitoring. Browsers generate the reports themselves, so there is nothing to install, nothing to keep updated, and no third-party script added to the pages you are trying to protect.
### Do alerts work while my CSP is still in Report-Only?
Yes, and that is usually where you want them. Rules run on the reports a browser sends, not on the blocks it performs, and Content-Security-Policy-Report-Only sends exactly the same violation reports while blocking nothing. So you can watch for a new origin or a changed script through the whole report-only rollout, before you enforce anything.
### Can I create alert rules over the API?
Yes. Rules are a REST resource, and the same operations are available over the built-in MCP server, so onboarding a hundred sites is a loop rather than an afternoon. An API key acts as the person who created it, with that person's roles, and revoking it cuts the integration off immediately.
## Set one rule today. Forget about it until it matters.
Add the header, connect a channel, pick the change worth a message. 14-day free trial, no agent to deploy.
[Start free trial](https://app.centralcsp.com) [Check your reporting setup](https://centralcsp.com/en/tools/reporting-api/)
---
Available in: [en](https://centralcsp.com/en/platform/alerting/), [fr](https://centralcsp.com/fr/platform/alerting/)
```yaml
title: "CSP API and MCP server for AI agents and CI/CD"
description: "Read CSP violations, script inventories and metrics over a REST API, gate deploys from CI, or connect Claude Code and Cursor to the built-in MCP server."
url: "https://centralcsp.com/en/platform/api-mcp/"
lang: "en"
```
API and MCP
# Anything you can click, your agent can too.
Connect the built-in MCP server and ask in plain language: your agent scans a site, reads the reports and comes back with what to fix first. The same coverage is a REST API when you would rather script it, authenticated with a workspace API key that carries your own roles.
[Set up the MCP server](https://centralcsp.com/en/docs/api-mcp/mcp/quickstart) [Read the API docs](https://centralcsp.com/en/docs/api-mcp/api)
claude — shop.example.com
\> Scan shop.example.com and tell me what to fix first.
Running a scan and pulling the last 30 days of reports.
centralcsp - scans\_create (MCP) (url: "shop.example.com")
queued · sc\_8f2a19c4
centralcsp - reports\_summary (MCP) (range: "30d")
1,087,621 reports · 2,710 blocked · 10 pages
centralcsp - compliance\_scripts (MCP) (cve: true)
4 scripts with known CVEs
Three things, in this order:
1. 1.
Critical Unknown script on /checkout
cdn.pixel-metrics.io/t.js first appeared 14:02 yesterday and is not in your policy.
2. 2.
High script-src still allows 'unsafe-inline'
Nonces are already on 94% of your inline scripts. Drop the keyword and the policy holds.
3. 3.
Medium jQuery 3.4.1 carries CVE-2020-11023
Loaded on 3 pages. Patched in 3.5.0.
\>
Ask a follow-up
3 MCP tools · centralcsp connected
Coverage
## Every CSP report, script and alert over one REST API.
The dashboard is just another API client. Every workspace resource has endpoints to read it and manage it, so if a number is on a screen, there is a call that returns it.
- `GET /workspaces/:id/websites`
Sites
List, create and configure monitored sites. Each returns its managed reporting endpoint, ready for the header.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
- `GET …/websites/:id/reports/:type/raw`
Reports
Raw and aggregated browser reports, filterable by type, directive, origin and time range.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
- `GET …/websites/:id/compliance/scripts`
Scripts and SBOM
The script inventory with integrity hashes, library versions and known CVEs.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
- `GET …/websites/:id/stats/metrics/:id`
Metrics and charts
The same metrics and chart series the dashboard renders, per site or across the workspace, for your own reporting.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
- `POST …/websites/:id/alerts/rules`
Alerting
Create alert rules and route them to Slack, Teams or any webhook.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
- `GET /workspaces/:id/members`
Members and audit
Invite members, assign roles and read the workspace audit log.
[View endpoints](https://centralcsp.com/en/docs/api-mcp/api)
MCP server
## Put the API in your agent's hands.
The CentralCSP MCP server exposes your websites, reports, scans, alert rules and the CSP builder as tools any agent can call. Connecting is one server URL and an OAuth sign-in, with no secret to store.
- Works with Claude Code, Claude Desktop, Codex CLI and any MCP client
- Same coverage as the REST API
- The server holds no credential: it signs you in over OAuth and acts as you
- Flip the workspace AI integration kill switch and it is cut off
[Set up the MCP server](https://centralcsp.com/en/docs/api-mcp/mcp/quickstart)
Agent permissions
## What an agent can and cannot do
The server acts as you. It never gains a permission you do not already have, and the workspace kill switch cuts every AI integration at once.
What the MCP server can read, can change, and can never do
| Scope | What that means |
| --- | --- |
| Can read | Your websites, their reports and scores, script inventories, scan results and alert rules, for the sites your roles already reach |
| Can change | What your roles let you change: start a scan, create or edit an alert rule, add a website |
| Can never | Reach a workspace or a site you have no role on, act after the key is revoked, or survive the workspace AI integration kill switch |
## What teams script first.
No SDK required. Three calls with curl and a cron get you further than most integrations.
### Gate your deploys from CI/CD
Your CI/CD job starts a scan on the release URL, polls until it finishes, and reads the score back. Compare it to the previous run and exit non-zero when a release would weaken the policy or drop a security header, so the build fails before the deploy lands.
### Feed your SIEM or data warehouse
Pull CSP violations, script hashes and network errors, plus scores and inventories, into your SIEM, your data warehouse or a weekly client report.
### Onboard sites in a pipeline
Create the site, read back its reporting endpoint and ship the header in the same run.
Further reading
## Start with the reference
Connect an agent, create a key, and read the endpoint reference.
- [MCP quickstart for Claude Code and Codex](https://centralcsp.com/en/docs/api-mcp/mcp/quickstart)
- [REST API reference](https://centralcsp.com/en/docs/api-mcp/api)
- [Connect Claude Code, Claude Desktop or Codex](https://centralcsp.com/en/docs/api-mcp/mcp/connect)
- [What an agent can and cannot do](https://centralcsp.com/en/docs/api-mcp/mcp/permissions)
- [Create a workspace API key](https://centralcsp.com/en/docs/platform/integrations/api-keys)
- [AI integration kill switch and API key restrictions](https://centralcsp.com/en/docs/platform/security/platform-security)
FAQ
## Frequently asked questions
MCP, tokens and plans, answered.
### What is an MCP server?
A standard interface AI agents use to discover and call a product's capabilities. Point any MCP client at the CentralCSP server and it lists the available tools itself: no API glue code, no custom plugin.
### Does the MCP server replace the API?
No. It sits on top of the same API with the same permissions. Agents and assistants talk MCP; your scripts, CI jobs and integrations call REST directly.
### MCP server or REST API: which should I use?
Use the REST API when something deterministic calls it: a script, a CI job, a nightly sync into your warehouse, an integration you maintain. Use MCP when a person is asking a question and an agent decides which calls to make: the same capability, exposed as tools the agent discovers by itself, under the same permissions. They are two front doors to one set of operations, not two products, so nothing is available over one and missing from the other.
### How do I authenticate to the API?
With a workspace API key, sent as a bearer token in the Authorization header. You create the key in the workspace, and it acts as the person who created it: the same website roles, the same plan limits. That also means a key cannot be edited after creation to widen what it reaches, so changing access means creating a new key and revoking the old one. Revocation takes effect immediately.
### Is it safe to connect an AI agent to my security data?
The server is first-party and it holds no credential of its own. It signs you in over OAuth and then acts as you: the same website roles you already have, and the same workspace plan. It cannot reach a site you cannot reach. If you want it gone, revoke the API key or flip the workspace AI integration kill switch, and access stops immediately.
### Which plan includes the API and MCP?
Business and up. Start covers collection and the dashboard; the API and MCP server come in with the automation tier.
### Which AI tools can use it?
Any MCP client. The ones we document and test are Claude Code, Claude Desktop and Codex CLI; Cursor, VS Code, Windsurf and the rest of the growing agent ecosystem speak the same protocol and connect the same way, with one server URL and an OAuth sign-in.
## Collect the signal. Script the rest.
Start free, add the header, and automate from day one. API and MCP are included from the Business plan.
[Start free trial](https://app.centralcsp.com) [Read the API docs](https://centralcsp.com/en/docs/api-mcp/api)
---
Available in: [en](https://centralcsp.com/en/platform/api-mcp/), [fr](https://centralcsp.com/fr/platform/api-mcp/)
```yaml
title: "CSP generator from real traffic, plus Permissions-Policy"
description: "Build a strict CSP from real browser reports, not a crawl, then Permissions-Policy and Connection-Allowlist the same way. Report-only first, enforce when clean."
url: "https://centralcsp.com/en/platform/csp-builder/"
lang: "en"
```
Policy builders
# Strict CSP and policy headers, built from real traffic.
A strict Content Security Policy is your best defense against cross-site scripting, and the hardest header to write by hand. CentralCSP builds it from what real browsers report, not from a crawler's snapshot of your homepage, and the same reports build your Permissions-Policy and Connection-Allowlist.
[Start free trial](https://app.centralcsp.com) [Scan your current policy](https://centralcsp.com/en/tools/csp-scanner/)
- From real traffic
Not a crawler snapshot
- Report-only first
Enforce when it's clean
- Value by value
Every source explained
- Dashboard, API or MCP
Same builder, same answer
Three builders
## One set of reports, three policy headers.
Each builder reads the reports its header sends and proposes the strictest value your real traffic allows. Every plan includes all three.
### Content-Security-Policy
Controls which scripts, styles, frames and connections your pages may load. The strongest defense you have against cross-site scripting and injected scripts.
- Built from CSP violation reports
- Detects the policy you already serve
- Nonces and 'strict-dynamic' handled
[Build a strict CSP](#csp)
### Permissions-Policy
Switches off the browser features your pages never use, like the camera, microphone, geolocation or the payment sheet, for your pages and every frame you embed.
- Built from violation and potential-violation reports
- 25 features, denied by default
- Frames granted by origin
[Build a Permissions-Policy](#more-policies)
### Connection-Allowlist
Limits where your pages can send data. Every destination not on the list is blocked, so an injected script has nowhere to send what it steals.
- Built from Connection-Allowlist reports
- WebSocket and WebRTC covered
- Redirects blocked unless you allow them
[Build a Connection-Allowlist](#more-policies)
How the builders work
## From real reports to a policy you can enforce.
A policy builder turns the violation reports browsers already send into a header. Instead of loading one page in a headless browser, the CSP generator, like the other two builders, reads what every visitor's browser reported across every page they opened, then proposes the policy value by value. Same four steps for all three.
1. 01 - Period
### Pick a period
Pick up to 30 days of the reports your visitors' browsers send, with a preset or by dragging across the chart.
2. 02 - Start
### Choose a start
Start from our secure baseline, a policy detected in your reports, a preset, or a header you paste in.
3. 03 - Review
### Review each value
One row per value, with its reports. Noise starts rejected: add or reject the rest, or let Auto decide.
4. 04 - Deploy
### Copy and ship it
Copy both headers or export them as a text file. Run report-only for a week, then enforce the same policy.
CSP builder
## A strict Content Security Policy, value by value.
The CSP builder is the deepest of the three: it detects the policy you serve, filters extension noise and knows how nonces change a policy.
### Start from the policy you already serve.
If your site already reports to CentralCSP, the builder reads the policies inside those reports and tells you which one is live, which covers only part of the site and which was replaced. Start from yours and it gains the protections the baseline adds, without losing anything it allows. No CSP yet? Start from the CentralCSP baseline: default-src 'self', object-src 'none', frame-ancestors 'none' and nothing third-party allowed.
- Live, partial and old policies detected
- Nonce-based policies recognized
- A secure baseline when you have none
### You decide every value before it ships.
Every value the builder proposes carries its evidence: how many reports it drew, its share of the directive, the days it was active, and the browsers, pages and code that reported it. A real dependency is obvious. Browser-extension sources, known injectors such as adware and coupon tools, and one-off bursts from a single browser are flagged as noise and start rejected, so they never land in your allowlist. Add what's real, reject the rest, or let Auto decide.
- The evidence behind every value
- Extension and injector noise starts rejected
- Add or reject, value by value
[How the CSP builder decides each value](https://centralcsp.com/en/docs/platform/features/builders/csp/how-it-decides)
### Safe to copy today, stricter every release.
A policy that breaks checkout never ships, so everything your pages rely on today starts added, even a value that weakens the policy. None of it slips through quietly: each weak value carries a risk flag from our CSP evaluator and the steps to remove it, like moving an inline script into a file or giving it a nonce. Where your policy uses nonces, the builder adds 'strict-dynamic' and rejects 'unsafe-inline' for you. And before you deploy, the evaluator grades the finished policy.
- Risky values flagged, with the fix
- Nonces and 'strict-dynamic' handled for you
- Evaluator findings before you deploy
[Nonces and unsafe-inline in the CSP builder](https://centralcsp.com/en/docs/platform/features/builders/csp/nonces-and-unsafe-inline)
Beyond CSP
## Two more policy headers, built the same way.
Permissions-Policy and Connection-Allowlist come from the same reports, the same four steps and the same review table. Few sites send either, because nobody wants to write them by hand.
### Permissions-Policy: deny every feature your pages never use.
Browsers never report the Permissions-Policy a page was served with, so you start from a preset or paste yours. The builder then reads the violations from your own pages and the potential ones from iframes asking for a feature. What your pages used is granted to your own origin, what a frame asked for goes to that frame's origin, and a feature only a third-party script reached for stays denied: granting it would hand the camera or the payment sheet to that script.
- 25 features, denied by default
- Frames granted by origin, with the allow attribute they need
- Third-party script requests stay denied
[Get started with the Permissions-Policy builder](https://centralcsp.com/en/docs/platform/features/builders/permissions-policy/get-started)
### Connection-Allowlist: an egress allowlist from the connections your pages make.
Start from your own origin and add only the destinations real browsers were blocked from reaching. Once three or more subdomains of one site are kept, they fold into a single pattern. WebSocket and WebRTC connections get their own groups, and redirects stay blocked unless a sign-in or payment step bounces through another site. Only Chromium-based browsers enforce it today, so keep CSP connect-src alongside it.
- Starts from your own origin, never from a reported list
- One pattern for three or more subdomains
- WebSocket, WebRTC and redirects decided apart
[Get started with the Connection-Allowlist builder](https://centralcsp.com/en/docs/platform/features/builders/connection-allowlist/get-started)
Approaches
## Three ways to get a Content Security Policy.
A CSP is only as good as its coverage. Here is the honest comparison between writing one by hand, scanning a page for one, and building it from the traffic you already have.
Comparison of ways to produce a Content Security Policy
| | CentralCSP | Crawler / scanner | By hand |
| --- | --- | --- | --- |
| Covers pages behind a login | Every visited page | Homepage only | If you remember it |
| Sees conditional third parties | Real sessions catch them | Missed if not triggered | Only what you know |
| Filters browser-extension noise | Flagged and rejected | Not distinguished | You guess |
| Stays current as the site changes | Rebuild from fresh reports | A one-time snapshot | Manual rewrite |
| Reaches enforcement safely | Report-only, then enforce | Starter policy only | Days of testing |
| Builds Permissions-Policy and Connection-Allowlist too | From the same reports | CSP only | Two more headers to write |
There is a fourth way: inject a report-only policy locally with a browser extension and build from what that one browser sees. It is genuinely good for authoring and debugging a single page, and [our Chrome extension does exactly that, free](https://centralcsp.com/en/tools/extension/). Whole-site coverage still needs real traffic, because one browser on one page is not your site.
API and MCP
## Every builder is one API call away.
The dashboard, the REST API and the MCP server run the same builders, so they give the same answer. Ask for a recommended policy over a period, optionally starting from yours, and get the header back. Nothing is saved.
- One REST endpoint per header
- Three MCP tools for AI agents
- On the Business and Scale plans
[See the API and MCP platform](https://centralcsp.com/en/platform/api-mcp/)
Alerting
## A new source shows up? You hear about it.
The same reports that build your policy can page you. When a script loads from an origin your policy never allowed, CentralCSP posts it to Slack, Teams, Google Chat, Telegram or email before the next visitor loads the page.
- New-origin and hash-change rules
- Violation spikes after a deploy
- Routed to the channel that owns the page
[See alerting](https://centralcsp.com/en/platform/alerting/)
Check your headers
## What does your site send today?
Two minutes, no account: scan your live headers and see whether you have a Content Security Policy at all, how strict it is, and which origins can run code on your pages right now.
Scan my site
Free, no account needed. Results land on a shareable page. [Check which policy headers you send today](https://centralcsp.com/en/tools/security-headers/).
Further reading
## How a policy gets built, in detail
The builder itself, report-only, the three headers, and shipping the finished policy on whatever stack you run.
- [Get started with the CSP builder](https://centralcsp.com/en/docs/platform/features/builders/csp/get-started)
- [The Content-Security-Policy-Report-Only header](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/report-only)
- [Why unsafe-inline defeats your CSP](https://centralcsp.com/en/blog/unsafe-inline-csp)
- [The Permissions-Policy header, feature by feature](https://centralcsp.com/en/docs/web-security/policies/permissions-policy)
- [Connection Allowlists, an egress sandbox in the browser](https://centralcsp.com/en/blog/connection-allowlists-network-egress)
- [Set the CSP header in nginx, Next.js and more](https://centralcsp.com/en/blog/set-csp-header-every-framework)
FAQ
## Frequently asked questions
Building a CSP, a Permissions-Policy or a Connection-Allowlist, filtering noise and rolling it out, answered.
### Can you really build a Content Security Policy from real traffic?
Yes, and it is the point. You deploy a report-only policy once, and every browser that visits reports the scripts, styles and connections your pages load. CentralCSP aggregates those reports into a policy that covers your whole site, including the pages and third parties a one-page crawler never reaches.
### Will a generated CSP break my site when I turn it on?
Not the way it is built. Every value your pages rely on starts added, even one that weakens the policy, so the policy you copy covers what your site loads today. It then runs in report-only first: sent as Content-Security-Policy-Report-Only, it reports violations but blocks nothing, so you see exactly what enforcing would break before it breaks. You switch to the enforcing Content-Security-Policy header only once the report-only run is clean, and you can switch back at any time. The Permissions-Policy and Connection-Allowlist builders follow the same rule.
### How long should I collect before I enforce?
At least a week, and until your important flows have been walked by real traffic. Checkout, login and admin are the ones that matter: a page nobody visited during the period you build from is a page whose sources you have not seen yet. The builders read up to 30 days of reports at a time (the last 7 for very high-volume sites), so pick a period that covers them. High-traffic sites usually settle within days; a low-traffic page can take weeks, and a quarterly campaign page will not appear until the campaign runs. There is no deadline, because report-only can stay on indefinitely and keeps reporting the whole time.
### How do you filter out browser-extension noise?
Ad blockers, password managers, antivirus suites and shopping assistants inject code into every page, and that code trips your policy. It is the main reason CSP reports feel like noise. The builder sets browser-extension sources aside, treats known injectors such as adware and coupon tools as noise outright, and scores everything else on volume, bursts and how many browsers reported it. Noise starts rejected, so a source that showed up inside one user's browser doesn't get mistaken for a real dependency, and you can still add it back if it is yours.
### What happens to my inline scripts?
They are kept working, and flagged loudly. If your pages run inline scripts today, the builder keeps 'unsafe-inline' so the copied policy does not break them, and marks it high risk: that single keyword switches off most of what a script-src directive protects you from. The value comes with the fix: move each inline script into a file served from your site, or give it a nonce generated for every response, then reject 'unsafe-inline'. If your policy already uses nonces, the builder rejects 'unsafe-inline' for you and adds 'strict-dynamic', so the scripts your nonced scripts load keep working.
### How is this different from a free CSP generator that scans my URL?
A scanner loads one page in a headless browser and writes a policy for what it happened to see. It misses anything behind a login, a click or an A/B test, and the third-party widget that only loads for some visitors. A policy built from real traffic covers all of it, because the reports come from real users on every page they actually opened.
### Do I need an existing CSP to start?
No. Without one, you start from the CentralCSP baseline: default-src 'self', object-src 'none', frame-ancestors 'none', base-uri and form-action locked to your own origin, and nothing third-party allowed yet. The builder fills it from what real browsers report. If you already run a CSP that reports to CentralCSP, the builder detects it from the reports, tells you which policy is live, which is partial and which was replaced, and lets you start from yours instead.
### How do you generate a Permissions-Policy header?
Browsers never report the Permissions-Policy a page was served with, so you start from a preset (deny every listed feature, a payment page baseline, or camera and microphone) or paste the header you send today. The builder then reads two report types: the violations your own pages and scripts trigger, and the potential violations raised when an iframe asks for a feature through its allow attribute. A feature your pages used is granted to self, a feature a frame asked for is granted to that frame's origin, and a feature only a third-party script reached for stays denied. Deploy it as Permissions-Policy-Report-Only first.
### What should my Permissions-Policy header contain?
Deny every feature you do not use with an empty allowlist, such as camera=(), microphone=() and geolocation=(). Grant a feature to self when your own pages need it, and to a named origin only for a frame that needs it; that frame also needs the feature in its iframe allow attribute. Never widen a feature to \*: that hands it to every frame you embed. The builder's deny-everything preset covers 25 features, from the camera and USB to the payment sheet and clipboard.
### What is the Connection-Allowlist header?
Connection-Allowlist is a response header that lists the only destinations a page may connect to. The browser blocks every other outgoing connection, so even a script running on your page cannot send data to a host you never listed. Redirects and WebRTC stay blocked too unless you allow them. It is an egress control, where most other policy headers control what loads.
### How is Connection-Allowlist different from CSP connect-src?
CSP connect-src restricts the requests scripts make with fetch, XHR, WebSockets and beacons, as one directive among many that decide what a page may load and run. Connection-Allowlist is a single list for the page's outgoing connections, and it also covers what connect-src never did: WebRTC peer connections and where a redirect can lead. Run both: only Chromium-based browsers enforce Connection-Allowlist, so connect-src remains the egress control for every other browser.
### Which browsers support Connection-Allowlist?
Chrome, Edge and other Chromium-based browsers enforce and report it. Other browsers ignore the header, so it adds protection without breaking anything for them. The header is new: deploy it as Connection-Allowlist-Report-Only first, and keep CSP connect-src alongside it.
### Does the policy stay current as my site changes?
Reports keep arriving after you deploy, so the next build is always one run away. Start from the policy you serve today, pick the latest period, and the review shows what real browsers reported since: a new script, a new origin, a violation your policy now blocks. Alerting covers the gap in between, so you hear about an origin you never approved when it shows up, instead of at the next rewrite.
### Can I build a policy from the API or an AI agent?
Yes, from the Business plan. Each builder is a REST endpoint and a tool on the CentralCSP MCP server (build\_recommended\_csp, build\_recommended\_permissions\_policy and build\_recommended\_connection\_allowlist): ask for a recommended policy for a website over a period, optionally starting from a policy you already have, and get the header value back with the Reporting-Endpoints value to send beside it. Nothing is saved, and the dashboard, the API and MCP all run the same code, so they give the same answer.
## Start collecting today. Enforce when you're ready.
Ship one report-only header this afternoon, then build your CSP, Permissions-Policy and Connection-Allowlist from what real browsers report. 14-day free trial, no agent, no page script.
[Start free trial](https://app.centralcsp.com) [Evaluate a policy for free](https://centralcsp.com/en/tools/csp-evaluator/)
---
Available in: [en](https://centralcsp.com/en/platform/csp-builder/), [fr](https://centralcsp.com/fr/platform/csp-builder/)
```yaml
title: "CSP violation monitoring and 12 browser report types"
description: "One endpoint collects all 12 browser report types: CSP violations, script hashes, NEL, crashes. Deduped, classified, EU-hosted."
url: "https://centralcsp.com/en/platform/monitoring/"
lang: "en"
```
Monitoring
# All browser signals, in one place.
Blocked scripts, failed connections, crashed tabs: browsers report them as real users browse. CentralCSP collects all of it with one response header.
[Start free trial](https://app.centralcsp.com) [Check what your site collects](https://centralcsp.com/en/tools/reporting-api/)
How it works
## From response header to alerts in your existing channels.
A reporting endpoint is a URL the browser POSTs its reports to, named in a Reporting-Endpoints response header. CSP violation monitoring is collecting those reports from real traffic, deduplicating them and reading them, whether your policy runs in report-only or enforced.
1. 01 - Collect
### Ship one header
Add Reporting-Endpoints at your CDN, proxy or framework. Legacy report-uri lands on the same endpoint.
2. 02 - Process
### Collected, deduped, classified
Browsers send reports in the background: visitors feel nothing. Every report is kept; duplicates group together and extension false positives get flagged.
3. 03 - Act
### Watch, alert, export
Filter the live feed, route alerts to your channels, pull the raw JSON over the API.
Setup
## Your reporting endpoint is one response header away.
Add Reporting-Endpoints to your responses and browsers start delivering their reports to your endpoint.
response header
Reporting-Endpoints :
default= "https://MyEndpoint.report.centralcsp.com"
Have a CSP already? Point its report-to at the same endpoint and every violation lands there too. Legacy report-uri payloads are accepted as well, so switching collectors is the same one-line change.
1. ### Add your site
Create the site in your dashboard and copy its managed reporting endpoint.
2. ### Ship the header
Deploy from your edge or app. Reports flow from real visitor browsers immediately.
3. ### Route the signal
Watch the live dashboard, wire alerts to your channels, pull anything over the API.
Verify your setup
## Is your site already reporting?
Verify my config
Free, no account needed. Results land on a shareable page.
The scan verifies
- Policy setup: which report types your headers request
- Endpoint setup: where reports are sent and if it responds
- Misconfigurations: what silently gets dropped today
Aggregation
## A million reports become a short list of issues.
Raw reports stay stored and queryable, but you work from the aggregate: grouped, deduped and ranked so the real problem surfaces first.
- See the trend, spot the change
- Aggregated: one issue, one row
What we collect
## Twelve report types. Three reasons to want them.
Most tools stop at CSP violations. Browsers can report much more, and every type below lands on the same endpoint, parsed and searchable.
### Attack signals
The reports that catch injected code, tampered files and data leaving the page.
`csp-violation`
CSP violations
A resource loaded, or tried to, against your Content Security Policy. Works enforced or report-only.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation)
`csp-hash`
Script hashes
The hash of every script your pages execute. Your script inventory, and your PCI DSS 6.4.3 evidence, sourced from real traffic.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-hash)
`integrity-violation`
Integrity violations
A file no longer matches its Subresource Integrity hash. Either your build changed it, or someone else did.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/integrity-violation)
`connection-allowlist`
Connection Allowlist violations
An outbound connection left the page for an origin you never declared. This is how exfiltration gets noticed.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/connection-allowlist)
### Failures your server never logs
These happen before the request reaches you, or after the page is dead. Only the browser can report them.
`network-error`
Network errors (NEL)
DNS failures, TLS errors and dropped connections, logged by the browser that experienced them. Network Error Logging takes its own NEL header and a Report-To group, and is Chromium-only today.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/network-error)
`crash`
Crashes
The tab crashed or ran out of memory. A dead page can't run a monitoring script; the Reporting API is the only witness.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/crash)
`deprecation`
Deprecations
Your pages call an API the browser plans to remove, with the removal date when the browser knows it.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/deprecation)
`intervention`
Interventions
The browser changed your page's behavior on its own: an autoplay denied, a slow script throttled.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/intervention)
### Policy hygiene
Proof that the isolation and permission policies you ship actually hold in production.
`permissions-policy-violation`
Permissions Policy violations
Code asked for camera, geolocation or another gated feature against your Permissions-Policy.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/permissions-policy-violation)
`document-policy-violation`
Document Policy violations
A page behavior broke the configuration your Document-Policy declares.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/document-policy-violation)
`coop`
COOP violations
A cross-origin window interaction your Cross-Origin-Opener-Policy blocked or would block.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/coop)
`coep`
COEP violations
A resource loaded without the opt-in your Cross-Origin-Embedder-Policy requires.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/coep)
Coverage
## Reports from every visitor, everywhere.
Your monitoring runs wherever your users are: every browser, every network, every country your traffic comes from.
### Full Reporting-API support
All 12 report types over both header generations, on one endpoint. If a browser can send it, we collect it.
### Real-time signal
Reports hit your feed moments after the browser sends them, already deduped and classified. Alert rules fire as it happens.
### Built for scale
1.5 billion reports ingested and counting, landing in France on OVH and never leaving the EU. A violation spike on your busiest day is when the feed matters most, so it never falls behind.
After collection
## Collection is half the job.
What the platform does with the reports once they're parsed.
### Live dashboard
Filter the feed by report type, directive, browser or origin, and drill into any report's raw JSON.
- Feed filtered by type, directive, browser, origin
- Raw JSON for every report
- Per-site scores and inventories
[Open the dashboard](https://app.centralcsp.com)
### Alert rules
New origin, hash change, violation spike: route what matters to the channels your team already uses.
- New-origin and hash-change rules
- Violation spike detection
- Slack, Teams, Google Chat, Telegram, email
[See alerting](https://centralcsp.com/en/platform/alerting/)
### API and MCP
Everything in the feed is queryable over the REST API, exportable as CSV, and drivable by AI agents over MCP.
- REST API with workspace API keys
- CSV and raw-report exports
- Built-in MCP server
[See the API](https://centralcsp.com/en/platform/api-mcp/)
### CSP builder
Turn the collected violations into a Content Security Policy that fits your real traffic, then tighten it over time.
- Policy built from production reports
- Directive-by-directive suggestions
- Test in report-only first
[See the CSP builder](https://centralcsp.com/en/platform/csp-builder/)
### PCI DSS evidence
The same reports feed a continuous script inventory of your payment pages, exported as auditor-ready evidence.
- Requirements 6.4.3 and 11.6.1
- Continuous script inventory
- Auditor-ready exports
[See PCI DSS](https://centralcsp.com/en/platform/pci-dss/)
### Supply chain
Every script in your inventory is checked against known CVEs, so a compromised dependency doesn't stay quiet.
- Known CVEs flagged in your scripts
- New-script detection
- Fed by the same reports
[See supply chain](https://centralcsp.com/en/platform/supply-chain/)
Further reading
## Read the reference before you wire it up
How the Reporting API works, which header to send, and what happens to a report once it lands.
- [How the Reporting API works](https://centralcsp.com/en/docs/web-security/reporting-api/concepts/how-the-reporting-api-works)
- [The Reporting-Endpoints header](https://centralcsp.com/en/docs/web-security/reporting-api/headers/reporting-endpoints)
- [Connect your site step by step](https://centralcsp.com/en/docs/platform/websites/connect-your-site)
- [Read the monitoring guide](https://centralcsp.com/en/docs/platform/monitoring)
- [How long reports are kept](https://centralcsp.com/en/docs/platform/security/data-retention)
- [Where browser CSP reports go, and build vs buy](https://centralcsp.com/en/blog/where-to-send-csp-reports)
FAQ
## Frequently asked questions
Performance, privacy and browser support, answered.
### Does collecting reports slow my site down?
No. There is no script to load: the browser generates reports itself and sends them in batches, out of band, up to a minute after the page loads. Your pages ship the same bytes as before, plus one response header.
### How long are reports stored?
Browser reports are kept for 90 days. That window is fixed and not configurable. The decisions you make on top of them, such as script justifications and audit log entries, are kept until the account is deleted, because those are the records an assessment asks for rather than raw telemetry.
### Do browser reports contain personal data?
The payload contains URLs, directives, source locations and the browser family; it does not contain cookies, form input or session identity. URLs can still carry personal data in their query parameters (an email or a token in a query string, for example), so CentralCSP offers an option to strip query parameters from collected reports before anything is stored. Reports are stored in France, on OVH, and never leave the EU.
### Which browsers send reports?
Effectively all of them. Modern browsers report through the Reporting API; older ones still send CSP violations through the legacy report-uri directive. CentralCSP accepts both formats on the same endpoint, so every browser in your traffic reports.
### What's the difference between report-uri, report-to and Reporting-Endpoints?
They are three generations of the same idea: report-uri is the legacy CSP directive, Report-To came with the first Reporting API, and Reporting-Endpoints is the current header. Ship Reporting-Endpoints plus report-uri and every generation is covered; both deliver to the same CentralCSP endpoint.
### Why do CSP reports include violations that aren't real?
Browser extensions like ad blockers and password managers inject code into every page, and that code trips your policy. It's the main source of CSP noise. CentralCSP collects those reports too, and flags them as extension noise so you can tell at a glance what matters on your site.
### Do I need a Content Security Policy before I can monitor?
No. Crash, deprecation and intervention reports only need the Reporting-Endpoints header. Network errors are the exception: they take their own NEL header plus a Report-To group. For CSP, you can start with Content-Security-Policy-Report-Only, which reports everything and blocks nothing.
### Can I just build my own report collector?
Yes. An endpoint is a URL that accepts POST with application/reports+json, and application/csp-report for the legacy report-uri format, and returns a 2xx. The endpoint is the easy part. What follows is volume, because a busy site generates far more reports than page views on the day a policy is wrong; deduplication, because the same violation arrives thousands of times; browser-extension noise, which is the majority of what an open endpoint receives; and storage you have to keep queryable. CentralCSP is those four, not the URL.
### What happens on a violation spike, or when a site hits its report quota?
Each website carries its own cap, so one misconfigured site cannot drain the workspace quota on its own. Ingestion filters let you restrict which origins are allowed to report, which is how you keep an open endpoint from absorbing traffic that is not yours. You get usage warnings at 80% and 100% of the workspace quota by email, and ingestion stops at the limit rather than billing past it.
## Your next visitor can be your first report.
Add the header, watch the feed fill up with real traffic. 14-day free trial, no agent to deploy.
[Start free trial](https://app.centralcsp.com) [Check your reporting setup](https://centralcsp.com/en/tools/reporting-api/)
---
Available in: [en](https://centralcsp.com/en/platform/monitoring/), [fr](https://centralcsp.com/fr/platform/monitoring/)
```yaml
title: "PCI DSS 6.4.3 & 11.6.1: payment page script inventory"
description: "Inventory every payment page script from real browser traffic, justify each one, alert on change, and export QSA evidence for 6.4.3 and 11.6.1. No agent."
url: "https://centralcsp.com/en/platform/pci-dss/"
lang: "en"
```
PCI DSS 6.4.3 & 11.6.1
# Every payment page script, inventoried and justified.
CentralCSP builds your script inventory from real browser traffic, records the justification 6.4.3 asks for, alerts on every change, and exports the evidence your assessor reads. Nothing new runs on your checkout.
[Start free trial](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
- PCI DSS v4.0.1
Requirements 6.4.3 and 11.6.1
- Nothing on your page
No agent, no proxy
- Audit evidence
CSV and PDF export
- EU data residency
France, on OVH
PCI DSS v4.0.1, mandatory since 31 March 2025
## What the assessment asks. What you hand back.
Requirements 6.4.3 and 11.6.1 exist because payment page skimmers (e-skimming, Magecart, formjacking) run entirely in the visitor's browser and never touch your server logs. Here is each clause, mapped to the artifact CentralCSP produces for it.
Requirement 6.4.3 asks you to manage every script loaded and executed in the consumer's browser on a payment page: confirm each one is authorized, assure its integrity, and keep an inventory with a written business or technical justification for each.
Requirement 11.6.1 asks for a change and tamper detection mechanism that alerts your team to unauthorized modification of the payment page's scripts, HTTP headers and content as received by the consumer's browser, evaluated at least every seven days.
| The requirement | What CentralCSP produces | Status |
| --- | --- | --- |
| 6.4.3 - Script inventory | An inventory of every script loaded on your payment pages, built from what real visitor browsers execute and kept current with every deploy. Not a spreadsheet that was true last quarter. | Covered |
| 6.4.3 - Authorization | Each script carries an authorization status. New ones land as pending review, so nothing stays on the page unaccounted for. | Covered |
| 6.4.3 - Written justification | A business or technical justification recorded per script. Rules auto-validate known patterns, so a routine hash rotation never queues for manual re-approval. | Covered |
| 6.4.3 - Integrity | Script hashes tracked from real traffic. When contents change, the change lands on the timeline and your team is alerted. | Covered |
| 11.6.1 - Change and tamper detection | New scripts and new origins on the payment page raise an alert the moment browsers report them: additions, changes and deletions, dated. | Covered |
| 11.6.1 - Evaluation frequency | The requirement's floor is weekly. Reports flow continuously from production traffic, so evaluation never waits for a scheduled crawl. | Covered |
| Assessment evidence | One export: the inventory, justifications and change history as CSV or PDF, plus an SBOM of the site's technologies and versions. | Covered |
### Your payment page, as a timeline.
Every script change on the checkout becomes a dated event: a file appeared, a hash rotated, an origin showed up for the first time. When the assessor asks what changed since last year, you scroll. You do not reconstruct.
- A new script file on the page
- A hash that changed on a script you already run
- An origin seen on the page for the first time
- A script that disappeared
- The change record 11.6.1 reviews expect
### Justify once. Rules absorb the noise.
6.4.3 wants a written justification for every script. Record it when the script first appears, then let auto-validation rules carry the routine: a known pattern rotating its hash revalidates itself, an unknown file stays pending until a human looks.
- Written justification stored per script
- Auto-validation rules for known patterns
- A pending queue for anything new
### Know what your scripts are made of.
CentralCSP identifies the library and version behind each script, flags known CVEs and end-of-life versions, and exports the lot as an SBOM of your site. The vulnerable jQuery on the checkout stops being a surprise finding.
- Technology and version identification
- CVE and end-of-life flags
- SBOM export of the whole site
[Check any page for free](https://centralcsp.com/en/tools/tech-checker/)
### The alert reaches the team that owns the page.
A new script or a new origin on a payment page pings Slack, Microsoft Teams, Google Chat, Telegram or email the moment a browser reports it. Keep the notification: between assessments, it is the control demonstrably working.
- New-script and new-origin alerts, built in
- 6 channels including webhooks
- Routed per site and per team
Payment page script monitoring
## Four ways to run 6.4.3 and 11.6.1.
Each of these can pass an assessment. They differ in what they see, what they add to the payment page, and what the evidence costs to produce.
Comparison of approaches to PCI DSS 6.4.3 and 11.6.1
| | CentralCSP | WAF-based | Scheduled crawl | Proxy or agent |
| --- | --- | --- | --- | --- |
| Adds nothing to the payment page | Nothing added to the page | A dependency at the edge | Nothing added to the page | New dependency, new failure point |
| Builds the inventory automatically | Automatic, from real browsers | Never executes the page | Only what the crawl reached | From its agent's sessions |
| Alerts on change and tampering (11.6.1) | Continuous, from live traffic | Blind in the browser | Only at scan cadence | While its agent runs |
| Provides a justification workflow (6.4.3) | Built-in auto-validation rules | Not provided | Varies by product | Varies by product |
| Detects CVEs and exports an SBOM | Included, with SBOM export | Not for page scripts | Varies by product | Rarely included |
| Exports audit-ready evidence | One-click CSV / PDF | Raw request logs | Usually exportable | Usually exportable |
Evidence as data
## The inventory is queryable, not a screenshot.
Everything the dashboard shows is on the REST API: pull the payment page inventory, justification statuses and change history into your GRC tooling, or let an agent drive it over MCP.
- Full REST API with workspace API keys
- CSV and PDF exports from the dashboard
- Built-in MCP server for AI agents
[See the API and MCP platform](https://centralcsp.com/en/platform/api-mcp/)
How it works
## Ten minutes to set up. Evidence whenever it's asked.
No agent, no SDK, no change to the checkout's behavior. Browsers report natively.
1. 01 - Connect
### Add one response header.
Create your site in the dashboard and set the reporting header. Real visitor browsers start reporting what the payment page loads within minutes.
2. 02 - Justify
### Review the inventory once.
Approve what belongs, record why, set the auto-validation rules. From then on, only genuinely new scripts ask for your attention.
3. 03 - Prove
### Export when the QSA asks.
Inventory, justifications and the change timeline as CSV or PDF. The evidence matches what actually ran in browsers, so the conversation is short.
The dashboard
## Your payment pages, on one screen.
Inventory, justifications, changes and alerts for every payment page, behind one login.
- Every script, with its SHA-256
- Every change, dated and attributed
Trusted by teams across the world
Pricing
## PCI DSS features ship in the Scale plan.
Payment page monitoring, the justification workflow, evidence exports and CVE detection are all part of Scale, on top of everything in Business: automated scanning, alerting, API and MCP.
- Payment-page script inventory
- Justification workflow and auto-validation rules
- CSV and PDF evidence exports
- SBOM, CVE and end-of-life flags
### Scale
PCI DSS v4 evidence, at portfolio scale.
€349.99 / mo
- Applications 30
- Users 100
- Reports / month 10,000,000
Everything in Business, plus:
- CVE detection
- Payment page monitoring
- PCI DSS evidence
- SSO and audit log
- Invoicing and procurement support
[Get started](https://app.centralcsp.com/?plan=scale&billing=monthly)
Further reading
## What an assessor asks for
How requirements 6.4.3 and 11.6.1 read in practice, and what the evidence export contains.
- [How a CSP maps to 6.4.3 and 11.6.1](https://centralcsp.com/en/blog/csp-pci-dss-v4)
- [PCI DSS v4 client-side security, explained](https://centralcsp.com/en/blog/pci-dss-v4-client-side-explained)
- [How the inventory is built from CSP hash reports](https://centralcsp.com/en/blog/script-inventory)
- [What is in the evidence export](https://centralcsp.com/en/docs/platform/features/pci-dss/evidence-export)
- [Define payment page scope with URL patterns](https://centralcsp.com/en/docs/platform/features/pci-dss/payment-pages)
- [How auto-validation rules work](https://centralcsp.com/en/docs/platform/features/pci-dss/justification-rules)
FAQ
## Frequently asked questions
What merchants and their assessors ask us, answered.
### What does PCI DSS 6.4.3 actually require?
That every script loaded and executed on your payment pages is managed three ways: a method to confirm each script is authorized, a method to assure its integrity, and an inventory of all scripts with a written business or technical justification for each. CentralCSP produces those three records from your real browser traffic.
### Is a CSP or SRI enough to satisfy 6.4.3?
They cover two of the three clauses, not the third. A Content Security Policy authorizes which origins may load a script, and a hash or a nonce authorizes an exact piece of content, so a CSP is a legitimate authorization method. Subresource Integrity verifies that a static file's bytes are the ones you expect, so SRI is a legitimate integrity method. Neither produces the third thing 6.4.3 asks for: a written inventory with a business or technical justification for every script. That is a record, not a header. CentralCSP builds the inventory from the script hashes browsers report and stores the justification against each script, so the header and the paperwork come from the same source.
### How often does the 11.6.1 check have to run?
The floor is at least once every seven days, or at a frequency you set through a targeted risk analysis under requirement 12.3.1. In practice that floor never becomes the binding constraint here, because the reports arrive from live production traffic rather than from a scheduled job: a script that changes on a Tuesday afternoon is evaluated when the first visitor's browser reports it, not at the next weekly run.
### What counts as a payment page?
Under PCI DSS v4.0.1, any page that captures account data, and the requirements also reach the page that embeds a payment iframe. If your checkout wraps your provider's iframe, that wrapping page is in scope. Monitor it like the form itself.
### Do 6.4.3 and 11.6.1 apply to SAQ A merchants?
The dividing line is the iframe. A merchant who embeds a payment form in an iframe on their own page is reachable by script on that page, so the script-susceptibility eligibility gate applies to them; a merchant who redirects the shopper entirely to a hosted payment page is not reached by it at all. SAQ A-EP merchants, whose own page affects the payment transaction, carry 6.4.3 and 11.6.1 in full with no eligibility gate to consider. Since the January 2025 revision, SAQ A no longer lists them, but its new eligibility criteria expect you to confirm your site is not susceptible to script attacks, which in practice means running the same controls or holding an attestation from your payment provider. Confirm the interpretation with your QSA; CentralCSP gives you the evidence either way.
### How much work is the justification requirement, really?
The first pass is the work: approve each script on the page and record why it is there. After that, auto-validation rules absorb the routine. A known script rotating its hash revalidates itself; you only hear about files and origins that are genuinely new.
### Does 11.6.1 cover HTTP headers too?
Yes. The requirement is written around the payment page as the consumer's browser receives it, which is its scripts, its HTTP headers and its content, not scripts alone. CentralCSP alerts on the script and origin side from browser reports: a new file, a rotated hash, an origin appearing for the first time. For the header side, the free security headers checker grades what a page sends today, and CSP monitoring watches the policy header over time once it is deployed.
### What evidence does my QSA actually get?
A CSV or PDF export of the payment page inventory with each script's justification and authorization status, the dated change timeline, and an SBOM of technologies, versions and known CVEs. It is the artifact list assessors ask for, generated from what real browsers executed.
### Does CentralCSP add latency to the checkout, or block anything?
Neither. Nothing loads on your page: browsers send reports natively through the Reporting API, so monitoring stays out of the serving path. Enforcement remains your CSP's job, which CentralCSP helps you build from the same reports. What 11.6.1 demands for payment page scripts, detection and alerting, is exactly what it does.
## Walk into the assessment with the inventory ready.
Connect a payment page this afternoon; browsers start reporting within minutes. No agent to deploy, nothing added to the checkout.
[Start free trial](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
---
Available in: [en](https://centralcsp.com/en/platform/pci-dss/), [fr](https://centralcsp.com/fr/platform/pci-dss/)
```yaml
title: "Client-side supply chain & Magecart script monitoring"
description: "Magecart and supply-chain protection: inventory every script real browsers run, its version and CVEs, and get alerted when one changes. No agent, no proxy."
url: "https://centralcsp.com/en/platform/supply-chain/"
lang: "en"
```
Supply-chain security
# Every script your visitors run, and what's inside it.
Your firewall never sees the third-party scripts in your visitors' browsers. We do: every script, its library and version, and the moment one changes or picks up a CVE.
[Start free trial](https://app.centralcsp.com) [Book a demo](https://centralcsp.com/en/contact/?topic=demo)
- 0 scripts added
Browsers report natively
- Real visitor traffic
Not a crawler snapshot
- CVE detection
Fingerprinted from content
- EU data residency
France, on OVH
The threat
## The breach that never touches your server.
A client-side supply-chain attack compromises a third-party script your page already loads, so the malicious code runs in your visitors' browsers rather than on your servers. Server-side tooling misses it because nothing on your infrastructure changed. Our annual census found 22.0% of the web ships a Content-Security-Policy at all, and only 0.97% of domains have one that passes. Three incidents, three routes in.
1. ### Polyfill.io, 2024
The polyfill.io domain changed hands in February. By June, the CDN behind it was injecting malicious redirects into pages on 100,000+ websites that embedded one script tag. The code dodged admin users and analytics tools, so sites that only tested their own pages saw nothing.
[Sansec's report](https://sansec.io/research/polyfill-supply-chain-attack)
2. ### British Airways, 2018
Magecart attackers edited roughly 22 lines of a Modernizr file on ba.com. For 15 days, every payment form fed cards to an attacker domain. About 400,000 customers were hit; the ICO fine closed at 20 million pounds.
[The ICO's penalty notice](https://ico.org.uk/media2/migrated/2618421/ba-penalty-20201016.pdf)
3. ### npm chalk and debug, 2025
18 packages with 2.6 billion combined weekly downloads shipped malicious versions after one maintainer got phished. The payload ran in end users' browsers, hooking fetch and wallet APIs. Every build-time check passed at install; the attack ran after the build.
[Aikido's write-up](https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised)
How it works
## One response header in. Every script accounted for.
No agent to load, no proxy in your delivery path, no robot visiting your site. Your real visitors' browsers are the sensors.
1. 01 - Collect
### Browsers report every script they run
Add one response header. From then on, real visitors' browsers report the URL and hash of every script your pages execute: first-party, third-party, and the fourth-party scripts your third parties load after they run, like the tag your tag manager pulled in last night.
2. 02 - Analyze
### We identify what's inside each script
Each script's content is fingerprinted and analyzed to identify the library, framework or vendor behind it, and its version. That identity is checked against known CVE databases and lifecycle status: outdated, unmaintained, end-of-life.
3. 03 - Act
### Changes and CVEs become alerts
A new script, a changed hash, a new outbound origin or a fresh CVE pings Slack, Teams, Google Chat, Telegram or email as browsers report it. Fix the finding, or block the vector with a CSP built from the same reports.
### A third-party script inventory built by your real traffic.
Skimmers cloak: they fire on real checkouts in real sessions and stay dormant for crawlers and sandboxes. CentralCSP's inventory comes from what actual visitors' browsers executed, so a script that only misbehaves in production is still on the list.
- First-party and third-party scripts, per page
- Fourth-party scripts: the ones your third parties load after they run
- Last-seen times from live traffic
- New scripts flagged the moment they appear
### A CVE in a marketing tag is still your CVE.
Knowing a script's filename tells you nothing about the jQuery inside it. CentralCSP fingerprints each script's content, resolves the library and version it contains, and holds it against CVE databases and maintenance status. You patch the vulnerable version before someone else finds it first.
- Content fingerprinting, not just URL matching
- Known CVEs matched to the exact version
- End-of-life and unmaintained versions flagged
[Check any page for free](https://centralcsp.com/en/tools/tech-checker/)
### The SBOM your build pipeline can't produce.
Your CI scans what's in the repo. The tag manager's payload, the chat widget and the analytics snippet never pass through it, and the npm compromise of September 2025 cleared every build-time check before doing its damage in browsers. This SBOM lists what actually ran client-side.
- Technologies and versions from live pages
- Covers scripts that never touch your repo
- Export it for security reviews and audits
### Data leaving the page is a report, not a mystery.
Web skimming has two tells: a file that changed, and data flowing to an origin you never approved. Browsers report both by name. A script that stops matching its SRI hash arrives as an integrity-violation report; a script whose bytes changed arrives as a csp-hash script hash report; a page talking to an undeclared origin arrives as a connection report.
- Outbound connections to unknown origins reported
- SRI mismatches arrive as integrity-violation reports
- Byte changes arrive as csp-hash script hash reports
Prevention
## Detection tells you. Configuration stops it.
The same reports that build your inventory harden your policy: lock down what can load and where data can go, then let the browser enforce it.
### A CSP from real traffic
The CSP builder turns collected reports into a policy that fits your site: script sources locked to what you actually use, connect-src and form-action closed to unknown origins, so a skimmer has nowhere to send the data.
- Built from production reports
- Exfiltration destinations locked down
- Report-only first, enforce when clean
[See the CSP builder](https://centralcsp.com/en/platform/csp-builder/)
### Integrity on your assets
Pin your static scripts with Subresource Integrity and a swapped file refuses to run. Browsers report every mismatch, so tampering surfaces even where you can't pin.
- SRI hashes generated in seconds
- Integrity violations reported live
- Covers the polyfill.io failure mode
[Generate SRI hashes](https://centralcsp.com/en/tools/sri-hash/)
### Headers graded continuously
The free scanners grade your CSP and security headers like an attacker reads them: which origins may run code, which destinations may receive data, what reporting you'd have during an incident.
- CSP and header scanning
- Reporting setup verified
- Free, no account needed
[Scan your headers](https://centralcsp.com/en/tools/security-headers/)
Approaches
## Three ways to watch your scripts.
Three deployment models, by the names buyers use: agentless reporting, an injected agent, and proxy delivery. Every client-side security product answers one question differently: what do you have to add to your site to get visibility? Here is the honest comparison the vendors skip.
Comparison of client-side security deployment models
| | CentralCSP (agentless) | Injected agent | Proxy delivery |
| --- | --- | --- | --- |
| Adds nothing to your page | Nothing, a header | Its own script | A proxy in the path |
| Sees real visitor sessions | Every browser reports | While its script runs | Proxied traffic only |
| Catches cloaked skimmers | Fires on real checkouts | Unless evaded first | If payload inspected |
| Produces PCI DSS 6.4.3 evidence | Exportable inventory and justifications | Varies by product | Varies by product |
| Blocks malicious scripts inline | Via your CSP | In-browser blocking | Blocks at the edge |
| Adds no page weight or latency | Zero bytes added | Runs on every page | Latency per fetch |
| Adds no new attack surface | Never in the page | One more third party | It serves your code |
Check your exposure
## How exposed is your site right now?
Two minutes: see which origins can run code on your pages today, and whether you would even hear about it when one goes bad.
Scan my site
Free, no account needed. Results land on a shareable page.
Trusted by teams across the world
Pricing
## CVE detection starts on Scale.
The script inventory is included from the Start plan, and alerting, automated scanning and the full API and MCP arrive with Business. Scale adds CVE detection, alongside payment page evidence for PCI DSS.
- Script inventory from real traffic
- CVE and end-of-life detection
- New-script and hash-change alerts
- API, MCP and CSV exports
### Scale
PCI DSS v4 evidence, at portfolio scale.
€349.99 / mo
- Applications 30
- Users 100
- Reports / month 10,000,000
Everything in Business, plus:
- CVE detection
- Payment page monitoring
- PCI DSS evidence
- SSO and audit log
- Invoicing and procurement support
[Get started](https://app.centralcsp.com/?plan=scale&billing=monthly)
## Taking payments? This is now mandatory.
Since March 2025, PCI DSS v4 requires a justified inventory of every payment page script (6.4.3) and alerts on unauthorized changes (11.6.1). That is this page's feature set, pointed at your checkout, with the evidence exports your assessor asks for.
[See PCI DSS evidence](https://centralcsp.com/en/platform/pci-dss/)
- Script inventory with justifications
- Change and tamper alerts
- CSV and PDF evidence exports
- SBOM for the assessor
Further reading
## How client-side attacks actually work
Where skimmers come from, how a script inventory is built, and how to enforce integrity on every asset.
- [Script hash reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-hash)
- [How to detect a client-side skimmer](https://centralcsp.com/en/blog/magecart-formjacking-detection)
- [Build a script inventory with CSP hash reporting](https://centralcsp.com/en/blog/script-inventory)
- [Enforce SRI on every script with Integrity-Policy](https://centralcsp.com/en/blog/integrity-policy-explained)
- [How attackers abuse Google Tag Manager](https://centralcsp.com/en/blog/google-tag-manager-security-risk)
- [CSP and PCI DSS v4: 6.4.3 and 11.6.1](https://centralcsp.com/en/blog/csp-pci-dss-v4)
FAQ
## Frequently asked questions
Client-side supply-chain attacks and how we catch them, answered.
### What is Magecart, and is it the same as formjacking or e-skimming?
Magecart is the name given to the family of attacks that inject skimming JavaScript into checkout and login pages to steal card numbers and credentials as they are typed. Formjacking, e-skimming and web skimming describe the same technique under different names. The defining trait is where it runs: the theft happens in the visitor's browser, in the page you served, which is why your server logs and your database look untouched afterwards. The British Airways breach on this page is the textbook case.
### What is a client-side supply-chain attack?
An attack that reaches your users through code your pages load from someone else: a third-party script, a CDN, a tag manager, an npm package that ends up in your bundle. The vendor gets compromised, your page delivers the payload, and the theft happens in the visitor's browser. Your servers are never breached, which is why server-side tooling misses it.
### Can a Content Security Policy stop Magecart attacks?
It stops a lot: a strict CSP blocks scripts from origins you never approved and, through connect-src and form-action, blocks data from being sent to the attacker's server. What it can't judge is an approved vendor turning malicious, which is exactly what happened to British Airways. That is why CentralCSP pairs the policy with a script inventory, content fingerprinting and change alerts: the CSP closes the doors, script monitoring watches the vendors you let in.
### Is Subresource Integrity enough on its own?
It is a real control, and it is not sufficient. SRI pins a file whose markup you control: you put the hash in the tag, and the browser refuses the file if the bytes ever differ. That covers a swapped library on a CDN. It cannot cover a script injected at runtime by a tag manager, or one loaded by another script, because neither has a tag you wrote a hash into. That gap is why the browser also reports integrity violations and script hash changes: SRI tells you a pinned file was swapped, and the hash reports tell you about everything that was never pinned in the first place.
### Why don't my WAF or my dependency scanner catch this?
They stand in the wrong places. The WAF inspects traffic to your servers, and a skimmer sends data from the visitor's browser straight to the attacker's domain, so the WAF never sees the request. Your dependency scanner checks the code in your repository, and the tag manager's payload or the chat widget never passes through it. The only place every script is visible is the browser that executes it, and that is where CentralCSP's reports come from.
### How does CentralCSP detect CVEs in my scripts?
Browsers report the URL and hash of every script your pages execute. CentralCSP fingerprints each script's content and runs its own analysis to identify the library or framework inside and its exact version, then checks that identity against known CVE databases and lifecycle data. You get the finding attached to the script and page it runs on: a known CVE, an end-of-life version, or a library that stopped being maintained.
### How quickly will I know a script changed?
As reports arrive from live traffic. Browsers queue reports and deliver them out of band, typically within a minute of the page load that produced them, so a new script, a changed hash or a new outbound origin surfaces once real visitors have loaded the page. The alert rule fires on that event, not on a schedule. The contrast worth drawing is with crawler-based checks, which tell you at the cadence you set them to run: PCI DSS 11.6.1 puts the floor at once every seven days, and a weekly crawl meets that floor while leaving six days in which a skimmer is live and unreported.
### What is a client-side SBOM?
A software bill of materials for what runs in the browser rather than what sits in your repository. A build-time SBOM stops at your bundle; the client-side SBOM also covers the scripts your pages pull in at runtime, from tag managers to support widgets, with the version and vulnerability status of each. It is the list a security review actually wants: what code ran in front of the user.
### Does CentralCSP add a script or latency to my site?
No. Detection is built on the Reporting API: browsers generate reports natively and send them in the background, so your pages ship the same bytes as before, plus one response header. There is no agent to compromise, no proxy in your delivery path, and nothing new to add to your own script inventory.
## Find out what your pages ran today.
Add the header this afternoon and the inventory builds itself from your next visitors. Free trial, no agent, no proxy, no code change.
[Start free trial](https://app.centralcsp.com) [Scan your site for free](https://centralcsp.com/en/tools/security-headers/)
---
Available in: [en](https://centralcsp.com/en/platform/supply-chain/), [fr](https://centralcsp.com/fr/platform/supply-chain/)
```yaml
title: "CentralCSP pricing - client-side security plans"
description: "Compare CentralCSP plans for client-side security and CSP monitoring. Every paid plan is EU-hosted with all browser report types. 14-day free trial."
url: "https://centralcsp.com/en/pricing/"
lang: "en"
```
Pricing
# Plans and pricing for client-side security.
EU hosting, all report types, and 90-day retention come standard on every paid plan. Pay annually and get two months free.
Monthly Annual
Save 2 months by paying yearly
## Start
For a first production site.
€39.99 / mo
14-day free trial
- Applications 3
- Users 5
- Reports / month 250,000
Plan features
- Full Reporting-API support
- Unlimited scans
- Script inventory
- Team access and RBAC
- Policy builder
[Start free trial](https://app.centralcsp.com/?plan=start&billing=monthly)
Recommended
## Business
Automate it and wire it into your stack.
€129.99 / mo
- Applications 10
- Users 25
- Reports / month 2,000,000
Everything in Start, plus:
- Alerting to six channels
- Unlimited alerts
- API & MCP
[Get started](https://app.centralcsp.com/?plan=business&billing=monthly)
## Scale
PCI DSS v4 evidence, at portfolio scale.
€349.99 / mo
- Applications 30
- Users 100
- Reports / month 10,000,000
Everything in Business, plus:
- CVE detection
- Payment page monitoring
- PCI DSS evidence
- SSO and audit log
- Invoicing and procurement support
[Get started](https://app.centralcsp.com/?plan=scale&billing=monthly)
## Enterprise
For banks, insurers, and large accounts.
Custom
- Applications Custom
- Users Custom
- Reports / month Custom
Everything in Scale, plus:
- Custom quotas and contract
- A contractual uptime SLA
- Priority support and onboarding
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
Trusted by teams across the world
Compare plans
## Compare every capability
See exactly what each plan includes.
| | Start | Business | Scale | Enterprise |
| --- | --- | --- | --- | --- |
| Sources & ingestion | | | | |
| Monitored applications | 3 | 10 | 30 | Custom |
| Users | 5 | 25 | 100 | Custom |
| Reports ingested / month | 250,000 | 2,000,000 | 10,000,000 | Custom |
| Report types | | | | |
| Content-Security-Policy | Included | Included | Included | Included |
| Script Hash Integrity | Included | Included | Included | Included |
| Network errors | Included | Included | Included | Included |
| Deprecation | Included | Included | Included | Included |
| Intervention | Included | Included | Included | Included |
| Crashes | Included | Included | Included | Included |
| Cross-Origin-Embedder-Policy | Included | Included | Included | Included |
| Cross-Origin-Opener-Policy | Included | Included | Included | Included |
| Document-Domain-Policy | Included | Included | Included | Included |
| Permissions-Policy | Included | Included | Included | Included |
| Integrity-Policy | Included | Included | Included | Included |
| Connection-Allowlist | Included | Included | Included | Included |
| Detection & alerts | | | | |
| Alerting | Not included | Included | Included | Included |
| Alert channels | Not included | All (6) | All (6) | All (6) |
| Alerts / month | Not included | Unlimited | Unlimited | Unlimited |
| Script inventory | Included | Included | Included | Included |
| Script analysis | | | | |
| Technology identification | Not included | Not included | Included | Included |
| CVE detection | Not included | Not included | Included | Included |
| Version detection | Not included | Not included | Included | Included |
| Real-time alerting | Not included | Not included | Included | Included |
| Tools | | | | |
| Security header scanner | Included | Included | Included | Included |
| Reporting-API checker | Included | Included | Included | Included |
| Content-Security-Policy scanner | Included | Included | Included | Included |
| Content-Security-Policy evaluator | Included | Included | Included | Included |
| Content-Security-Policy builder | Included | Included | Included | Included |
| PCI DSS compliance | | | | |
| Payment page alerting | Not included | Not included | Included | Included |
| Payment page monitoring | Not included | Not included | Included | Included |
| Script justification | Not included | Not included | Included | Included |
| PCI DSS v4 evidence | Not included | Not included | Included | Included |
| Integrations | | | | |
| API | Not included | Included | Included | Included |
| MCP | Not included | Included | Included | Included |
| Team & access | | | | |
| Team access | Included | Included | Included | Included |
| Role-based access control | Included | Included | Included | Included |
| Audit log | Not included | Not included | Included | Included |
| Single sign-on (SSO) | Not included | Not included | Included | Included |
| Data retention & location | | | | |
| Data retention | 90 days | 90 days | 90 days | 90 days |
| Data location | EU | EU | EU | EU |
| Billing & terms | | | | |
| Self-service | Included | Included | Included | Not included |
| Invoicing & terms | Not included | Not included | Included | Included |
| Legal & procurement support | Not included | Not included | Included | Included |
| Support | | | | |
| Support | Email | Email | Email | Priority (email) |
| Uptime SLA | Not included | Not included | Not included | Included |
| Feature requests | Not included | Not included | Included | Included |
## Need enterprise scale?
For larger deployments and compliance-heavy teams, we shape CentralCSP around your needs, from quotas and hosting to security and support.
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
- Custom quotas for reports, seats, and applications
- SSO, RBAC, and a complete audit log
- EU-hosted, with a contractual uptime SLA
- Priority support, onboarding, and invoicing
FAQ
## Frequently asked questions
Plans, billing, and everything in between.
### Is there a free trial?
Yes. The Start plan includes a 14-day free trial, so you can add the header and see real reports from your own traffic before you pay. The other plans are sold without one.
### How does annual billing work?
Pay yearly and you get two months free: the annual price is ten times the monthly price. You can switch between monthly and annual billing at any time.
### Can I change plans later?
Yes. You can upgrade or downgrade at any time from your dashboard as your needs change.
### Which plan do I need for PCI DSS v4?
PCI DSS v4 evidence, payment-page monitoring, and script justification are included on the Scale plan. To meet requirements 6.4.3 and 11.6.1, choose Scale.
### What comes standard on every paid plan?
EU hosting, all twelve browser report types, 90-day data retention, the script inventory, team access and role-based access control are included on every paid plan, whichever tier you choose. CVE detection starts on Scale.
### Where is my data hosted?
All data is hosted in France on OVH and never leaves the EU, so you keep full European data residency.
### Do you offer invoicing for larger teams?
Yes, from Scale upwards. Scale and Enterprise can be paid by invoice with custom terms and come with help on security reviews, DPAs, and procurement paperwork. Every self-service plan, Scale included, can also be paid by card checkout.
### Which plan includes SSO and the audit log?
Both start on Scale. Scale and Enterprise include single sign-on over SAML or OIDC and a complete, exportable audit log. Team access and role-based access control are on every paid plan, including Start.
### What does the Enterprise plan include?
Everything in Scale, with applications, users, and report volume set to whatever your deployment needs, a contractual uptime SLA, and priority email support. It is quoted and invoiced rather than bought online, so talk to sales.
## Ready to start monitoring?
Add one header and reports start flowing. No agent, no code changes. Start free, upgrade when you need to.
[Start free trial](https://app.centralcsp.com) [Book a demo](https://centralcsp.com/en/contact/?topic=demo)
---
Available in: [en](https://centralcsp.com/en/pricing/), [fr](https://centralcsp.com/fr/pricing/)
```yaml
title: "Monitor every client site from one dashboard, for agencies"
description: "One dashboard for your whole client portfolio, with no agent to install on their sites. Portfolio pricing, alerts per client, resell it in your care plans."
url: "https://centralcsp.com/en/solutions/agencies/"
lang: "en"
```
For agencies
# Every client site. One security dashboard.
Monitor the scripts, policies and headers of your whole portfolio from one place, and turn client-side security into a service your clients pay for. EU-hosted.
[Start now](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
## Fifteen sites is fifteen attack surfaces
- No time to babysit
You ship sites weekly. Nobody on the team has hours to review raw violation reports per client.
- Clients want proof
"Are we secure?" deserves better than a shrug. You need something credible to show, in plain words.
- PCI landed on your desk
Your merchant clients forward the auditor's questionnaire to you. 6.4.3 and 11.6.1 are now your job.
For your portfolio
## Agency features, built in.
Everything you need to run security for a book of clients, included in one plan.
### Your whole portfolio, at a glance
Every client site on one screen: security score, report volume, open advisories. Green means move on. Red means you knew before the client did.
- Health and score per site
- CVE flags on client scripts
- Drill into any site in one click
[See portfolio monitoring](https://centralcsp.com/en/platform/monitoring/)
### Scoped to how agencies work
Access scoped per site, alerts routed per team. Your juniors see the sites they work on, not your whole book.
- Roles scoped per member and per site
- Team access without shared logins
- Alert channels per site
[See alert routing](https://centralcsp.com/en/platform/alerting/)
### Nothing to install
One response header per client site and reports flow from real visitor browsers.
- 12 report types, one endpoint
- Real production traffic
- Zero performance impact
[See how collection works](https://centralcsp.com/en/platform/monitoring/)
### CSP builder
Build and refine each client's policy from what their traffic actually loads.
- Generated from real reports
- Report-only first, enforce when clean
- Catches what a crawler misses
[See the CSP builder](https://centralcsp.com/en/platform/csp-builder/)
### PCI DSS evidence
Auditor-ready 6.4.3 and 11.6.1 evidence for every merchant client.
- Payment-page script inventory
- Justification workflow
- Auditor-ready exports
[See PCI DSS evidence](https://centralcsp.com/en/platform/pci-dss/)
### Supply-chain
Know every script your clients ship, and get flagged the moment one gains a CVE.
- Script SBOM per site
- Known-CVE detection
- New-script alerts
[See supply-chain protection](https://centralcsp.com/en/platform/supply-chain/)
How it works
## A new client takes five minutes
No agent, no SDK, no code changes on client sites. Browsers report natively.
1. 01 - Add
### Create the site in your dashboard.
Add each site, invite your team, set who sees what.
2. 02 - Connect
### Paste one response header.
Reports start flowing from real visitor browsers immediately. Zero performance impact.
3. 03 - Deliver
### Route alerts, share the evidence.
Send each client's incidents to the right channel and forward monthly proof that their site is watched.
The dashboard
## Everything happens in one place.
Reports, scores, alerts and evidence for every client site, behind one login.
- Every report type
- Enforced vs report-only
- Crashes and network errors too
- Deprecated APIs flagged early
250+
agency sites monitored
1.5B
reports ingested
82.5k
websites analyzed
Full
Reporting-API support
Pricing
## One subscription. A line item in every care plan.
Business covers your whole portfolio in one dashboard: automated scanning, API & MCP and alerting are all in the plan. Resell the monitoring to each client at your own rate.
- Every client site in one dashboard
- Automated scanning on every site
- Alerting, API and MCP included
- EU-hosted client data
Recommended
### Business
Automate it and wire it into your stack.
€129.99 / mo
- Applications 10
- Users 25
- Reports / month 2,000,000
Everything in Start, plus:
- Alerting to six channels
- Unlimited alerts
- API & MCP
[Get started](https://app.centralcsp.com/?plan=business&billing=monthly)
> With our workflow fully integrated, every website is wired to the right team, new scripts are detected automatically and tracked directly in each client's Slack channel. It has streamlined our entire process.
Operations manager, web agency
## Built to be resold
The client-facing layer is included: reports, alerts and exports you can hand straight to your clients.
### Each client alerted in their own channel
Add a channel per client, Slack, Teams, Google Chat, Telegram, email or webhook, then choose which events reach it. A new script origin on a checkout page lands with the people who own that site.
[Start now](https://app.centralcsp.com)
### Evidence you can forward
Payment-page script inventory and PCI DSS exports, ready to hand to the client.
### Scans and alerting included
Automated scanning and alerting on six channels ship with Business. CVE detection arrives with Scale.
### API and MCP
Pull anything into your own tooling and reports, or drive it with AI.
FAQ
## Frequently asked questions
Running client-side security for a portfolio, answered.
### How do I monitor CSP across multiple client websites?
Add each site to your CentralCSP dashboard and set one response header per site. Reports from real visitor browsers flow into one portfolio view, one row per site, with scores, inventories and alerts. No agent or code changes on client sites.
### Can I resell CentralCSP to my clients?
Yes. One subscription covers your portfolio, and you bill security monitoring inside your own care plans at your own price. Most agencies package it as a monthly add-on with the report as the deliverable.
### A client's auditor asked about PCI DSS 6.4.3 and 11.6.1. Can you handle it?
Yes. CentralCSP inventories the scripts on payment pages from real traffic, tracks justification, alerts on tampering, and exports auditor-ready evidence for both requirements.
### How is this different from a free CSP report collector?
A collector stores raw reports for one site. CentralCSP dedupes and classifies them across your whole portfolio, inventories scripts, flags known CVEs, alerts the right client channel and produces evidence you can forward. The difference is the hours you don't spend triaging.
### Where is my clients' data hosted?
In France, on OVH. It never leaves the EU.
## Put your portfolio under watch this afternoon.
Start with one client site, add the rest when you're convinced.
[Start now](https://app.centralcsp.com) [Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
---
Available in: [en](https://centralcsp.com/en/solutions/agencies/), [fr](https://centralcsp.com/fr/solutions/agencies/)
```yaml
title: "CSP reporting without an SDK, for developers"
description: "Add one response header, no SDK and no agent, then debug violations with source-level context: the file, the line and the script that actually tripped them."
url: "https://centralcsp.com/en/solutions/developers/"
lang: "en"
```
For developers
# Ship the site. Keep the browser under watch.
One response header collects CSP and browser security reports from your real traffic: violations to debug, alerts to act on. No agent, no SDK.
Audit my website
1.5B
reports ingested
12
report types collected
0
agents or SDKs to install
100%
EU data residency
The blind spot
## Your server tools stop at the response.
Third-party scripts, injected code and policy violations execute in the browser, after the page leaves your infrastructure. CentralCSP collects the signal browsers already emit and routes it back to your stack.
01 - Browsers
Native Reporting-API signals from your real production traffic.
- csp-violation
- deprecation
- intervention
- network-error
- crash
02 - Endpoint
Your managed reporting endpoint.
MyEndpoint.report.centralcsp.com
- Normalize and dedupe
- Classify by report type and origin
- Enrich with source context
- Score and inventory
03 - Your stack
The signal lands where you already work.
- Live dashboard
- REST API
- MCP server
### Real production traffic
Reports come from your actual visitors' browsers, not a crawler pointed at a staging URL.
### Source-level context
Every violation keeps its source file, line, column, directive, browser and origin.
### Zero runtime dependency
Nothing loads on your pages. Browsers report natively, so performance impact is zero.
Setup
## One header. That's the integration.
Ship it from the CDN, reverse proxy, framework or application layer, whichever you own.
response header
Reporting-Endpoints :
default= "https://MyEndpoint.report.centralcsp.com"
Have a CSP already? Point its report-to at the same endpoint and every violation lands there too.
1. ### Add your site
Create the site in your dashboard and copy its managed reporting endpoint.
2. ### Ship the header
Deploy from your edge or app. Reports flow from real visitor browsers immediately.
3. ### Route the signal
Watch the live dashboard, wire alerts to your channels, pull anything over the API.
Free tools
## Try the full security toolkit.
Every free tool, no account required. The same engines the platform runs on.
### CSP scanner
Map the headers, policy findings and reporting coverage of any public site.
- Full header inventory
- Findings ranked by severity
- Results on a shareable page
[Scan a site](https://centralcsp.com/en/tools/csp-scanner/)
### CSP evaluator
Paste a policy and get prioritized findings with a clear score.
- Directive-by-directive findings
- A clear overall score
- Powered by the platform engine
[Evaluate a policy](https://centralcsp.com/en/tools/csp-evaluator/)
### Reporting-API checker
See which reports a site actually collects, and where they are sent.
- Endpoint and binding checks
- Coverage per report type
- Dropped-report warnings
[Check your setup](https://centralcsp.com/en/tools/reporting-api/)
### Security headers scanner
Audit the response headers of any public site and see what's missing.
- Every header, graded
- Fixes for what's missing
- Rescan after you deploy
[Scan security headers](https://centralcsp.com/en/tools/security-headers/)
### Technology Checker
See the JavaScript libraries a page uses, their versions and the known CVEs affecting them.
- Versions and end-of-life status
- Known CVEs with the fixed version
- CycloneDX SBOM export
[Check a site's technologies](https://centralcsp.com/en/tools/tech-checker/)
### SRI hash calculator
Turn a CDN script or stylesheet URL into its Subresource Integrity hash.
- SHA-256, 384 and 512
- Ready-to-paste tag
- CORS verified for you
[Generate an SRI hash](https://centralcsp.com/en/tools/sri-hash/)
### CSP hash calculator
Hash an inline script or style so it runs under a strict policy.
- Hashes for inline scripts
- Runs entirely client-side
- Ready for script-src
[Generate a CSP hash](https://centralcsp.com/en/tools/csp-hash/)
### Security compare
Scan your site live and see how it ranks against your industry.
- Live scan of your site
- Industry cohort comparison
- Assess your maturity
[Compare your site](https://centralcsp.com/en/tools/compare/)
### Chrome extension
Watch live violations and build or test a policy against any page in your browser.
- Live violation feed
- Build and test policies in place
- Works on the page you're viewing
[Get the extension](https://centralcsp.com/en/tools/extension/)
The dashboard
## Everything happens in one place.
Reports, scores, inventories and evidence for every site you ship, behind one login.
- Trends across millions of reports
- Reports broken down by browser
- Millions of reports, aggregated
Automation
## Everything in the dashboard, over the API.
Reports, inventories, scores and evidence are all queryable. Automate site onboarding, export everything, or let your AI agents drive it over MCP.
- Full REST API with workspace API keys
- Webhooks, CSV and raw-report exports
- Built-in MCP server for AI agents
- Alerts to Slack, Teams or any webhook
[See the API and MCP platform](https://centralcsp.com/en/platform/api-mcp/)
Past the code review
## Answers for the rest of the room.
What compliance, security review and procurement will ask about, covered by the same platform.
1. 01 - Compliance
### PCI DSS evidence
If your checkout is in scope, requirements 6.4.3 and 11.6.1 are covered from the same signal.
2. 02 - Security review
### Enterprise controls
The controls your security review asks about, already in place. Data hosted in France, on OVH.
3. 03 - Access
### Team and access
Bring the whole team without sharing one login, and scope who sees what.
Pricing
## Priced for a side project. Built for production.
Start covers real collection on your first production site: every report type, the live dashboard and unlimited scans. Upgrade when you need automation.
- 12 report types, one header
- Unlimited scans
- Policy builder
- 14-day free trial
### Start
For a first production site.
€39.99 / mo
14-day free trial
- Applications 3
- Users 5
- Reports / month 250,000
Plan features
- Full Reporting-API support
- Unlimited scans
- Script inventory
- Team access and RBAC
- Policy builder
[Start free trial](https://app.centralcsp.com/?plan=start&billing=monthly)
The signal
## The reports you will read first.
One endpoint collects all twelve types. These are the three most developers open on day one.
- `csp-violation`
CSP violations
A resource was blocked, or would be blocked, by your Content Security Policy.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation)
- `csp-hash`
Script hashes
The hash of every script the page executes, the raw material for hash-based policies.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-hash)
- `network-error`
Network errors
DNS, TLS and connection failures your server never sees, logged by the browser itself.
[View docs](https://centralcsp.com/en/docs/web-security/reporting-api/reports/network-error)
[See all 12 browser report types](https://centralcsp.com/en/platform/monitoring/)
FAQ
## Frequently asked questions
Implementation, safety and automation, answered.
### How long does it take to connect a site?
One response header. Add it at your CDN, reverse proxy, framework, or application layer, and reports appear as real users browse. There is no JavaScript agent and no SDK to deploy.
### Can CentralCSP break my application?
No. Collecting reports changes nothing about how your pages behave. For CSP work, start with Content-Security-Policy-Report-Only, review real violations, and enforce only when the policy runs clean.
### Is this just a CSP report collector?
No. CentralCSP dedupes and classifies reports, keeps the raw JSON with source file, line and column, inventories scripts with integrity hashes, flags known CVEs, builds policy from production traffic, scores your posture, routes alerts, and exports audit evidence.
### Does it replace Sentry or a WAF?
No. Those tools cover application errors, network and server telemetry. CentralCSP covers the scripts, requests and policy violations that execute in your users' browsers, then feeds that signal back into the stack you already run.
### Can I use the data in my own automation?
Yes. Everything in the dashboard is available over the REST API, webhooks, and CSV, timeline and raw-report exports. AI agents can drive the platform over the built-in MCP server.
### Where is the data hosted?
In France, on OVH. It never leaves the EU.
## Add the header. See what the browser sees.
Start with one site and real production traffic. 14-day free trial, no agent to deploy.
[Start free trial](https://app.centralcsp.com) [Scan your site](https://centralcsp.com/en/tools/csp-scanner/)
---
Available in: [en](https://centralcsp.com/en/solutions/developers/), [fr](https://centralcsp.com/fr/solutions/developers/)
```yaml
title: "Pass the vendor security assessment: EU-hosted, SSO, RBAC"
description: "We answer your vendor questionnaire with you: data residency in France, SSO, RBAC and an audit log, with the evidence linked for your review."
url: "https://centralcsp.com/en/solutions/enterprise/"
lang: "en"
```
For enterprise
# Client-side security that passes the security review.
CentralCSP watches the Content Security Policy, scripts and browser reports of every site you run. EU-hosted, with SSO, RBAC and an audit log. When the questionnaire lands, we answer it with you.
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales) [See Enterprise pricing](https://centralcsp.com/en/pricing/)
- Data residency in the EU
France, on OVH
- Independent pentest
Scheduled end of 2026
- Status page
status.centralcsp.com
- Enterprise controls
SSO, RBAC, audit log
The vendor assessment
## Your questionnaire, answered before you send it.
These rows are on every security review spreadsheet we have seen. Here is where CentralCSP stands on each one, evidence linked.
| Requirement | Our answer | Status |
| --- | --- | --- |
| Single sign-on | SSO login ships with the Scale plan, so your team signs in through your identity provider. [Request SSO setup](https://centralcsp.com/en/contact/?topic=sso) | Answered |
| Role-based access | Scope each member to the sites and permissions they need. Juniors see their projects, not the whole estate. | Answered |
| Audit log | Account activity is logged: who changed what, and when. | Answered |
| Data residency | Hosted in France, on OVH. Report data never leaves the EU, so there are no transfer clauses to negotiate. | Answered |
| Penetration testing | An independent pentest is scheduled for the end of 2026. | Answered |
| Availability | Uptime and incidents are public, and an SLA is available as an Enterprise plan option. [status.centralcsp.com](https://status.centralcsp.com) | Answered |
| SLA | An SLA is available with the Enterprise plan. We discuss the terms and send the document when speaking with procurement. | Answered |
| Disaster recovery plan | A disaster recovery plan is in place. We walk through it and send the document when speaking with procurement. | Answered |
| Support | Priority support on the Enterprise plan, answered by the engineers who build the platform. | Answered |
| Scale | The platform already ingests billions of browser reports. | Answered |
| The vendor | A French company, founded by two security engineers. [Learn more about us](https://centralcsp.com/en/about/) | Answered |
| Paperwork | The DPA is public and ready for legal review. Send us the rest and we fill it in with you. [Read the DPA](https://centralcsp.com/en/legal/dpa/) | Answered |
Trusted by teams across the world
Integrations
## Integrates into the systems you already run.
CentralCSP is not another silo. Reports, scores and evidence flow out over the REST API, webhooks and MCP, straight into the tooling you already run.
- Full REST API with workspace API keys
- Built-in MCP server for AI agents
- Webhooks and CSV exports
[See the API and MCP platform](https://centralcsp.com/en/platform/api-mcp/)
### Sign in through your identity provider.
SSO login ships with the Scale plan and we set it up with you during onboarding. Joiners and leavers are handled where you already manage them, and every sign-in lands in the audit log.
- SSO login on the Scale plan
- Set up with you during onboarding
- Sign-ins recorded in the audit log
[Request SSO setup](https://centralcsp.com/en/contact/?topic=sso)
### One workspace. Scoped access.
Invite the whole security and platform team, no shared logins. Each member gets a role that scopes what they can view, configure or enforce, per site.
- Invite your team, no shared logins
- Roles scoped per member and per site
- No all-or-nothing admin access
### Every account action, on the record.
Sign-ins, role changes, policy edits: the audit log records who did what, and when. When the review asks how access is controlled, the answer is one screen away.
- Audit log of account activity
- Actor and timestamp on every event
- Evidence for access reviews
### Alerts where your teams already work.
Route each site's incidents to the channel that owns it. New script on the checkout? The payments squad's channel pings. No new inbox to watch.
- Alerts to Slack, Teams, Google Chat, Telegram or email
- Webhooks for anything custom
- Channels scoped per site and per team
Compliance paperwork
## Send us the questionnaire.
Security questionnaires, DPAs and vendor forms are part of buying software. We treat answering them as part of selling it.
1. 01 - Send
### Forward the paperwork.
The questionnaire, the vendor form, your DPA template. Whatever procurement handed you, pass it on.
2. 02 - Answer
### We fill it in with you.
Hosting, controls, data handling: we draft the answers, you review, we refine until your security team has what it needs.
3. 03 - Sign
### Close the review, start monitoring.
DPA signed, assessment filed. Your team gets back to watching what actually runs in your users' browsers.
## Get started now, deploy tomorrow.
An adjusted quote on custom quotas, plus the controls above, enabled for your workspace. Tell us the size of your estate and we come back with numbers.
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales)
- Custom quotas, adjusted pricing
- SSO and role-based access
- Audit log
- Optional SLA
- Priority support
- Data residency in the EU
FAQ
## Frequently asked questions
What security reviews ask us most, answered.
### Where is our data hosted?
In France, on OVH. It never leaves the EU, so EU entities need no international transfer mechanism. The details are in our DPA, which is public.
### Do you support SSO?
Yes. SSO login is part of the Scale plan. Tell us which identity provider you use and we set it up with you during onboarding.
### What does the SLA cover?
The SLA is an option of the Enterprise plan and is agreed as part of your quote, with scope and targets written into the contract. Our real availability is public at status.centralcsp.com either way.
### How often is CentralCSP pentested?
Annually, starting with our first independent pentest scheduled for the end of 2026. The report is not available yet; once the test completes we will publish it instead of gating it behind a sales call.
### How does the vendor assessment work in practice?
Send your security questionnaire or vendor form to our team. We fill it in with you, attach the supporting documents like the DPA, and iterate until your review has what it needs.
### Can we control what each team member can see and do?
Yes. Members are invited into one workspace and scoped by role and by site, and account activity lands in the audit log. No shared logins, no all-or-nothing admin access.
## Start the review with the answers in hand.
Talk to sales for an adjusted quote and the DPA. Pilot on one site while procurement runs its process.
[Talk to sales](https://centralcsp.com/en/contact/?topic=sales) [See pricing](https://centralcsp.com/en/pricing/)
---
Available in: [en](https://centralcsp.com/en/solutions/enterprise/), [fr](https://centralcsp.com/fr/solutions/enterprise/)
```yaml
title: "State of the Web 2026: client-side security report | CentralCSP"
description: "An anonymized census of client-side security across 761,345 domains: configuration quality averages 96.6 out of 100, security 29.2, and what to fix first."
url: "https://centralcsp.com/en/state-of-the-web/"
lang: "en"
```
Research
Published September 13, 2026 · 761,367 domains scanned
# State of the Web 2026
An annual, anonymized census of client-side security across the sites we scan. It measures how widely the protective HTTP response headers, Content-Security-Policy, the modern browser policies and the Reporting API are adopted, how well they are configured, which mistakes are most common, and which fixes matter most.
Every figure below is a population share over the 761,367 domains scanned for this edition. No figure names an individual site.
**The web keeps its configuration tidy and leaves it unsafe.** Configuration quality, how cleanly each header and policy is authored, averages 96.6 out of 100. Security, whether that configuration actually protects anyone, averages 29.2.
Those are two different axes, not two grades of one thing. A policy can be flawlessly authored and still wide open, and across three quarters of a million domains that is the normal case.
Security 29.2 /100
Quality 96.6 /100
761,367
Domains scored for this edition, each one with a GET request.
152,164
Content-Security-Policies collected and evaluated.
## Key findings
- **Almost nothing resists script injection.** 108 domains out of 761,367 pass, and 99.3% are exposed.
- **One site in five ships a Content-Security-Policy; 1.5% of those policies pass.** A passing CSP exists on 0.29% of all domains.
- **Nonces have not landed.** 5.3% of policies use one, against 38.1% that still allow `unsafe-inline`.
- **Reporting is a CDN artifact.** 33.7% of domains collect network-error reports because a CDN switched it on; 1.9% collect their own CSP violations.
- **The ceiling is reachable.** The best 150 domains average 92.4 out of 100, against a corpus average of 46.0.
## How does the web score overall?
Plot every domain by its overall score and the curve has one story to tell: it bunches in the middle and never climbs. Six in ten sites land in the 40-to-60 band, a third sit below it, and **93.4% score under 60** overall.
Both ends are nearly empty. Not one domain in the corpus scores below 20, but only **6.6% clear 60**, and the whole 80-to-100 band is 3,051 domains out of 761,367, four in every thousand.
That middle bulge is the two axes averaging out: near-perfect authoring dragged down by security that barely registers. A 46 is not half-protected. It is well-formed and open.
The waffle below puts the whole web in 100 squares, shaded by score band. Watch how little green there is: 33 red squares and 61 amber ones carry the whole population, and just 6 squares reach past 60.
0-20 0.0% (0) 20-40 32.7% (248,681) 40-60 60.7% (462,466) 60-80 6.2% (47,169) 80-100 0.4% (3,051)
0-20: 0.0% of domains. 20-40: 32.7% of domains. 40-60: 60.7% of domains. 60-80: 6.2% of domains. 80-100: 0.4% of domains.
Each square is about 1% of all 761,367 domains, shaded by its overall-score band.
That curve is the rest of the report in one shape. Before reading it header by header, here is how each score was built.
To place a single domain on that curve, [compare it against the same corpus](https://centralcsp.com/en/tools/compare/) with the scanner that produced these numbers.
## How we measured this
Each of the 761,367 domains received a single anonymous GET request over HTTPS, and only its response headers were analyzed. The assessment is **passive and non-intrusive**: no payloads, no fuzzing, no state-changing requests.
Every header, policy and directive is checked on **two separate 0-100 axes**: security, does it protect, and quality, is it cleanly authored. Those two combine into the overall score.
Presence is not safety. A header being delivered and parseable is not the same as it being correct, and quality is a different question from security rather than a softer version of it.
A tidy Content-Security-Policy that still allows `unsafe-inline` scores **high on quality and low on security**. That single example is the whole report in one line.
### How a domain is scored
We grade every header, directive, policy, reporting endpoint and attack concept on its own, from 0 to 100. Each one starts clean and loses points for the problems found on it, and the **single worst problem** sets its score.
How far a problem pulls a score down depends on its severity. Every finding lands in one of five levels, from an open hole to a gentle nudge:
Critical An open hole an attacker can use right now, such as running code on the page or taking over a session. Fix immediately.
High A serious gap that exposes credentials or data, or lets an attacker escalate. Fix urgently.
Medium A real weakness that thins the defenses against one specific attack. Worth fixing soon.
Low A minor issue with narrow or indirect impact. Tidy up during normal maintenance.
Info A quality nudge with no direct security impact. These shape the Quality score, never the Security one.
Those per-item scores roll up into the category and overall scores **by weight**, so the controls that matter most for security count most. A weak `script-src` moves the needle far more than a missing `Referrer-Policy`, and the same weighting folds the relevant headers, directives and policies into each attack-resistance score.
One rule does the heavy lifting at the bottom of the scale. A required control that is simply missing **scores 0** on that item, every time.
What separates a missing critical header from a missing minor one is not the score but **the weight it carries**. The mandatory one drags the total down hard; an optional one barely moves it.
### What this data can and cannot tell you
Every number here describes response headers at scan time, from one request, from one place on the network. That is a real limit and it cuts in both directions, so it is worth stating plainly before the findings.
**We under-count some protections.** A site that sets a policy only on authenticated pages, or that varies headers by route, is judged on the one response we saw. Controls that live in HTML rather than headers, such as a `meta`\-delivered policy on a page we did not fetch, are invisible to us.
**We also under-count some risks.** Header analysis cannot see whether a page loads an unpinned script, whether an inline handler bypasses the policy in practice, or whether a nonce is regenerated per response. A passing header is a floor, not a clean bill of health.
**The population is what we scan, not a ranked sample of the web.** It skews toward domains that resolve, answer on 443 and return a document, and it is not weighted by traffic. A figure here is a share of domains, never a share of page views.
One external check is worth having. The HTTP Archive's Web Almanac put CSP adoption at 21.9% of mobile home pages in 2025, measured on a different corpus with a different crawler; **we measure 19.4%** over a larger and broader population. Two independent crawls landing within two and a half points of each other is a reason to trust the shape of what follows.
Two axes, five severities, a weight on every control, and a stated limit on what a header can prove: that is the method. The sections that follow read its output, first the big attack classes, then header by header.
## How exposed is the web to the big client-side attacks?
Roll every relevant header, directive and policy into one resistance score per attack class and the web's defenses nearly vanish. **Three of the four vectors leave more than 97% of sites exposed.**
Full protection is a rounding error. Just 108 domains pass on script injection and 870 on data exfiltration; supply-chain tampering is stopped on a single domain in the entire corpus.
The one exception is clickjacking, where 7.1% pass and another third hold a partial defense, and only because the fix is one old, simple header. Even there, three sites in five are open.
Each ring below rolls the headers, directives and policies that defend against one attack class into a single test, then counts a domain as exposed when that defense is missing or too weak. The green slice is the strict bar: only a full pass counts as protected.
Corpus exposure
Protected 7.1% Partial 32.5% Exposed 60.5%
Corpus exposure
| Protected | 53,852 (7.1%) |
| Partial | 247,265 (32.5%) |
| Exposed | 460,250 (60.5%) |
Average resistance 35/100
### Clickjacking
Clickjacking loads your page inside an attacker's frame and tricks users into clicking controls they cannot see. One old header closes it: `X-Frame-Options`, or a CSP `frame-ancestors` directive.
The donut shows the catch: this is the best-defended vector, and it is still mostly open. Watch the green slice, the only one of the four big enough to read.
Because the fix is a single line copied around for years, this is the one vector where a real share of the web is protected. **About one site in 14 passes (7.1%)**, and a further third carries some defense (32.5%). The other 60.5% are exposed.
It sets the bar for what follows. The rest of the big client-side attacks need a whole maintained policy, and there almost no site measures up. Even clickjacking, the easy one, averages 35 out of 100 in resistance.
Corpus exposure
Protected 0.0% Partial 0.7% Exposed 99.3%
Corpus exposure
| Protected | 108 (0.0%) |
| Partial | 5,135 (0.7%) |
| Exposed | 756,124 (99.3%) |
Average resistance 3/100
### Script injection
The classic cross-site scripting attack: an attacker gets their own code to run inside your page, where it can read the DOM, lift session tokens and rewrite forms. The one thing that reliably contains it is a strict Content-Security-Policy, a nonce or hash based `script-src` with `strict-dynamic`, backed by Trusted Types or enforced Subresource Integrity, with the injection sinks (`base-uri`, `object-src`) locked down.
The donut is almost entirely red. A domain counts as exposed when that strict path is open, which is nearly everywhere.
Out of 761,367 domains, **108 pass**, and fewer than one site in 100 has even partial defense (0.7%). The average resistance score is 3 out of 100.
That is effectively the whole web failing the one test that matters most for the most common client-side attack.
Corpus exposure
Protected 0.0% Partial 2.3% Exposed 97.7%
Corpus exposure
| Protected | 1 (0.0%) |
| Partial | 17,579 (2.3%) |
| Exposed | 743,787 (97.7%) |
Average resistance 4/100
### Supply-chain tampering
Most pages pull in third-party scripts from vendors and CDNs. If one of those scripts is altered upstream, the modified code runs in your page with full access. This is the pattern behind Magecart card-skimming.
Subresource Integrity, required through an `Integrity-Policy` header or `require-sri-for`, is what catches a script that changed behind your back. A domain counts as exposed when integrity is not enforced and scripts are trusted by origin alone.
The stat collapses to a single number because protection here is too rare to draw. **Exactly one domain in the whole corpus passes**, a further 2.4% hold a partial defense, and the average resistance is 4 out of 100 against 97.7% exposed.
A single compromised dependency would run unchecked almost everywhere.
Corpus exposure
Protected 0.1% Partial 1.3% Exposed 98.6%
Corpus exposure
| Protected | 870 (0.1%) |
| Partial | 9,673 (1.3%) |
| Exposed | 750,824 (98.6%) |
Average resistance 50/100
### Cross-origin data exfiltration
Once a script runs on your page, the next question is where it can send what it reads. A CSP that pins `connect-src`, `img-src` and `form-action` to known hosts boxes in the outbound channels: fetch, image beacons and form posts.
A domain counts as exposed when those channels are open, so an injected script could quietly ship form data and tokens to any origin it likes.
**870 of 761,367 domains pass** and 98.6% are exposed. The partial defenses come from the 1.3% of sites that pin some channels but not all.
This vector carries the highest average resistance of the four, 50 out of 100, and that number needs reading with care. It is **partial credit, not safety**: a policy that pins images but leaves `connect-src` open scores well and stops nothing.
Across all four classes the verdict is the same. **Full protection is a rounding error everywhere**, the one vector with real protection owes it to a single legacy header, and the resistance averages are propped up by partial defenses rather than by anyone closing the gap. The next section steps back from the attacks to ask which protective headers the web actually sends.
## Which protective headers does the web actually send?
Rank the protective response headers by how many sites send them and you get a staircase down from the automatic to the deliberate. `Cache-Control` tops it at 66.2%, and it is there because performance tooling sets it rather than because anyone chose it.
The security headers proper sit in the middle, each on **roughly two in five sites**: `X-Content-Type-Options` at 39.9%, `X-Frame-Options` at 37.3%, `Strict-Transport-Security` at 34.0%. The cross-origin headers, which take real thought, fall to 1.2% at the bottom.
Adoption is only half the story. For most active headers, the sites that send them pass our checks: `X-Content-Type-Options` passes on **99.9% of its senders** and `X-Frame-Options` on 98.6%. `Cross-Origin-Resource-Policy` is the exception: only **57.6% of its senders pass**. More than four in ten set it to `cross-origin`, which grants exactly what sending no header at all grants, so the header is present and the protection is not.
These headers are near-binary switches, though. Passing them is easy, so the real signal is how few sites send them at all. `Referrer-Policy` passes on 86.7% of its senders, `Cache-Control` on 86.8%.
One header breaks the pattern. A third of all sites send `Strict-Transport-Security`, but **barely one sender in five sends it correctly**: 22.1% of HSTS senders pass, while the rest ship a short `max-age` or skip `includeSubDomains` and `preload`. A further 8,380 sites send it with `max-age=0`, which switches the protection off outright.
That gap is the whole story of this section. Counted against the entire corpus, fully correct HSTS reaches just **one site in 13 (7.5%)**. It is the one broadly adopted header where adoption and correctness come apart.
The first table below is that staircase: each active header by adoption and by how its senders score. The second lists the retired headers still in the wild, where sending them is the problem.
The same checks run on demand: [test the headers your own site sends](https://centralcsp.com/en/tools/security-headers/).
Protective response headers
Share of all 761,367 scored domains that send each header, and how the senders score.
| Header | Adoption | Pass Partial Failed |
| --- | --- | --- |
| Cache-Control | 66.2% | 86.8 / 0.0 / 13.2 |
| X-Content-Type-Options | 39.9% | 99.9 / 0.0 / 0.1 |
| X-Frame-Options | 37.3% | 98.6 / 1.4 / 0.0 |
| Strict-Transport-Security | 34.0% | 22.1 / 52.9 / 25.0 |
| Referrer-Policy | 26.4% | 86.7 / 0.0 / 13.3 |
| Cross-Origin-Resource-Policy | 1.2% | 57.6 / 42.4 / 0.0 |
How widely each protective response header is sent, ranked by adoption.
Retired headers
Headers the platform has dropped, ranked by how many domains still send them.
| Header | Why it was retired | Still sent by |
| --- | --- | --- |
| X-XSS-Protection | Drove the XSS auditor every browser has since removed; only 0 is safe. | 18.6% |
| Expect-CT | Certificate Transparency reporting, redundant since CT became mandatory. | 1.0% |
| Feature-Policy | Renamed and replaced by Permissions-Policy. | 0.7% |
| Public-Key-Pins | One wrong pin could lock users out of the site; replaced by Certificate Transparency. | 0.0% |
Headers browsers have retired, why each was dropped, and how many domains still send them.
### The header that makes browsers less safe
Most missing headers cost you protection. One header **costs you protection by being there**. `X-XSS-Protection` drove a browser feature, the XSS auditor, that every modern engine has since removed.
Turning it on (`1` or `1; mode=block`) created the very cross-site information leaks it was meant to stop. The only safe value left is `0`, which switches the dead feature off.
Yet **nearly a fifth of the web still sends the header** (18.6%, 141,522 sites). For these sites adoption is the regression: the fix is to delete the header, not configure it.
Worse, **more than nine in ten of those senders use the unsafe enabled value** (91.0%, 128,730 sites), the exact mode that was the reason browsers killed the feature.
The two tiles below read inverted. Presence is the failure, so adoption shows in amber, and the second tile is the share of senders stuck on the unsafe value.
18.6%
still send X-XSS-Protection
141,522 of 761,367 domains keep a header every current browser has removed.
91.0%
of those use the unsafe value
128,730 domains leave the filter on (1 or 1; mode=block), the mode that opened cross-site information leaks. The safe value is 0.
How many domains still send X-XSS-Protection, and how many of those use the unsafe enabled value.
### What your headers give away
Headers protect, but they also disclose. By default a lot of stacks announce themselves in the response: `Server`, `X-Powered-By` and their kin name the software, and often the exact version, running behind the site.
None of this is required to serve a page, and all of it shortens an attacker's work. Naming the technology narrows the search; naming the version turns the header into a direct lookup against published vulnerabilities for that release.
**Roughly two in five sites name their stack** (39.4%), and over half of those print the version too (56.1% of the disclosers), leaving about one site in five exposing the exact release it runs (22.1% of the whole corpus).
The two tiles below split that disclosure: the share of all sites that name their technology, and the narrower share that also leak the version.
39.4%
name their technology in a header
300,232 domains advertise what they run through Server, X-Powered-By and similar headers.
22.1%
also expose the exact version
168,527 domains add the version number too, turning a banner into a ready-made lookup of known vulnerabilities.
Across the whole corpus, how many domains disclose their technology in a header, and how many also expose its version.
### How safe are the cookies the web sets?
A cookie carries the session, so its flags decide how easily that session can be stolen or sent where it should not go. Three attributes do the work: `Secure` keeps the cookie off plaintext connections, `HttpOnly` hides it from JavaScript and so from an injected script, and `SameSite` controls whether it rides along on cross-site requests.
This figure counts cookies rather than sites. Across the 672,987 cookies in the corpus, about half carry each protective flag: `Secure` on 54.3%, `HttpOnly` on 49.6%, `SameSite` on 45.5%. **Fewer than half declare `SameSite` at all.**
The `SameSite` value is the sharper twist. Of the cookies that set it, `Lax` is the plurality at 48.8%, but `None`, the value that opts back out of cross-site protection, sits right behind it at 45.7%, and `Strict` is a rounding error at 5.4%.
So the hardened-cookie choice is close to a coin flip between the safe default and the opt-out. Counted against every cookie in the corpus, `None` still lands on about one in five (20.8%), while `Strict` stays negligible.
The table below shows the share of cookies using each flag, and the donut below it breaks down the `SameSite` value among those that set one.
Cookie protections
Share of the 672,987 cookies in the corpus that set each attribute.
| Attribute | What it does | Adoption | Cookies |
| --- | --- | --- | --- |
| Secure | Only sent over HTTPS, never on a plain connection. | 54.3% | 365,248 |
| HttpOnly | Hidden from JavaScript, so an injected script cannot read it. | 49.6% | 333,599 |
| SameSite | Limits when the cookie rides along on cross-site requests. | 45.5% | 305,897 |
SameSite value, when set
None 45.8% Lax 48.8% Strict 5.4%
SameSite value, when set
| None | 139,940 (45.8%) |
| Lax | 149,181 (48.8%) |
| Strict | 16,612 (5.4%) |
Of the cookies in the corpus, the share setting each protective attribute, and the SameSite value chosen by those that set one.
Across all four figures the same fault repeats: a header sent is not a header set correctly. The easy headers are nearly perfect; **the load-bearing ones are not**. Where the value carries real security weight, HSTS, `SameSite` and the leftover retired headers show how often the choice works against the site.
That leads straight into the one control built to contain script injection, and how the web builds it.
## How is Content-Security-Policy actually built?
Content-Security-Policy is the one control on the web that reliably contains script injection once it happens. About one site in five sends one, and almost none of those send a safe one.
The four donuts below frame the whole problem: how many domains ship a CSP, how those policies score on security, how they are delivered, and whether they enforce or only watch.
Adoption
Ships a CSP 19.4% No CSP 80.6%
Adoption
| Ships a CSP | 148,000 (19.4%) |
| No CSP | 613,367 (80.6%) |
Security outcome
Pass 1.5% Partial 7.1% Failed 91.4%
Security outcome
| Pass | 2,251 (1.5%) |
| Partial | 10,446 (7.1%) |
| Failed | 135,303 (91.4%) |
Delivery method
Header 96.0% Both 1.2% Meta tag 2.7%
Delivery method
| Header | 146,113 (96.0%) |
| Both | 1,887 (1.2%) |
| Meta tag | 4,164 (2.7%) |
Mode
Enforced 89.5% Both 2.7% Report-only 7.8%
Mode
| Enforced | 132,467 (89.5%) |
| Both | 3,977 (2.7%) |
| Report-only | 11,556 (7.8%) |
How many domains ship a Content-Security-Policy, how those policies score, and how they are delivered and enforced.
Adoption is the easy half. **19.4% of the web ships a CSP** (148,000 of 761,367 domains), and those policies are clean: they average 98 out of 100 on quality.
Then the security check runs and the floor drops out. Of the policies we evaluate, **91.4% fail** (135,303 sites) and only 1.5% pass (2,251 sites).
The same policies that score 98 on clean authoring average **29 on security**. Clean, and useless.
These are real policies, not experiments. Almost all run in enforce mode rather than report-only (89.5%), and **96.0% arrive in a header**, with only 2.7% relying on a meta tag alone. The header is present; the protection is not.
At corpus scale, a passing CSP exists on **0.29% of all domains**. Fewer than three sites in a thousand have the control that would contain the most common client-side attack.
The gap between authoring quality and security is what a policy written by hand looks like. [Building one from real browser reports](https://centralcsp.com/en/platform/csp-builder/) closes it, because the directives come from what your visitors actually load.
### Which directives do policies set, and how well?
A Content-Security-Policy is a list of directives, and they do not carry equal weight. Sites get the cheap ones right and the dangerous ones wrong.
`frame-ancestors` leads adoption at 54.9% of CSP sites and passes 76.9% of the time, because it does one narrow job. `script-src`, the directive that actually gates injected scripts, appears on 40.5% of CSP sites and **fails 89.1% of the time** (45,390 of 50,916 uses).
That pattern holds down the table. The directives that constrain scripts and styles fail hardest (`style-src` passes 9.3% of the time, `script-src-elem` 2.7%), while the structural ones pass easily: `base-uri` passes 91.6%, and `upgrade-insecure-requests` passes everywhere it appears.
**The hard part of CSP is the two or three directives that actually contain an attack**, not the act of listing them. The modern hardening directives barely register at the bottom of the table: `require-trusted-types-for` appears on 285 CSP sites, `trusted-types` on 166.
The table below ranks every canonical directive by how often it appears, then scores each one: of the times it is used, how many pass, partially pass, or fail. Watch the gap between the high-usage `*-src` directives and their failure rates.
CSP directives
Share of the 152,164 CSP-delivering domains that set each directive, and how those uses score.
| Directive | Used | Pass Partial Failed |
| --- | --- | --- |
| frame-ancestors | 54.9% | 76.9 / 13.5 / 9.6 |
| default-src | 41.8% | 53.0 / 2.4 / 44.6 |
| script-src | 40.5% | 6.4 / 4.4 / 89.1 |
| img-src | 37.9% | 17.2 / 3.0 / 79.8 |
| style-src | 34.8% | 9.3 / 49.6 / 41.2 |
| font-src | 34.4% | 71.6 / 4.8 / 23.6 |
| connect-src | 34.2% | 17.7 / 1.1 / 81.1 |
| upgrade-insecure-requests | 33.2% | 100.0 / 0.0 / 0.0 |
| frame-src | 30.6% | 26.4 / 15.1 / 58.5 |
| object-src | 28.4% | 76.5 / 0.0 / 23.5 |
| base-uri | 26.3% | 91.6 / 0.0 / 8.4 |
| form-action | 19.4% | 68.1 / 5.0 / 27.0 |
| media-src | 17.8% | 64.2 / 4.1 / 31.7 |
| worker-src | 14.9% | 63.0 / 1.0 / 36.0 |
| child-src | 8.2% | 0.0 / 49.2 / 50.8 |
| report-uri | 7.8% | 99.1 / 0.8 / 0.1 |
| manifest-src | 7.3% | 74.3 / 18.8 / 6.8 |
| block-all-mixed-content | 4.2% | 0.0 / 100.0 / 0.0 |
| script-src-elem | 3.3% | 2.7 / 4.7 / 92.6 |
| report-to | 3.0% | 99.6 / 0.2 / 0.2 |
| style-src-elem | 2.1% | 10.6 / 45.2 / 44.3 |
| script-src-attr | 2.0% | 48.0 / 2.4 / 49.7 |
| style-src-attr | 1.3% | 7.7 / 87.1 / 5.1 |
| require-trusted-types-for | 0.2% | 99.3 / 0.7 / 0.0 |
| prefetch-src | 0.1% | 0.0 / 80.7 / 19.3 |
| sandbox | 0.1% | 4.1 / 2.6 / 93.4 |
| trusted-types | 0.1% | 30.1 / 62.0 / 7.8 |
| fenced-frame-src | 0.0% | 0.0 / 70.0 / 30.0 |
| navigate-to | 0.0% | 0.0 / 96.4 / 3.6 |
| plugin-types | 0.0% | 0.0 / 100.0 / 0.0 |
| referrer | 0.0% | 0.0 / 100.0 / 0.0 |
| reflected-xss | 0.0% | 0.0 / 100.0 / 0.0 |
| require-sri-for | 0.0% | 0.0 / 100.0 / 0.0 |
| webrtc | 0.0% | 0.0 / 100.0 / 0.0 |
How often each CSP directive appears in policies, and how well those uses score.
### What hardens a policy, and what weakens it
Whether a policy protects comes down to the keywords inside it, and CSP authors reach for the wrong ones. The weakening keywords **outnumber the hardening ones by a wide margin**.
`unsafe-inline` shows up on 38.1% of CSP sites and `unsafe-eval` on 33.0%. Nonces, the headline hardening mechanism, reach **5.3%**. Roughly seven times as many policies allow inline scripts outright as lock them down with a nonce.
It gets worse below the headline. `strict-dynamic`, the keyword that makes a nonce-based policy genuinely hard to bypass, sits on **2.5% of CSP sites** (3,853 policies). Trusted Types, the strongest DOM-injection defense the platform offers, is enforced on 348.
The weakening list also runs deeper than the two famous keywords. More than one policy in five allows a known JSONP endpoint (22.1%) or a known script gadget (21.2%), both of which hand an attacker a way around an otherwise reasonable allowlist.
The two tables below split the mechanisms that harden a policy from the ones that weaken it, each as a share of CSP-delivering sites. Read them as a pair: the green column is short, the red column is not.
Hardening mechanism
Share of the 152,164 CSP-delivering domains.
| Hardening mechanism | Domains | Hardening |
| --- | --- | --- |
| upgrade-insecure-requests | 50.5k | 33.2% |
| Nonces | 8k | 5.3% |
| strict-dynamic | 3.9k | 2.5% |
| Hashes | 2.9k | 1.9% |
| Trusted Types (enforced) | 348 | 0.2% |
| Trusted Types (declared) | 203 | 0.1% |
The mechanisms that strengthen a policy, each as a share of CSP-delivering domains.
Weakening mechanism
Share of the 152,164 CSP-delivering domains.
| Weakening mechanism | Domains | Weakening |
| --- | --- | --- |
| unsafe-inline | 58k | 38.1% |
| unsafe-eval | 50.3k | 33.0% |
| JSONP endpoint | 33.6k | 22.1% |
| Script gadget | 32.2k | 21.2% |
| Subdomain wildcard | 28.1k | 18.4% |
| Scheme source | 27.3k | 17.9% |
| Shared host | 17.7k | 11.7% |
| Full wildcard \* | 5.6k | 3.7% |
| wasm-unsafe-eval | 1.9k | 1.2% |
| unsafe-hashes | 842 | 0.6% |
The mechanisms that weaken a policy, each as a share of CSP-delivering domains.
### What goes wrong in the policies that exist?
Even where policies are messy, the mess is mostly harmless. **The most common authoring mistake reaches 8.1% of CSP sites**, and it is a source value listed twice in the same directive.
Below it the list stays in single digits: a keyword used in a directive that ignores it (6.2%), a source already covered by a broader one (6.1%), a deprecated directive copied from an old template (4.3%). These are hygiene problems, not holes.
The ones with real teeth are rare, which is exactly why they survive. About one CSP site in 89 writes a keyword without its quotes (1.1%), so `unsafe-inline` or `self` is parsed as a hostname and the directive quietly means something the author never wrote.
**CSP gives authors almost no feedback**, so these mistakes are never caught. Nothing in a browser tells you that your policy parsed into something you did not write.
The table below ranks the ten most common authoring mistakes by how many CSP sites they hit, as a share of CSP-delivering sites.
CSP authoring mistakes
Share of the 152,164 CSP-delivering domains hit by each mistake.
| Authoring mistake | Domains | Share of CSP sites |
| --- | --- | --- |
| Duplicate value in a directive | 12.3k | 8.1% |
| Keyword not valid in that directive | 9.4k | 6.2% |
| Source already covered by a broader one | 9.2k | 6.1% |
| Deprecated directive | 6.5k | 4.3% |
| Source value with no effect | 3.9k | 2.6% |
| Multiple CSP headers | 3.7k | 2.5% |
| Directive allows localhost | 2.9k | 1.9% |
| Policy sent in both a meta tag and a header | 1.9k | 1.2% |
| Keyword missing its quotes | 1.7k | 1.1% |
| Unknown directive | 1.2k | 0.8% |
The most common authoring mistakes in the policies that exist, by how many CSP sites they hit.
CSP adoption is real, but a present header is not a working defense. **Nine policies in ten fail**, and the directives that stop script injection are exactly the ones authors get wrong. The next section steps back from CSP to ask how the other modern policies are deployed.
## How widely are the other policies deployed?
The most-deployed policy on the web is not a security control. Network Error Logging reaches **33.7% of domains**, ahead of Content-Security-Policy at 19.4%, and it gets there because CDNs switch it on rather than because operators chose it.
Below CSP the modern headers thin out fast. COOP reaches 9.8% and Permissions-Policy 9.1%, roughly one site in eleven. COEP, the second half of cross-origin isolation, lands on **0.6% of sites**.
Because true isolation requires both COOP and COEP, that COEP figure is the real ceiling no matter how many sites set COOP alone. COEP is the scarcer of the pair by a factor of seventeen, so **almost every COOP deployment cannot reach isolation** at all.
The genuinely new policies barely register. Document-Policy sits at 0.1% (720 domains), while Integrity-Policy and Connection-Allowlist are a literal handful, **16 domains and 6**. These are shipped browser features with essentially no field adoption, a frontier worth naming so next year has a baseline.
The table below ranks each policy by the share of the corpus that deploys it, then splits each one by mode: enforce, both, or report-only. Notice that report-only is all but abandoned; every widely-set policy is **enforced from day one**.
Modern policy adoption
Share of all 761,367 scored domains that deploy each policy.
| Policy | Deployed | Enforced Both Report-only |
| --- | --- | --- |
| Network Error Logging | 33.7% | 100.0 / 0.0 / 0.0 |
| Content-Security-Policy | 19.4% | 89.5 / 2.7 / 7.8 |
| Cross-Origin-Opener-Policy | 9.8% | 98.7 / 1.1 / 0.2 |
| Permissions-Policy | 9.2% | 100.0 / 0.0 / 0.0 |
| Cross-Origin-Embedder-Policy | 0.6% | 76.8 / 19.2 / 4.0 |
| Document-Policy | 0.1% | 99.4 / 0.1 / 0.4 |
| Connection-Allowlist | 0.0% | 20.0 / 0.0 / 80.0 |
| Integrity-Policy | 0.0% | 31.3 / 0.0 / 68.8 |
How widely each modern policy is deployed, and for each one whether its deployers enforce it, run both modes, or only monitor it.
Deployment is only half the picture. The chart below shows, of the sites that deploy each policy, how many pass our security checks, land in partial, or fail outright, sorted so the worst failure rate sits on the left.
One bar stands apart. **CSP fails on 91.4% of the policies that get evaluated** and passes on 1.5%. Every other widely deployed policy passes almost every time it is set: Permissions-Policy at 100%, NEL at 100%, COOP at 90.9%.
COEP is the interesting middle case. It passes on only 19.9% of its deployers, with the other 80.1% landing in partial, because setting COEP without the COOP value that completes isolation gets you a header and not the guarantee.
Part of the CSP gap is what the policy can express. CSP is graded on a hard rubric, a rich allowlist that can be present yet insecure. The others are close to binary, where present and well-formed is a pass, so the contrast **measures the difficulty of the policy** as much as the operator's skill.
Read the smallest bars with care. The Document-Policy, Integrity-Policy and Connection-Allowlist rates rest on a few deployers each, not a population, so their bars are **anecdotes, not trends**.
Pass Partial Failed
Policy health
| Policy | Pass | Partial | Failed |
| --- | --- | --- | --- |
| CSP | 1.5% | 7.1% | 91.4% |
| NEL | 100% | 0% | 0% |
| COOP | 90.9% | 9.1% | 0% |
| Permissions | 100% | 0% | 0% |
| COEP | 19.9% | 80.1% | 0% |
| Document | 98.6% | 1.4% | 0% |
| Connection | 100% | 0% | 0% |
| Integrity | 40% | 60% | 0% |
Of the sites that deploy and can be evaluated for each policy, how many pass, partially pass, or fail our security checks. Bars are sorted by failure rate.
CSP is the one widely deployed policy that mostly fails. **A fifth of the web reaches for it**, keeps it clean enough to enforce, and still leaves it open. The next section asks who can even see those failures when they happen.
## Can anyone actually see the violations?
On paper, about **a third of the web** is wired up to report problems back to its operators. Almost all of that is network-error logging, switched on automatically by CDNs rather than chosen by any site owner.
Strip the auto-enabled logging out and the deliberate signal is small. Network Error Logging is set up on 256,658 domains; every other report type a site would actually choose adds up to **19,907 domains** between them.
The report that matters most is the rarest of the common ones. **1.9% of the corpus** collects its own Content-Security-Policy violations: 14,197 domains, the only feedback that tells you your policy is breaking real pages.
Reporting is also the rare place where setup and delivery come apart, and the newer policies are where it breaks. Of the 1,112 domains that wire up COOP reporting, **81.3% have it broken**, and COEP reporting is broken on 92.4% of the 1,005 that try.
CSP reporting is in better shape: 97.5% of the domains that set it up receive reports. **The web is not watching its own violations, and where it tries on the newer policies it usually misconfigures the endpoint.**
What counts as broken is worth stating precisely. A row is broken only when the policy **names a destination the browser cannot deliver to**; a policy that quietly falls back to the default group and finds nothing there is counted as not set up, never as broken.
That distinction is what sinks COOP and COEP. Neither can name a URL: both point at a `report-to` group that has to be declared separately in a `Reporting-Endpoints` header, so the ordinary failure is a line copied from a guide with its `report-to="coop"` intact and no group ever declared behind it.
**CSP escapes most of this** because `report-uri` names a URL inline, with no second header to forget. The gap between 97.5% working for CSP and 7.6% for COEP is largely that one design difference, not a difference in how carefully the two were set up.
The table below ranks each report type by the share of the corpus that sets it up, then splits each row into working and broken endpoints. Two denominators sit side by side: the set-up share is of the whole corpus, but the working-versus-broken split is of that row's own set-up count.
Report collection
Set-up share is of all 761,367 domains; working and broken split each row's own set-up count.
| Report type | Set up to report | Working Broken |
| --- | --- | --- |
| Network error | 33.7% | 100.0 / 0.0 |
| CSP violation | 1.9% | 97.5 / 2.5 |
| COOP report | 0.1% | 18.7 / 81.3 |
| Crash | 0.1% | 96.8 / 3.2 |
| Deprecation | 0.1% | 96.8 / 3.2 |
| Intervention | 0.1% | 96.8 / 3.2 |
| COEP violation | 0.1% | 7.6 / 92.4 |
| Permissions-Policy violation | 0.1% | 99.2 / 0.8 |
| CSP script-hash report | 0.0% | 95.2 / 4.8 |
| Integrity violation | 0.0% | 92.3 / 7.7 |
| Document-Policy violation | 0.0% | 77.8 / 22.2 |
| Connection-Allowlist | 0.0% | 100.0 / 0.0 |
Each report type by the share of the corpus that sets it up. The working and broken columns split each row's own set-up count, not the corpus.
### Report-To or Reporting-Endpoints?
There are two ways to tell a browser where to send reports. `Reporting-Endpoints` is the current standard; `Report-To` is the older header it replaced and is now deprecated.
The donut below looks only at the sites that declare either header, and the balance is lopsided. Of those sites, **98.1% still use the deprecated `Report-To`**, and 1.9% have moved to the modern header.
That deprecated slice is the same CDN plumbing already counted above. `Report-To` sits on 34.1% of the corpus, near enough the same share as network-error logging, because they are **one CDN-injected mechanism** rather than a choice made site by site.
The modern `Reporting-Endpoints` has barely landed: 5,065 sites, 0.7% of the corpus, roughly one site in 151.
Wiring it up is one response header, and [collecting what browsers send back](https://centralcsp.com/en/platform/monitoring/) is where the numbers in this section come from.
Domains declaring a reporting header
Reporting-Endpoints 1.9% Report-To (deprecated) 98.1%
Domains declaring a reporting header
| Reporting-Endpoints | 5,065 (1.9%) |
| Report-To (deprecated) | 259,388 (98.1%) |
Of the domains that declare a reporting-destination header, the split between the modern Reporting-Endpoints and the deprecated Report-To.
The web cannot see what it does not watch. Outside the logging CDNs switch on for it, **deliberate reporting barely registers**, and on the newest policies most of the sites that try get the endpoint wrong. The next section turns from diagnosis to prescription.
## What should you fix first?
157 distinct findings is not a plan. Weight each one by how much damage it does and how many sites it reaches, and a short priority list falls out.
The three highest-severity recommendations all reduce to one sentence: ship a real CSP. The script-injection (99.2%), supply-chain (98.9%) and data-exfiltration (98.6%) findings each reach **roughly 99% of sites**.
All three are the same condition wearing three hats. A page with no real CSP restricts nothing, so it fails all three at once. That makes the highest-leverage move on the web also the most basic: **deploy a policy, then tighten it**.
Below those headline findings the list changes character. The fixes for sites that already have a CSP but weakened it reach far fewer domains: **about one site in seven** leaves `connect-src` open enough to exfiltrate freely (15.1%), and 7.4% still allow `unsafe-inline` in `script-src`.
After that come the cheap missing-header recommendations that reach almost everyone but rarely raise the stakes, and finally the emerging policies almost no one ships.
One thing is worth stating because of what it is not. **The catalogue contains no critical findings this year.** Nothing in the corpus fires our top severity, and the damage is carried entirely by 21 high-severity findings, three of which reach nearly every site on the web.
The table below ranks the top recommendations by relevance, damage times reach, so the most damaging and most widespread fixes sit first.
Priority recommendations
The 157 findings in the catalog, weighted by severity and reach, over all 761,367 domains.
| Priority | Recommendation | Severity | Domains | Share of corpus |
| --- | --- | --- | --- | --- |
| Do now | Add a strict nonce-based script-src with 'strict-dynamic'. | High | 755.1k | 99.2% |
| Do now | Add an Integrity-Policy header to require SRI for scripts. | High | 752.9k | 98.9% |
| Do now | Set connect-src to 'self' and your known hosts. | High | 750.7k | 98.6% |
| Fix your CSP | Restrict connect-src to 'self' and your API/analytics hosts. | High | 114.6k | 15.1% |
| Fix your CSP | Drop 'unsafe-inline'; use a nonce with 'strict-dynamic'. | High | 56.6k | 7.4% |
| Fix your CSP | Remove 'unsafe-eval' from the directive. | High | 50.3k | 6.6% |
| Fix your CSP | Remove the dangerous scheme from the directive. | High | 33.8k | 4.4% |
| Fix your CSP | Remove the JSONP host from the directive. | High | 32.8k | 4.3% |
| Fix your CSP | Remove the script gadget host from the directive. | High | 31.6k | 4.1% |
| Fix your CSP | Replace the shared host with a dedicated one you control. | High | 17.6k | 2.3% |
| Fix your CSP | Move the CSP to the enforced header. | High | 11.5k | 1.5% |
| Fix your CSP | Remove the scheme source from the directive. | High | 10.9k | 1.4% |
| Do now | Replace max-age=0 with max-age=31536000. | High | 8.4k | 1.1% |
| Fix your CSP | Replace default-src \* with 'self'/'none' and set per-directive sources. | High | 4.7k | 0.6% |
| Fix your CSP | Replace the wildcard in the directive with a nonce policy. | High | 3.5k | 0.5% |
| Fix your CSP | Generate a fresh nonce for every response. | High | 1.4k | 0.2% |
| Recommended | Add a Permissions-Policy header disabling unused features. | Medium | 691.2k | 90.8% |
| Fix your CSP | Add a strict nonce-based Content-Security-Policy. | Medium | 609.2k | 80.0% |
| Recommended | Add a NEL header with a report\_to group declared in Report-To. | Medium | 504.7k | 66.3% |
| Recommended | Declare a Reporting-Endpoints group and reference it. | Medium | 499.7k | 65.6% |
157 findings weighted by severity and reach, the highest-leverage fixes first.
The whole catalogue collapses to one priority: **get a real CSP in place**, then close the directives that weaken the policies that already exist. Everything else is the long tail. The next section steps back from the failures to ask what the best-configured sites do differently.
## How far apart are the best and the rest?
A small elite proves a near-perfect score is reachable. The best 150 domains average **92.4 out of 100**; the whole corpus of 761,367 averages 46.0. That is a 46.4-point gap, as large again as the typical score.
Split that gap by axis and it turns out to be one axis. On quality the two populations are almost indistinguishable: **97.5 for the best cohort against 96.6 for everyone else**, less than a point apart.
On security they are not the same web. The best cohort averages **90.9 out of 100** against the corpus average of 29.2, a chasm of 61.5 points. The entire distance between the two populations sits on that one axis.
So the elite are not tidier than everyone else. They are **protected**, and everyone else is not, while both keep their configuration in much the same order.
The three cards below compare the best-configured cohort against the whole corpus on the overall score. The section that follows breaks that one number down area by area.
Best cohort average 92.4 /100
Corpus average 46.0 /100
The gap +46.4 pts
The best-configured 150 domains against all 761,367, on the overall 0-100 score.
### Where the best pull ahead, area by area
The cards above compare the two populations on one number; these radars show where the difference actually sits. Each one sets the best-configured cohort of 150 sites against the average across all 761,367 domains, every spoke a 0-100 sub-score.
The two series are not the same size. Green is **fewer than 1 site in 5,000**. Amber is the whole web, the real baseline.
The same shape repeats in every panel: a green ring pushed out near the rim, sitting on a collapsed amber core. The gap is categorical, not incremental.
On CSP the best cohort scores 98 against the average's 7, a fourteenfold split and the widest of all. Attack resistance runs 88 against 23, and the policy headers 61 against 15, **roughly four times the average** in both cases.
Two areas read against that grain. Security headers is the one place the average clears half, at 54 out of 100, and only because the **cheap headers nearly everyone already sends** prop it up.
Reporting setup is the opposite. Even the best cohort scores **8 out of 100**, so this is the one axis where being best still means almost nobody bothers. Read a spoke near zero with care: it can mean the control is simply absent rather than badly configured.
Best cohort Corpus average
Security Headers
Security Headers
| Security Headers | Best cohort | Corpus average | Domains measured |
| --- | --- | --- | --- |
| X-Content-Type-Options | 100/100 | 40/100 | 761,367 |
| Referrer-Policy | 100/100 | 24/100 | 761,367 |
| Cache-Control | 99/100 | 92/100 | 505,415 |
| Strict-Transport-Security | 99/100 | 23/100 | 750,390 |
| Cross-Origin-Resource-Policy | 98/100 | 83/100 | 9,067 |
Attack Resistance
Attack Resistance
| Attack Resistance | Best cohort | Corpus average | Domains measured |
| --- | --- | --- | --- |
| Clickjacking | 99/100 | 35/100 | 761,367 |
| Data Exfiltration | 99/100 | 50/100 | 761,367 |
| Script Injection | 82/100 | 3/100 | 761,367 |
| Supply Chain | 70/100 | 4/100 | 761,367 |
Reporting-API Policies
Reporting-API Policies
| Reporting-API Policies | Best cohort | Corpus average | Domains measured |
| --- | --- | --- | --- |
| Integrity-Policy | 100/100 | 82/100 | 5 |
| Permissions-Policy | 96/100 | 9/100 | 761,346 |
| Document-Policy | 94/100 | 100/100 | 717 |
| Cross-Origin-Opener-Policy | 71/100 | 10/100 | 761,213 |
| Content-Security-Policy | 61/100 | 47/100 | 148,000 |
| Cross-Origin-Embedder-Policy | 45/100 | 0/100 | 761,206 |
| Network Error Logging | 30/100 | 34/100 | 761,367 |
| Connection-Allowlist | 0/100 | 100/100 | 1 |
Reporting-API Setup
Reporting-API Setup
| Reporting-API Setup | Best cohort | Corpus average | Domains measured |
| --- | --- | --- | --- |
| CSP violation | 36/100 | 2/100 | 761,367 |
| Network error | 28/100 | 34/100 | 761,367 |
| Crash | 6/100 | 0/100 | 761,367 |
| Deprecation | 6/100 | 0/100 | 761,367 |
| Intervention | 6/100 | 0/100 | 761,367 |
| Permissions-Policy violation | 5/100 | 0/100 | 761,367 |
| COOP report | 4/100 | 0/100 | 761,367 |
| COEP violation | 3/100 | 0/100 | 761,367 |
| Connection-Allowlist | 1/100 | 0/100 | 761,367 |
| CSP script-hash report | 1/100 | 0/100 | 761,367 |
| Document-Policy violation | 1/100 | 0/100 | 761,367 |
| Integrity violation | 1/100 | 0/100 | 761,367 |
Content Security Policy
Experimental directive Deprecated directive
Content Security Policy
| Content Security Policy | Best cohort | Corpus average | Domains measured |
| --- | --- | --- | --- |
| base-uri | 100/100 | 20/100 | 146,602 |
| default-src | 100/100 | 25/100 | 143,920 |
| font-src | 100/100 | 27/100 | 132,731 |
| form-action | 100/100 | 12/100 | 147,670 |
| frame-ancestors | 100/100 | 87/100 | 76,310 |
| frame-src | 100/100 | 17/100 | 130,194 |
| manifest-src | 100/100 | 7/100 | 95,459 |
| media-src | 100/100 | 15/100 | 112,749 |
| report-to | 100/100 | 99/100 | 3,088 |
| report-uri | 100/100 | 100/100 | 8,478 |
| require-trusted-types-for | 100/100 | 100/100 | 287 |
| script-src | 100/100 | 10/100 | 142,389 |
| style-src-elem | 100/100 | 46/100 | 3,188 |
| upgrade-insecure-requests | 100/100 | 100/100 | 49,894 |
| worker-src | 100/100 | 16/100 | 101,932 |
| trusted-types | 99/100 | 91/100 | 167 |
| img-src | 98/100 | 16/100 | 148,508 |
| connect-src | 97/100 | 13/100 | 144,155 |
| object-src | 96/100 | 22/100 | 147,729 |
| block-all-mixed-content | 94/100 | 94/100 | 6,137 |
| script-src-attr | 94/100 | 63/100 | 2,887 |
| webrtc | 94/100 | 94/100 | 45 |
| style-src | 90/100 | 16/100 | 138,004 |
| child-src | 88/100 | 4/100 | 99,913 |
| style-src-attr | 82/100 | 55/100 | 2,008 |
| script-src-elem | 81/100 | 19/100 | 4,915 |
| sandbox | 71/100 | 46/100 | 201 |
| fenced-frame-src | 0/100 | 64/100 | 21 |
| navigate-to | 0/100 | 92/100 | 28 |
| plugin-types | 0/100 | 94/100 | 19 |
| prefetch-src | 0/100 | 77/100 | 123 |
| referrer | 0/100 | 94/100 | 15 |
| reflected-xss | 0/100 | 94/100 | 16 |
| require-sri-for | 0/100 | 54/100 | 14 |
Each radar plots every posture control we measure, hygiene headers aside, however few domains use it. Read both extremes with care. A spoke near zero can mean the control is configured badly, or simply that almost nobody sets it. A spoke near the rim can mean the same: each average covers only the domains that set that control, so a rarely used one often sits high because the handful who bother also configure it well. Green is 150 domains, amber is all 761,367.
The best sites settle the report's central question. A strict, secure posture is fully buildable, and a **1-in-5,000 sliver** of the web has built it. The distance to everyone else is not a matter of tuning. It is the distance between sending a header and maintaining a whole policy, the same quality-high, security-low split traced here from the first chart to the last.
* * *
This report is produced by automated header analysis and reflects each target's configuration at scan time only. It is not a substitute for a penetration test, source-code review or runtime testing, and does not assert the absence of other vulnerabilities. All statistics are anonymized population shares over the domains we scan, and no individual site is named.
## Where does your site land?
Scan your domain against the same checks that produced this report, then let CentralCSP collect the real Content-Security-Policy reports from your visitors' browsers so you can close the gap.
[Scan your site](https://centralcsp.com/en/tools/csp-scanner/) [Start with CentralCSP](https://app.centralcsp.com)
---
Available in: [en](https://centralcsp.com/en/state-of-the-web/), [fr](https://centralcsp.com/fr/state-of-the-web/)
```yaml
title: "Website security score - free benchmark vs 500,000+ sites"
description: "Scan any domain for free and score its CSP, security headers and attack resistance out of 100 against the best-configured sites and 500,000+ others."
url: "https://centralcsp.com/en/tools/compare/"
lang: "en"
```
Tools
# Compare your site's security
Run a live scan and see how your security posture stacks up against the best-configured sites in our dataset and the dataset average. Free, no account needed.
### Compare your site
Run a live scan of your site and see how its security posture compares to the best-configured sites in our dataset and the dataset average.
Scan & compare
Enter a domain and we scan it, then chart its scores against this year's cohort. Any public domain works, including one you do not own.
Want the findings behind these scores? [Run the security headers scan](https://centralcsp.com/en/tools/security-headers/)
Sample result
## What your benchmark looks like
How a typical store that ships the basic headers but no Content Security Policy compares. The green and orange references are the real 2026 dataset values your own scan is charted against.
Your site 46/100
Best cohort 71/100
Average 25/100
Your site Best cohort Average
The blue series is illustrative. Best-cohort and average values are the real 2026 dataset references, published in the State of the Web report. Run the scan above to draw your own site's polygon.
Guide
## Understanding your security benchmark
This benchmark scores your site's public security configuration and plots it against how other sites score, so the number comes with a reference point. It answers the question a lone grade cannot: not "is my site secure?" but "is it better or worse configured than everyone else's?". It runs a live scan and charts the result against the rest of the scanned web.
### What the comparison measures
It scores what any outsider can verify about your site: the security headers you send, the Content Security Policy behind them, how you hold up against the attack classes that actually hit production sites, and whether your policies report anywhere. Nothing is installed and no account is needed: if a header is missing from your responses, it is missing for everyone who looks. The controls behind each axis are covered in our [web security guides](https://centralcsp.com/en/docs/web-security).
### How the score is calculated
Six areas, each scored from 0 to 100, each read from the same public response:
- **Security headers:** every protective response header, judged on the value it carries rather than on being present.
- **Content Security Policy:** the policy your server sends, with permissive keywords, broad sources and missing directives weighted by what an attacker would use.
- **Attack resistance:** what the configuration would actually stop, across the common client-side attack routes.
- **Policy enforcement:** which policies you enforce rather than run in report-only mode, and how tightly each one is configured.
- **Reporting-capable policies:** whether the policies you send are wired to report violations rather than failing silently.
- **Reporting setup:** whether the endpoints you declare exist, are referenced correctly, and would receive what the browser sends.
The overall number averages only the areas your site was evaluated on, which is why a site with no policy at all shows fewer spokes rather than a row of zeros.
### Who you are compared against
Your scores are charted against two references: the best cohort, meaning the best-configured sites of the year, and the dataset-wide average. Both come from the CentralCSP dataset, the same one behind our annual [State of the Web report](https://centralcsp.com/en/state-of-the-web/). The 2026 edition covers 761,345 scored domains, with a best cohort of 150 sites.
Both references are published and auditable, which is unusual for a benchmark. Security ratings products compare you to an industry cohort they do not disclose; here you can open the report and see how the population scores, control by control. The references refresh with each edition, so the bar moves as the web does.
### How to read your security benchmark radar
One look at the radar tells you where you stand: each spoke is a control scored 0 to 100 for your site, the best cohort, and the average, so the controls carrying your gap are visible immediately. Two conventions keep the picture honest: a control that does not apply to you is left off the chart rather than dragging your polygon to zero, while a required control that is missing stays at 0, so a real gap is never hidden.
### If a security ratings platform flagged your site
[SecurityScorecard](https://securityscorecard.com), [Bitsight](https://www.bitsight.com) and [RiskRecon](https://www.riskrecon.com) read the same outside-in signals this scan does: your public responses, no agent, no access. Everything they can flag about your headers and client-side policies, this scan flags too, and it keeps going where their checklists stop: value-level findings, attack resistance, and whether your reporting actually works.
To see those findings on your own site, control by control, run one of these: [CSP scanner](https://centralcsp.com/en/tools/csp-scanner/), [Security headers checker](https://centralcsp.com/en/tools/security-headers/) or [Reporting API checker](https://centralcsp.com/en/tools/reporting-api/). Each one lists the exact headers and directives behind the score, and what to change.
If you are working from a specific finding, two walkthroughs cover the common ones: [fix SecurityScorecard CSP findings](https://centralcsp.com/en/blog/fix-securityscorecard-csp-findings) and [fix BitSight CSP findings](https://centralcsp.com/en/blog/fix-bitsight-csp-findings). BitSight began rating CSP in July 2025: [why BitSight now rates CSP](https://centralcsp.com/en/blog/bitsight-rau25-was-csp).
CentralCSP is not affiliated with SecurityScorecard, Bitsight, RiskRecon or any ratings platform, and no tool can promise a specific score: this scan shows you the same outside-in evidence they measure, so you can fix the controls behind it.
Keep reading
- [Content-Security-Policy overview](https://centralcsp.com/en/docs/web-security/policies/content-security-policy)
- [Web security guides](https://centralcsp.com/en/docs/web-security)
- [CSP violation reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation)
- [Subresource Integrity](https://centralcsp.com/en/docs/web-security/other/subresource-integrity)
- [How to improve your security headers grade](https://centralcsp.com/en/blog/improve-security-headers-grade)
More free tools
## Keep auditing with the other free tools
Every tool is free, runs without an account, and scores with the same severity scale.
### Security headers scanner
Grade every security header a URL sends, from HSTS to Permissions-Policy, with each finding explained and prioritized.
- Every header, one grade
- Fix list ordered by impact
[Scan your security headers](https://centralcsp.com/en/tools/security-headers/)
### CSP scanner
Fetch a URL's live Content-Security-Policy and score it against known bypasses, wildcard sources and missing directives.
- Directive-level findings
- Shareable results link
[Run the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/)
### Reporting API checker
Check that violation reporting actually works: endpoints, Reporting-Endpoints and Report-To, and which security features really report.
- Endpoint and feature mapping
- Silent drops flagged
[Check your Reporting API setup](https://centralcsp.com/en/tools/reporting-api/)
### Technology Checker
List the libraries and frameworks a page uses, with their versions, where each comes from, and the known CVEs affecting them.
- Versions and end-of-life status
- CSV, CycloneDX and PDF exports
[Check a site's technologies](https://centralcsp.com/en/tools/tech-checker/)
FAQ
## Frequently asked questions
Scoring, the dataset and security ratings, answered.
### How does the website security comparison work?
Enter a domain and the tool runs a live scan of the site's public responses, following redirects to the final URL. It scores five areas on a 0-100 scale: security headers, Content Security Policy, attack resistance, reporting-capable policies, and reporting setup. Each area is then charted against two references from the CentralCSP dataset: the best-configured sites of the year and the dataset-wide average. A scan typically finishes in under a minute.
### What is a good website security score?
In the 2026 CentralCSP dataset the average site scores 46 out of 100 overall and the best-configured cohort averages 92.4, so "average" is a very low bar. Above 60 overall already puts a site ahead of 93% of the scanned web. The gap is mostly Content Security Policy (dataset average 7 out of 100) and HSTS (average 23), so those two areas usually move a score fastest.
### Can I benchmark a competitor's site?
Yes. The scan reads only the public responses a site sends to everyone, the same view any visitor gets, so it runs on any reachable domain whether or not you own it. It handles one domain at a time: scan yours, then scan theirs, and read both polygons against the same two references, the best cohort and the population average. Nothing is logged into, nothing is probed beyond what a browser would request.
### Why a score out of 100 instead of an A to F grade?
Because a letter collapses five different areas into one character, and the letter you get tells you nothing about which one is dragging you down. Here each area keeps its own 0-100 spoke, so you can see that your headers are fine and your Content Security Policy is the gap, rather than being handed a C. A grade also has no reference point: it says how you did against a fixed checklist, not where you sit relative to other sites, which is the question this tool exists to answer.
### Which sites is mine compared against?
The same dataset behind the CentralCSP State of the Web report: 761,345 scored domains in the 2026 edition. The green reference is the best cohort, the 150 best-configured sites of the year; the orange reference is the dataset-wide average. Both are published in the report, and they refresh with each annual edition.
### How often do the reference numbers change?
Once a year. The best cohort and the population average both come from the State of the Web census, which is published annually, and the references your radar is drawn against right now are the 2026 edition. Your own score is live: it is measured at the moment you scan, so re-running after a fix shows the change immediately even though the references stay put until the next edition.
### Is the benchmark free? Do I need an account?
Yes, it is free, and no account or email is needed. An invisible captcha runs before each scan to keep automated abuse out. The scan is a real live scan of your site, not a cached lookup, so you can re-run it right after deploying a fix and see the change.
### Will fixing these gaps improve my SecurityScorecard or Bitsight rating?
Those platforms observe the same public signals this scan does, so deploying a fix gives their scanners a compliant response to observe, which is what resolves the corresponding finding. Use the platform's own resolve or rescan flow to speed that up. No tool can promise a specific score change: composite ratings weigh your entire digital footprint with proprietary models, and CentralCSP has no access to your scorecard.
### Why does my radar show fewer spokes than expected?
Controls that were not evaluated for your site are left off the chart so they do not flatten your polygon at zero. A control that is required but missing is different: it stays on the chart at 0, so a genuine gap remains visible. Your overall score follows the same rule and averages only the areas you were evaluated on.
## Today's score is one deploy from changing
CentralCSP watches your CSP and security headers continuously, with reports straight from your visitors' browsers, and alerts you when a deploy drops a header or a new script appears. The posture you benchmarked today is still there next quarter. Add one header, no code changes.
[Start with CentralCSP](https://app.centralcsp.com) [See continuous header monitoring](https://centralcsp.com/en/platform/monitoring/)
---
Available in: [en](https://centralcsp.com/en/tools/compare/), [fr](https://centralcsp.com/fr/tools/compare/)
```yaml
title: "Free CSP evaluator & validator - grade your policy"
description: "Paste a Content-Security-Policy and get a 0-100 grade: every directive checked, unsafe-inline, wildcards and JSONP bypasses flagged, fixes ranked by severity."
url: "https://centralcsp.com/en/tools/csp-evaluator/"
lang: "en"
```
Tools
# CSP evaluator
Paste a Content-Security-Policy and get a graded evaluation: weaknesses flagged directive by directive, with prioritized fixes.
### Evaluate a policy
Paste a Content-Security-Policy and get a graded evaluation: every directive checked, weaknesses flagged, prioritized fixes.
Evaluate policy
Paste the policy value, with or without the header name.
Is the policy already live on a site? [Scan the URL with the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/)
Sample result
## See a graded policy before you paste yours
The kind of policy most sites still ship, graded and flagged directive by directive. Paste yours above to get the same verdict.
43 / 100
Critical CSP gaps
Overall CSP score
### Next actions
Replace 'unsafe-inline' in script-src with a nonce or hash
Stop allowlisting hosts with known JSONP endpoints
Replace the wildcard host with an exact hostname or a nonce
Add object-src 'none' and base-uri 'none'
Security
How well the site resists client-side attacks.
31 /100
The configuration has significant security gaps.
Quality
Hygiene only: typos, duplicates, dated values.
78 /100
A few things to tidy up: dated values, duplicated directives, options that no longer match current practice. None of them weakens the site, they just make it harder to maintain.
* * *
Flagged values are tinted by severity. Select one to see what is wrong, the impact, and the fix to apply.
content-security-policy[](https://centralcsp.com/en/docs/web-security/policies/content-security-policy)
default-src
'self'
script-src
'self' 'unsafe-inline' \*.example-cdn.com https://www.google-analytics.com
style-src
'self' 'unsafe-inline'
img-src
\*
* * *
### Findings & recommendations
Issues and quality recommendations for this Content-Security-Policy.
###
'unsafe-inline' allows any injected script to run The script-src directive allows inline scripts. An attacker who can inject HTML into the page can execute arbitrary JavaScript, which is the exact attack a CSP exists to stop.
Critical Security
Critical Security
Recommendation
Replace 'unsafe-inline' with a nonce or a hash for each inline script you actually ship. Browsers that support CSP Level 2 or 3 will then ignore a leftover 'unsafe-inline' fallback.
Impact
Any successful HTML injection becomes full cross-site scripting: session theft, payment form skimming, account takeover.
###
An allowlisted host exposes a JSONP endpoint that bypasses the policy www.google-analytics.com serves a JSONP endpoint. Because the whole host is trusted, an attacker can point a script tag at that endpoint with a callback of their choice and execute code with the policy enforced.
High Security
High Security
Recommendation
Load the analytics snippet with a nonce or hash plus 'strict-dynamic' instead of allowlisting the host, so trust attaches to the script you ship rather than to everything the host serves.
Impact
The policy reads as strict but is bypassable in practice: a known public technique turns the trusted host into an execution route.
Example
```
```
###
A wildcard host trusts every file on every subdomain \*.example-cdn.com allows scripts from any subdomain of the CDN. You are not trusting your bundle, you are trusting every customer upload and every forgotten bucket under that wildcard.
High Security
High Security
Recommendation
Pin the exact hostname you load from, or better, move script-src to a nonce or hash plus 'strict-dynamic' and drop the host list entirely.
Impact
Any attacker-controlled file anywhere under the wildcard executes as if it were your own code.
###
No object-src or base-uri fallback The policy sets neither object-src nor base-uri. Plugins fall back to default-src, and a missing base-uri lets an injected tag redirect every relative script URL on the page.
Medium Security
Medium Security
Recommendation
Add object-src 'none' and base-uri 'none' unless you have a documented reason to allow them.
Impact
Two well-known escape hatches stay open even after script-src is fixed.
###
img-src \* allows images from any origin A wildcard image source is rarely exploitable on its own, but it makes the policy noisy to review and can leak visitor data to arbitrary origins through image requests.
Low Quality
Low Quality
Recommendation
List the image origins you actually use, or use 'self' plus your CDN.
Impact
A maintainability and privacy smell rather than a direct execution risk; it lowers the quality score, not the security score.
Guide
## Understanding your CSP evaluation
A Content-Security-Policy is only as strong as its weakest directive. The evaluator reads the policy the way an attacker would: it looks for the keyword, the wildcard, or the allowlisted host that turns your header into a bypass.
### How this compares to Google's CSP Evaluator
[Google's CSP Evaluator](https://csp-evaluator.withgoogle.com) and ours flag the same core weaknesses. What differs is what you get back, and what happens after the policy ships.
Our CSP evaluator compared with Google's CSP Evaluator
| Capability | CentralCSP | Google's CSP Evaluator |
| --- | --- | --- |
| Per-finding severity | Yes | Yes |
| Known allowlist and JSONP bypass checks | Yes | Yes |
| Overall 0-100 grade | Yes | No |
| Separate security and quality scores | Yes | No |
| Findings ordered by severity, each with a next action | Yes | Flags the weakness |
| Parsed directive view pinning each finding to its value | Yes | Per-directive listing |
| Accepts a Report-Only policy value | Yes | Not distinguished |
| Violation reporting once the policy is deployed | Yes, through CentralCSP | No |
### What the evaluator checks
The policy is parsed directive by directive and every source value is checked for what an attacker could use: unsafe keywords, overly broad sources, missing fallback directives, and allowlisted hosts that can be abused to run code the policy was supposed to block. Each class of weakness is explained in the [script-src directive reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src).
### How to read the scores
The verdict is built to be acted on: every weakness is pinned to the directive that caused it, with the fix right next to it. A dangerous keyword? Flagged. A source broad enough to be abused? Flagged too. Chase the security score first, a tidy policy can still be wide open, and clear the next actions in order: they are already sorted by what an attacker would use first.
### What a good CSP score looks like
Two axes, one to chase. The security score measures how well the policy resists real attacks; the quality score measures how cleanly it is written. A policy can be immaculately authored and still leave the door open, so when the two disagree, the security score is the one that matters.
What each score band means
| Score | What it means |
| --- | --- |
| 80 and above | A solid CSP setup. Worth keeping under monitoring so it does not drift. |
| 50 to 79 | Needs attention. The policy exists but something in it undoes a good part of the protection. |
| Below 50 | Critical gaps. Treat the top findings as the work, not as a backlog. |
### Three findings you will almost certainly see
'unsafe-inline' in script-src is the first. It allows any injected script to run, which is the exact thing the directive exists to stop. The fix is a nonce or a hash for the inline code you actually need.
A wildcard or a long host allowlist is the second. A wildcard host trusts every file on every subdomain, and a long allowlist is only as strong as its weakest entry: one host serving a JSONP endpoint is enough to bypass the policy. The fix is to shorten the list, or move to a nonce with strict-dynamic so the list stops carrying the weight.
A missing object-src or base-uri is the third. Neither falls back to default-src in a way that protects you, so both should be set to 'none' unless you have a specific reason not to.
### Check a policy before it ships
Because the evaluator works on the policy text alone, nothing has to be live. Paste the value from your nginx config, your middleware, or a teammate's pull request and review it before it reaches production. It also reads a Content-Security-Policy-Report-Only value, so you can grade the policy you are trialing before you enforce it.
A clean evaluation is step one, not proof. Deploy the policy in report-only mode first and watch what real browsers report; the policy that looks strict on paper is often the one that blocks your own checkout script. When the site is live, [scan the URL with the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/) to confirm the header your server actually sends matches what you evaluated.
### Why an allowlist policy still gets bypassed by JSONP
Most policies in the wild are allowlists, and that is why they fail: you are not trusting hosts, you are trusting every file on them, and a single abusable endpoint on an allowlisted CDN runs attacker code with the policy enforced. [How JSONP endpoints bypass your CSP](https://centralcsp.com/en/blog/jsonp-csp-bypass) walks through the bypass step by step.
The fix is a strict CSP: replace the host list with a nonce or hash plus 'strict-dynamic', so trust attaches to the scripts you tagged rather than to whole origins, and close the fallback gaps with object-src 'none' and base-uri 'none'. How nonces and hashes work is covered in the [CSP hashes and nonces guide](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce). The full syntax is in the [script-src directive reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src).
### When a security rating flags your CSP
Rating platforms like [SecurityScorecard](https://securityscorecard.com) and [Bitsight](https://www.bitsight.com) score your CSP from the outside, and a finding like "Content Security Policy Contains Broad Directives" often arrives via a customer or an insurer. Paste the exact policy from the finding here to see what their scanner saw and which directive triggered it.
Fix the flagged directive, evaluate the corrected policy until it comes back clean, then deploy it and use the platform's own resolve or rescan flow. A decorative wide-open policy no longer helps: rating scanners grade permissive policies as failures, so the finding only closes with a policy that is genuinely tighter.
Keep reading
- [Content-Security-Policy overview](https://centralcsp.com/en/docs/web-security/policies/content-security-policy)
- [The script-src directive](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src)
- [CSP hashes and nonces](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
- [CSP violation reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-violation)
- [How JSONP endpoints bypass a CSP](https://centralcsp.com/en/blog/jsonp-csp-bypass)
- [strict-dynamic explained](https://centralcsp.com/en/blog/strict-dynamic-csp)
- [CSP keyword reference](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-keywords)
- [A strict CSP starter template](https://centralcsp.com/en/blog/csp-starter-template)
More free tools
## Keep auditing with the other free tools
Every tool is free, runs without an account, and scores with the same severity scale.
### CSP scanner
Fetch a URL's live Content-Security-Policy and score it against known bypasses, wildcard sources and missing directives.
- Directive-level findings
- Shareable results link
[Run the CSP scanner](https://centralcsp.com/en/tools/csp-scanner/)
### CSP hash generator
Turn an inline script or style into the hash that lets it run under a strict policy, right in your browser.
- Runs entirely client-side
- SHA-256, 384 and 512
[Generate a CSP hash](https://centralcsp.com/en/tools/csp-hash/)
### Security headers scanner
Grade every security header a URL sends, from HSTS to Permissions-Policy, with each finding explained and prioritized.
- Every header, one grade
- Fix list ordered by impact
[Scan your security headers](https://centralcsp.com/en/tools/security-headers/)
### Chrome extension
Watch violations stream in on a real page, swap the policy in Report-Only or Enforce, and test a fix without a deploy.
- Test against production pages
- No deploy to try a policy
[Build a policy in your browser](https://centralcsp.com/en/tools/extension/)
FAQ
## Frequently asked questions
Scoring, bypasses and pre-deploy checks, answered.
### Is this CSP evaluator free?
Yes. Paste a policy and evaluate it as often as you need: no account, no email, no install. The policy is analyzed by the CentralCSP API and the verdict comes back in seconds; an invisible anti-bot check runs in the background instead of a captcha puzzle. Only the policy text you paste is sent. Nothing else about your site is touched: there is no crawl and no request to your server.
### What is the difference between the CSP evaluator and the CSP scanner?
The evaluator reads a policy string you paste, so it works before anything is deployed: on a config file, a pull request, or a header you copied from a guide. The scanner takes a URL, fetches the page and reads the Content-Security-Policy the server actually sends, including a Report-Only one, which is how you check what is live rather than what you meant to ship. Both use the same severity scale and the same score bands, so a verdict from one is directly comparable to the other.
### How is this different from Google's CSP Evaluator?
Google's CSP Evaluator flags weaknesses in a pasted policy and it does that well. This tool flags the same core issues and adds a 0 to 100 grade, separate security and quality scores, next actions ordered by severity, and a parsed view that pins each finding to the directive that caused it. It is also the front door to monitoring: once the policy ships, CentralCSP can collect violation reports from real browsers instead of leaving you with a one-off paste.
### What does a good Content-Security-Policy look like?
A strict policy trusts specific scripts, not whole hosts: script-src with a nonce or hash plus 'strict-dynamic', object-src 'none', and base-uri 'none'. Long host allowlists, 'unsafe-inline', and wildcards are what evaluators flag, because each one is a documented bypass route. If your policy is a list of CDNs, expect a low security score even if every host is one you use.
### Why is 'unsafe-inline' flagged as a serious problem?
'unsafe-inline' allows every inline script on the page to run, including the one an attacker injects, which defeats the main point of a CSP. Replace it with a nonce or a hash for the inline code you actually ship. One nuance: in a policy that already has a nonce or hash, browsers that support CSP Level 2 or 3 ignore 'unsafe-inline', so keeping it purely as a fallback for old browsers is accepted practice and scored accordingly.
### Can I evaluate a policy that is not deployed yet?
Yes, that is the point of pasting instead of scanning. The evaluator only reads the policy text, so a value from a config file, a pull request, or a report-only trial works the same as a live header. When the policy is deployed, use the CSP scanner to confirm the header your server actually sends, on every response, matches what you evaluated.
### Does a high score mean my site is safe from XSS?
No. The score grades the policy text: it cannot see whether the header ships on every page, whether it is enforced or report-only, or what breaks in real browsers once it is live. A strict CSP is a strong XSS mitigation, not a replacement for fixing injection bugs. Treat a high score as a prerequisite, then verify deployment with a scan and watch violation reports in production.
## Your policy will change. Re-check it automatically.
The evaluator grades a snapshot. CentralCSP watches the policy your site actually serves and collects violation reports from your visitors' browsers, so a new script, a weakened directive, or a broken page shows up as an alert instead of an incident. Add one header, no code changes.
[Start with CentralCSP](https://app.centralcsp.com) [Build a CSP from your real traffic](https://centralcsp.com/en/platform/csp-builder/)
---
Available in: [en](https://centralcsp.com/en/tools/csp-evaluator/), [fr](https://centralcsp.com/fr/tools/csp-evaluator/)
```yaml
title: "Free CSP hash generator - inline script & style SHA-256"
description: "Paste an inline script or style, get its SHA-256, 384 or 512 CSP hash and a ready-to-paste script-src line. Drop unsafe-inline. Nothing leaves your browser."
url: "https://centralcsp.com/en/tools/csp-hash/"
lang: "en"
```
Tools
# CSP hash calculator
Paste an inline script or style and get its hash to allowlist it in your Content-Security-Policy.
Inline script or style content [Learn how CSP hashes work](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) Hashing runs locally in your browser through the Web Crypto API. Nothing is uploaded.
256 384 512
Calculate hash
Need an integrity hash for a remote file? [Use the SRI calculator](https://centralcsp.com/en/tools/sri-hash/)
Guide
## Understanding CSP hashes
This CSP hash generator lets you keep a specific inline script or style in your pages while running a strict Content-Security-Policy, without falling back to the unsafe 'unsafe-inline' keyword.
### What is a CSP hash?
A CSP hash is a base64-encoded SHA digest of the exact contents of an inline script or style element. You add it to your policy so the browser executes only that exact snippet and blocks everything it did not expect.
Because the value is derived from the code itself, a strict policy can allow the inline code you trust while still stopping any script an attacker manages to inject into the page. Read the full explanation in the [CSP hashes and nonces guide](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce).
### Remove unsafe-inline without breaking your inline scripts
Copy the generated value, including the sha256- prefix and the surrounding quotes, into your script-src directive for scripts or style-src for styles. You can list several hashes in the same directive.
Hash only the content between the tags, never the script or style tags themselves. The digest must match the inline content byte for byte, so a single added space or line break produces a different hash and the browser will reject it. For the complete directive syntax, see the [script-src directive](https://centralcsp.com/en/docs/web-security/policies/content-security-policy/directives/script-src).
```
Content-Security-Policy:
script-src 'self' 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc=';
# the same generated value, for an inline