← All posts

BitSight RAU25 and why CSP is now rated

CentralCSP Team ·

Last update:

If you watch your BitSight rating, a change that went live in July 2025 affects how your web applications move your score. BitSight previewed the 2025 Ratings Algorithm Update (RAU25) on April 8, 2025 and rolled it out live in July 2025. RAU25 retired the old Web Application Headers (WAH) risk vector and put Web Application Security (WAS) in its place. WAS takes over the same 5% weight WAH held in the overall rating.

The short version: a weak or violated Content Security Policy (CSP) can now pull your rating down. CSP is an HTTP response header that tells the browser which scripts, styles, and other resources a page is allowed to load. Under WAS, BitSight scores how well that policy is written, and some directives count more than others. This post explains what changed, how the security header is graded, and how to fix a policy that is failing.

What changed in RAU25

WAS is not a straight rename of WAH. It keeps the header checks WAH carried and adds a broader set of web application security assessments on top, so a weak Content Security Policy is now one signal among several.

A few facts worth keeping straight:

  • WAS carries a 5% weight in the overall rating, the same weight WAH held, so it is a small but real slice of your score.
  • WAS replaces WAH as the rated web application vector.
  • WAS runs 21 assessments across 5 categories.

Each assessment gets a word finding grade, BAD, WARN, and FAIR among the grades used, and the risk vector as a whole gets a letter grade from A to F. Fix the most severe findings first, since those weigh heaviest on the vector grade.

How Content Security Policy is scored

BitSight grades a "Content Security Policy (CSP) Violations" assessment, and the weight a violation carries depends on which directive caused it. BitSight groups directives into severity tiers.

One detail to flag: BitSight places object-src in the informational tier, even though object-src 'none' is widely treated as security-relevant. Keep setting it regardless of how BitSight tiers it, because it closes off a real injection path.

Two directives in the high-severity tier deserve a note. trusted-types is not defined in CSP Level 3. It comes from the separate W3C Trusted Types spec, alongside require-trusted-types-for, and it is enforced only in Chromium-based browsers like Chrome and Edge, not Firefox or Safari. So that assessment only carries signal where the browser enforces it.

BitSight scores CSP from how the policy is written, a static read of the header and its directives. That is different from a CSP violation report, which is a runtime event the browser sends when a page tries to load something the policy forbids. CentralCSP works on the runtime side: it ingests the actual browser-emitted violation reports and builds a script inventory through CSP hash reporting. The two views complement each other. A clean static grade and clean runtime reports together tell you the policy is both well written and not breaking anything.

Why CSP carries weight here

A Content Security Policy is the browser-side control that limits which scripts and resources a page can run. It is one of the few defenses that reduces the impact of XSS, clickjacking, and other injection attacks after an attacker has already found a way onto the page. That is why BitSight treats a weak or absent policy as a real finding rather than a missing checkbox.

The most common way to weaken a policy is 'unsafe-inline'. It re-enables the inline scripts that CSP blocks by default, which is the exact behavior most XSS attacks rely on. If you are starting from a permissive policy, removing that keyword is the highest-value fix. Why you should never use unsafe-inline in CSP walks through the migration to nonces and hashes.

How to fix a failing policy

The goal is a strict policy that does not break the site and does not generate violations. Gather data before you enforce anything. The same workflow also clears the equivalent finding from other rating vendors, so you can fix SecurityScorecard CSP findings the same way.

1. Start in Report-Only

Deploy your draft policy with the Content-Security-Policy-Report-Only header first. The browser evaluates the policy and reports what it would have blocked, without blocking anything. Let it run for a week or two so you capture every legitimate script, style, and connection.

Content-Security-Policy-Report-Only:
    default-src 'self';
    script-src 'self' 'report-sample';
    style-src 'self';
    img-src 'self';
    font-src 'self';
    connect-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
    report-uri https://<Endpoint-ID>.report.centralcsp.com

2. Collect the violation reports

Point the reporting directive at an endpoint that collects the reports, then read what got blocked. CentralCSP ingests these reports and groups them so you can see, per directive, exactly which resources your draft policy would refuse. That inventory is what you build the real policy from.

3. Tighten the high-severity directives first

BitSight grades worst-first, so spend your effort where it moves the score. Remove 'unsafe-inline' and 'unsafe-eval' from script-src and the other high-severity directives, and replace inline code with external files, nonces, or hashes.

The two patterns to replace:

<!-- before: inline handler and inline block, both need unsafe-inline -->
<button onclick="submitForm()">Send</button>
<script>
  initWidget();
</script>
<!-- after: external file, allowed by script-src 'self' -->
<button id="send">Send</button>
<script src="/js/app.js"></script>
// app.js, the inline handler moved into an addEventListener call
document.getElementById("send").addEventListener("click", submitForm);
initWidget();

For an inline block you cannot move, allow it with a nonce instead of 'unsafe-inline':

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m'
<script nonce="r4nd0m">
  initWidget();
</script>

4. Check the policy before you enforce it

Before you flip from Report-Only to enforcing, run the draft through the CSP evaluator to catch remaining 'unsafe-inline', broad wildcards like *, and bare schemes like http: in sensitive directives. Fix what it flags or accept the risk knowingly.

5. Enforce, then keep watching

Switch to the enforcing Content-Security-Policy header. Keep the reporting directive in place so you keep receiving violation reports, and review them after each deploy. A policy that passed last month can start failing the moment a new third-party script lands on the page, which is the same drift BitSight will catch on its next scan.

The takeaway

RAU25 ties part of your BitSight rating to how well your Content Security Policy is written, with the script-running directives weighted highest. A strict policy with no 'unsafe-inline', no broad wildcards, and no live violations is what keeps that part of the score healthy. Build it in Report-Only, base it on real reports, and keep monitoring after you enforce it.

To collect violation reports and track your policy over time, start free with CentralCSP.

Sources