CentralCSP
Register

CSP Builder · From your own traffic

Generate a real CSP.
From the reports you already have.

Hand the Builder a window of CSP violation reports. It drafts a complete Content-Security-Policy with every source your app actually needs, every keyword the scoring agencies expect, and a value-by-value review, so nothing ships you cannot defend.

Generate your policyBook a demo

Why the output is different

Built from what actually loads. Reviewed before it ships.

Real

Sourced from CSP violation reports your browsers already emit on production. No static analysis, no synthetic crawler, no guesswork about what your app loads.

5+

Scoring frameworks the Builder aligns with as it writes: OWASP CSP, BitSight, SecurityScorecard, PCI DSS v4.0.1, and SOC 2.

Level 3

Full CSP Level 3 directive coverage, plus modern keywords: nonce, 'strict-dynamic', trusted-types, report-to, Reporting-Endpoints.

The problem

Hand-writing a CSP is a one-quarter project that no team has time for.

Modern apps load JavaScript from dozens of vendors. Each one needs a directive value, each value is a chance to break the site, and every scoring agency has a different opinion about what good looks like. Most teams put it off until an auditor or a customer brings it up.

  1. 01Time

    Mapping every script, font, and pixel by hand takes weeks.

    You read through application code, ask vendors what their tag actually does, and discover three new sources after every release. By the time you have a draft, the app has moved on and the draft is already wrong.
  2. 02Risk

    Ship a policy that is too strict and the site breaks for real users.

    Missing one third-party CDN is enough to break checkout for half a country. Most teams either ship a permissive policy they cannot defend, or they ship a strict one without testing and revert the next day.
  3. 03Compliance

    BitSight, SecurityScorecard, OWASP, PCI DSS, all asking for the same thing.

    Each framework wants the same outcome (a tight CSP) but spelled differently. Aligning a hand-written policy with all of them, and keeping it aligned as the app changes, is the kind of work that never feels finished.

How it works

Five steps.
Twenty minutes.

The Builder turns one screenful at a time into a policy you can ship. Each step is one decision, with the reports that justify it sitting right next to the suggestion.

  1. 01 / 05Step

    Detect

    Point the Builder at one of your applications. It picks up the policy you already serve (if any) and uses it as a starting point, or starts from a strict baseline.
  2. 02 / 05Step

    Analyze

    Pick a window of CSP violation reports, anything from one day to ninety. The Builder processes every report, attributes sources by directive, and weighs them by how often the browser saw them.
  3. 03 / 05Step

    Generate

    A complete candidate policy is drafted with the sources your app actually needs, security keywords like nonce or strict-dynamic where it helps, and the directives BitSight, SecurityScorecard, and OWASP score you on.
  4. 04 / 05Step

    Review

    Walk every directive and every value. Each source carries the reports that justify it. Approve, reject, or migrate. Nothing ships without you.
  5. 05 / 05Step

    Deploy

    Copy the final header out of the Builder. Paste it into your server, CDN edge, or framework middleware. Roll it out as Report-Only first, then enforcing once the report feed stays quiet.

What you get

A policy you can defend in your next audit.

~20 min

From hitting Generate to a reviewed, copy-ready Content-Security-Policy. Most of that time is your team approving values, not waiting on the tool.

All

CSP Level 3 directives, plus modern keywords: nonce, 'strict-dynamic', trusted-types, report-to, Reporting-Endpoints. No gaps.

0

Agents, crawlers, staging environments. The Builder works off real browser traffic you are already collecting through CSP reporting.

Per-value review wizard

Every source.
With the reports that justify it.

Each directive is reviewed value-by-value. The build shows the source, every blocked URI that triggered it and the report counts. Approve or reject.

Review the candidate policy

Each new source is shown with the reports that justify it.

3 of 12
script-src/https://cdn.acme.com

Reports that justify this source

  • https://cdn.acme.com/checkout/v2/init.js1,284 hits
  • https://cdn.acme.com/checkout/v2/forms.js612 hits
  • https://cdn.acme.com/checkout/v2/widgets.js318 hits
  • https://cdn.acme.com/checkout/v2/locale-en.js142 hits

Compliance, baked in

BitSight. SecurityScorecard. OWASP.
Checked while you review.

The Builder runs the candidate policy against the public rules from the scoring agencies as it generates each directive. Missing frame-ancestors? Flagged. upgrade-insecure-requests absent? Suggested. The output is shaped for the audits your security team is already running. For PCI DSS v4.0.1 6.4.3 evidence specifically, pair it with Script Inventory for the per-page integrity records assessors ask for.
See the full PCI DSS coverage page

What we automate, what you keep

Builder does the inventory work. Your team makes the calls.

The Builder is opinionated about what should be in a CSP, not about who decides what your application is allowed to load. The split is on purpose.

Automated

What the Builder handles.

  • Parsing every CSP violation report from your reporting endpoint.
  • Grouping sources per directive with hit counts and first-seen dates.
  • Drafting a complete policy that passes OWASP, BitSight, and SecurityScorecard rules.
  • Suggesting migrations from 'unsafe-inline' to nonce or 'strict-dynamic'.
  • Flagging dev-only origins, wildcards, and stale vendors for human review.

Yours

What stays in your court.

  • The final approve / reject decision on every source in the policy.
  • Choosing Enforce or Report-Only for the first deploy.
  • Mapping the policy to your server, CDN, or framework configuration.
  • Coordinating change-management evidence with the alerting product for ongoing drift detection.

Lifecycle

From reporting endpoint
to a deployed CSP.

The Builder is the third step in a four-step lifecycle. Most of the time is the browser doing the work for you, in production, while you keep shipping.
  1. 01

    Connect

    Point your CSP reporting at CentralCSP and start collecting violation reports from real users. No agent. No crawler.

  2. 02

    Wait one to four weeks

    Real production traffic surfaces the vendors, CDNs, and inline blocks your app depends on. Thirty days is the sweet spot for most teams.

  3. 03

    Run the Builder

    Pick your application, pick a date range, watch the candidate policy assemble. Review each directive in roughly twenty minutes.

  4. 04

    Ship

    Copy the policy, deploy as Report-Only first, then promote to enforce. Keep the reporting endpoint on so you catch drift forever.

Frequently asked

Questions teams ask.

Straight answers about prerequisites, compliance, integration, and what shipping actually looks like. Missing yours? Reach out and we'll add it.

Product principle
A policy you cannot explain, value by value, is a policy your team will rip out the first time it breaks production.

Twenty minutes from reports to a real header

Stop hand-writing CSPs.
Start shipping them.

Connect a reporting endpoint, wait long enough to collect the long tail of vendors, then let the Builder draft the policy your auditors are already asking for.
Generate your policyTalk to us
    CSP Builder: generate a Content-Security-Policy from your own traffic | CentralCSP