Understand Bitsight new Web Application Security (WAS) algorithm

Tuesday, July 15, 2025

5 min read

BitSight's 2025 update is live: why your content security policy is hurting your score

If you track your cybersecurity posture using BitSight, a major change that went live on July 10, 2025, has fundamentally altered how your web applications affect your overall score. The 2025 Ratings Algorithm Update (RAU25) is not a minor tweak; it's a paradigm shift. The update replaces a simple header check with a deep, behavioral analysis of your web applications. The result? Misconfigurations that were once low-priority findings are now critical vulnerabilities with the potential to severely damage your security rating. This article breaks down what has changed, why your Content Security Policy (CSP) is now under the microscope, and provides a clear, actionable playbook to protect your score.

What's new? Meet the web application security (WAS) vector

BitSight has replaced the old Web Application Headers (WAH) vector with the much more comprehensive Web Application Security (WAS) vector. Here's the difference in simple terms:

The Old Way (WAH): This was like a security guard checking if your front door was locked. It looked for the presence of certain security headers and gave you a simple pass/fail.
The New Way (WAS): This is like a full security team patrolling inside your building. The WAS scanner uses a real browser to load your pages, run JavaScript, and see how your application actually behaves. It actively looks for risky behavior and security flaws aligned with the industry-standard OWASP Top 10.

The CSP spotlight: from "nice-to-have" to rated requirement

The most significant impact of the new WAS vector is on Content Security Policy (CSP). Previously, just having a CSP header was often enough. Not anymore. Your CSP is now judged on its effectiveness. A weak, permissive, or violated policy will now incur substantial penalties. To pass BitSight's assessment, your CSP must be strict and properly configured.

BitSight's new rules for an effective CSP

To avoid a negative finding, your CSP must meet these core requirements:

✅ It must exist and be properly formatted.
✅ It must contain the essential directives such as: default-src or script-src
🚫 It must not generate any CSP violation.
🚫 It must not use dangerous keywords like 'unsafe-inline' or 'unsafe-eval' in the sensitive directives.
🚫 It must not use overly broad wildcards (like *) or allow plain URL schemes (like http:).

The most critical change is the strict prohibition of 'unsafe-inline' and 'unsafe-eval'. Many organizations use these as a workaround for legacy code, but under the new standard, these permissive policies are now considered failing grades.

What is a CSP violation? The finding you must avoid

A CSP violation is exactly what it sounds like: it's an event where your website tries to load a resource (like a script, font, or image) that is forbidden by your Content Security Policy. Before the RAU25 update, these violations might happen silently. Now, they are a direct cause for a lower BitSight rating. The WAS scanner detects these violations as they happen, just like a user's browser does, and logs them as a "Content Security Policy Violations" BAD finding. You can see these violations for yourself by opening the Developer Console in your browser (usually by pressing F12). An error message will look something like this:

Seeing these errors in your console is a clear sign that your BitSight score is at risk.

Your 6-step playbook to avoid CSP penalties

Fixing your CSP can seem daunting, but you can achieve compliance with a methodical approach. The key is to gather data before enforcing a policy that could break your website.

Step 1: Audit in report-only mode

Don't start by deploying a strict, blocking policy. Instead, use the Content-Security-Policy-Report-Only header. This allows the browser to send you reports about what your policy would have blocked without actually breaking any site functionality. Let this run for a week or two to gather a complete inventory of all the scripts, styles, and resources your site legitimately uses.

Example of a good, strict starting policy, using report-only and reporting to CentralCSP.com

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

Step 2: Collect all violations reports

Use a reporting tool like CentralCSP.com to collect all the CSP violations reports and see what has been blocked.

Step 3: Use a CSP builder to generate a policy

By using our CSP builder, you can generate a policy based on the reports collected. This way you can be sure to get all the resources that are allowed to be loaded. The builder will ask you aditional questions to make sure all the ressources added are needed by your website.

Learn how to use the CSP builder here.

When all the value has been reviewed, you can copy & deploy the policy in report-only mode to make sure it's working as expected.

Step 4: Eliminate 'unsafe-inline' & other unsafe keywords

The 'unsafe-inline' keyword allows the execution of scripts that are directly embedded in your HTML, such as:

Inline <script>...</script> blocks
Inline event handlers like onclick="..."

Allowing 'unsafe-inline' is a primary vector for Cross-Site Scripting (XSS) attacks.

Remediation:

Move all inline JavaScript code into external .js files.
Replace inline event handlers (e.g., onclick) with addEventListener calls in your external scripts.

If you need more information about unsafe-inline, you can read our article about it:

Learn more about unsafe-inline

The 'unsafe-eval' keyword allows the use of dangerous JavaScript functions such as eval(), which can execute arbitrary code and significantly increase your risk of XSS attacks.

Remediation:

Audit your codebase for any use of eval() and replace it with safer alternatives, such as JSON.parse() for parsing JSON data.
Ensure that you are using production builds of third-party frameworks, since development builds may depend on eval() and introduce vulnerabilities.
Avoid including libraries or plugins that require 'unsafe-eval' unless absolutely necessary, and seek out safer alternatives whenever possible.

Note : Each framework and library has its own way to handle CSP. Make sure to check the documentation of the framework or library to see if they allow you to get ride of the unsafe value.

Step 5: Check that your CSP is good to go using our CSP Scanner

Our audit tool will check your policy and give you a report of all the unsafe value found. Make sure you get ride of them or acknowledge the risk.

Scan your policy with our CSP Scanner.

Step 6: Deploy and keep monitoring

Once your policy is good to go, you can deploy it in production. However, you should keep monitoring it to make sure it's working as expected. Make sure to monitor the report regularly or after any update.

The takeaway: proactive security is the new standard

The BitSight RAU25 update is a clear signal that the era of "check-the-box" security is over. Your security rating is now directly tied to the fundamental hygiene of your software development and deployment practices. An effective Content Security Policy is no longer optional; it's a mandatory control with a direct and significant impact on your score. By understanding the new requirements and leveraging modern tools like CentralCSP.com, you can navigate this new landscape and maintain a strong, defensible security posture.

Continue Reading

JSONP and Content Security Policy

Learn what is the JsonP endpoint and what is the impact of using it with CSP. See how to avoid using JSONP endpoint and how it can be used to bypass CSP.

2025-06-08

10 min read

Theotime Quere