Web Application Security Status and FAQ – June 24, 2025

The Web Application Security risk vector performs multiple assessments related to web application security. It provides information about components with known vulnerabilities, broken authentication and access control, sensitive data exposure, cross-site scripting prevention mechanisms, and security misconfigurations.

You can find the answers to some of our most frequently asked Web Application Security questions below.

Risk Vector Availability

When was Web Application Security released?

Web Application Security has been available in Bitsight applications since September 7th, 2023, as a non-rating impacting risk vector.

When will it begin impacting the rating?

Web Application Security remained a non-rating-impacting risk vector for over one year after launch (September 2023). It will begin impacting the rating with the RAU25, scheduled for July 10th, 2025.

Risk Vector Integration

Is Web Application Security included in Risk Remediation?

Web Application Security has been available in Risk Remediation since the start of the RAU25 preview (April 8, 2025). It will be available in Forecasting and Peer Analytics at a later stage.

Risk Vector Functionality

What do failed and passed evidence mean?

All assessments provide a list of the evidence that was collected when performing it on a specific web application. We reference both negative indicators and correct implementations of the security controls we are evaluating. The Pass and Failed status for each piece of evidence highlights this.

Examples:

• In the Javascript Libraries with Known Vulnerabilities assessment, we list all javascript libraries that we could identify within a web application. Those marked as Passed are libraries in use but not known to contain any vulnerability, while those marked as Failed are libraries in use with at least one vulnerability.
• In the Cross-Domain Subresource Integrity Check assessment, those marked as Failed do not define the integrity attribute, while those marked as Passed define it.

Not all assessments provide a mix of Failed and Pass evidence. Some may only provide Failed evidence (e.g., Content Security Policy Violations or Cookie SameSite Blocked) since we can only see negative results. Others may only provide Pass evidence (e.g., HSTS Preload Directive Present) since we only consider this control to impact a web application's security positively. However, the meaning is always the same: a Pass evidence represents a good implementation of the security control we are evaluating, while a Failed evidence means an invalid or non-existent security control implementation.

Is it possible to export the information in the Evidence tab to CSV?

Yes. To export Evidence details, first select the Evidence column in the Customize Columns option in the Findings Table. Then, use the Download CSV feature to download all the data, including the evidence details.

Relation With Other Risk Vectors

What will happen to Web Application Headers?

The Web Application Security (WAS) risk vector can be seen as an evolution of the Web Application Headers (WAH) risk vector and will eventually replace it. However, they will be simultaneously available in Bitsight for some time. WAS is planned to replace WAH in the headline rating in the RAU25, scheduled for July 10, 2025, with the same weight of 5%. After the RAU25, the Web Application Headers risk vector will remain in Bitsight and we will still generate findings for some time. After a while, we’ll stop generating findings and will eventually remove the risk vector from Bitsight.

How does the TLS Errors on Page Resource Fetch assessment relate to TLS/SSL Configurations and TLS/SSL Certificates risk vectors?

The TLS/SSL Certificates and TLS/SSL Configurations risk vectors evaluate the strength and effectiveness of certificates used within your web applications. The TLS Errors assessment within Web Application security assesses the validity of certificates of third-party servers that are providing resources to your web application.

Scanning and Update Process

How is scanning performed for Web Application Security?

The Web Application Security risk vector uses a headless web browser to gather information about web servers and applications to perform assessments related to the security controls implemented. With this scanner, we render and understand HTML the same way a browser would, and we gather information such as:

• HTTP headers.
• Content Security Policies.
• Web application components and version detection (e.g. JavaScript libraries).
• Web page contents and their security context (e.g. HTTP resources loaded from an HTTPS context).
• Internet-accessible administration pages (e.g. admin portals for Wordpress, Drupal, and other Content Management Systems).

More information: Understanding and Troubleshooting Web Application Security Scanning

Can I request for a finding to be rescanned?

Yes. Users can use the standard rescan workflow available in Bitsight. Once a rescan is requested, the entire domain will be rescanned and all associated findings will be updated.

Is Bitsight sending any payload while performing the 22 assessments?

No. We only make a standard HTTP request (similar to any browser) and run the assessments on the responses we collect.

Grading

How was the severity of each assessment determined?

We determined the severity of each assessment by evaluating the Common Weakness Enumeration (CWE) that each assessment is targeting. Our Security Research team proposed the individual severity of each assessment based on the possible impacts and exploitability of each weakness. We then did a small-scale validation (~15M domains) on the prevalence of these issues on entities with known breaches that confirmed these severities.

We are currently working on performing this assessment again with a much larger number of domains.

How does severity affect the finding grade?

Severity is a static attribute that each assessment has. It was used to determine the maximum impact that a specific finding can have.

Risk Vector Assessment Details

JavaScript Libraries with Known Vulnerabilities

What does Bitsight assess?

We assess whether the web application is loading versions of JavaScript libraries known to contain vulnerabilities. We have a mechanism to detect if a commonly used library has been patched by comparing the loaded library with known vulnerable versions.

We do not, however, check if the vulnerability is being exploited (i.e., if the vulnerable function is being called) or if there are other mitigating measures, such as specific configurations that might avoid using the vulnerable code.

For each detected library, we create one evidence and assign it a Failed or Passed status depending on whether the library version is known to have vulnerabilities.

What is the risk?

Loading a vulnerable library in a web application introduces risk, as the vulnerability may be accidentally or intentionally exploited. Even if the vulnerability is not actively being exploited, the fact that it is present makes it vulnerable to being exploited in the future.

The recommendation from OWASP Top 10 is to avoid using vulnerable libraries by updating, patching, or removing them.

How are the libraries detected?

Library versions are identified through a combination of methods, including analyzing library names, detecting version identifiers within the code, and utilizing pattern recognition.

Why does some evidence not include the resource?

Depending on the method used to detect the library, sometimes we are not able to collect the resource. Therefore, the detections are still considered valid in those instances. We’re just not able to pinpoint the file that contains the library (that is usually a bundle). Analyzing the source code by searching for the library name and version should allow us to identify the source.

How can I check the vulnerable libraries being loaded into my web application?

We provide information about all the libraries we detect, along with their version and the source path (in most cases). This information can help identify a specific vulnerable library so you can apply the necessary measures to remove the vulnerability.

Other tools that may be helpful are the Wappalyzer - Technology profiler Chrome extension and the RetireJS library.

How can I check if a vulnerability was removed after I remove, update, or patch the library?

After the vulnerability is addressed and once we rescanned the web application, check in Bitsight if that specific version of the library is no longer listed in the evidence or if it is listed with a status of Passed. This means that we haven’t detected the vulnerable library version or we detected that the vulnerability has been removed.

Cross-Domain Subresource Integrity Check

What does Bitsight assess?

We assess whether external resources include a valid integrity attribute. The grade is based on a weighted observation of vulnerable (no SRI) vs. not vulnerable (has SRI) resources.

How can I check the Cross-Domain Subresource Integrity setting in my web application?

Use Chrome Developer Tools to inspect script tags and confirm presence of the integrity attribute.

Cross-Domain Subresource Integrity Failure

What does Bitsight assess?

We assess if there are any integrity mismatches where a provided SRI hash does not match the actual script content.

How can I check the cross domain subresource integrity failures in my web application?

Use Chrome Developer Tools (Console) to detect any errors related with any failure to find a valid digest in the 'integrity' attribute for a resource.

Content Security Policy Configurations

What does Bitsight assess?

We assess whether the web application includes an effective CSP configuration that helps prevent cross-site scripting and dynamic content injection attacks. We adhere to best practices set forth by Google via the CSP Evaluator project, which align also with the OWASP Top 10.

Our assessment focuses on the following criteria, which help protect against the attacks mentioned earlier:

• Existing and properly formatted CSP configuration;
• Presence of the `default-src`, `script-src`, and `object-src` directives;
• No use of 'unsafe-inline' or 'unsafe-eval' (or complementary use of nonces or hashes in `script-src`);
• No use of wildcards or allow lists;
• No use of plain URL schemes in certain directives.

We evaluate only CSP policies included in content-security-policy headers and Content-Security-Policy meta tags. We do not evaluate content-security-policy-report-only headers.

What is the risk?

A non-existent or ineffective CSP policy leaves a web application vulnerable to attacks such as cross-site scripting and dynamic content injection. These can cause severe damage, including sensitive data theft, session hijacking, and malicious content execution.

How are the CSP configurations detected?

We detect CSP policies that are defined via HTTP headers, HTML metatags, or both. Multiple policies are interpreted cumulatively, with stricter policies taking precedence.

How can I check the CSP configuration in my web application?

Use Chrome Developer Tools to check for CSP configurations defined in the HTTP headers or HTML metatags.

How can I check if a CSP configuration is effective?

Use tools such as the CSP Evaluator to check if the CSP configuration is properly and effectively configured (i.e., it does not include syntax or other errors that may render it unusable).

Our evaluation of CSP configurations may differ from the evaluation performed by other tools, such as CSP Evaluator. Make sure to check the evidence that we collect in Bitsight and its Failed or Passed status.

Content Security Policy Violations

What does Bitsight assess?

We assess whether the website content and security policies are incongruent, by checking if any CSP violation error is thrown by the browser. Only non-report-only violations count toward grading.

What is the risk?

While the CSP configuration might effectively block a resource from being loaded or used, the fact that a CSP violation error is thrown means that the website content and security policies are misaligned and this can lead to unexpected application behaviors.

Having any unresolved CSP violations is not considered a best practice and can lead to alert fatigue, which will prevent the detection of actual threats.

How are the CSP Violations detected?

We detect CSP violation errors thrown by the browser. Report-only violations do not count towards the grade but serve as informational data to test the CSP implementation without risking functionality.

How can I check the CSP Violations in my web application?

Use Chrome Developer Tools (Console) to check for CSP Violation errors.

How can I check if a CSP configuration is congruent with the web application?

When the web application does not throw CSP violation errors, its behavior and CSP configurations are aligned.

HTTPS to HTTP Redirects

What does Bitsight assess?

We assess whether there is an insecure redirect, from a secure location (HTTPS) to an insecure one (HTTP) in the redirect chain.

What is the risk?

When performing an insecure redirect, any sensitive information that might have previously been transmitted as encrypted may be accessible without encryption.

How are the HTTPS to HTTP redirects detected?

We check all the redirects that occur from the initial domain to the final one and flag any redirects that are insecure.

How can I check the HTTPS to HTTP redirects in my web application?

In Bitsight, check the Evidence tab for an HTTPS to HTTP redirect finding (check the Responses detail) for information about the complete redirect chain, which that allows to understand the issue:

• The first domain in the redirect chain where the connection started.
• The HTTPS domain where the insecure redirect happens. The next redirect is to an insecure domain; this will be the domain used to generate a finding (the finding evidence).
• The insecure domain to which the connection is redirected.

Depending on the website configurations, different initial domains can lead to different behaviors that might not always result in insecure redirects. Always refer to the first domain in the redirect chain to follow the chain of redirects that lead to the insecure behavior.

It may also be useful to use Chrome Developer Tools, starting a browser navigation from the first domain indicated in the evidence. Then, use the Network tab to confirm there is a redirect from an HTTPS address to the address indicated in the Value in the Evidence, which is HTTP.

How do I check if a HTTPS to HTTP redirects has been fixed?

After the insecure redirect is addressed and once we rescanned the web application, check in Bitsight if that specific hostname where the insecure redirect was detected no longer presents evidence of insecure redirects.

Internal Server Error

What does Bitsight assess?

We assess whether the web application returns an HTTP 500-series error (e.g., 500, 502, 503, 504) during the scanning process. These indicate unhandled exceptions or issues occurring on the server side during normal operation.

What is the risk?

While a 500 error may not directly expose sensitive data, it reveals that the application is not properly handling certain inputs or conditions. This can:

• Signal poor resilience or lack of input validation,
• Lead to inadvertent information disclosure through verbose error messages,
• Provide clues to attackers about the underlying infrastructure.

How can I check for internal server errors in my web application?

Use Chrome Developer Tools (Console or Network) tab to observe if HTTP 500-series status codes appear in the loaded page. Review server logs to identify and resolve the root causes by ensuring proper exception handling. Consider implementing custom error responses that don’t expose internal application details.

CORS Violation

What does Bitsight assess?

We assess whether cross-origin resource sharing (CORS) requests made by the web application are being blocked due to misconfigured or overly restrictive CORS headers. We count unique error messages per domain to identify issues with how cross-origin requests are handled.

What is the risk?

Improperly configured CORS headers can:

• Break critical cross-origin functionality, including loading resources from APIs or CDNs;
• Lead to silent failures in JavaScript execution;
• Result in degraded application functionality or unexpected behavior for end users.

How can I check for CORS Violations in my web application?

Use Chrome Developer Tools (Console) to inspect for CORS-related errors. Verify your server's Access-Control-Allow-Origin and other related headers (e.g., Access-Control-Allow-Methods, Access-Control-Allow-Headers).

Overly Permissive CORS Whitelist

What does Bitsight assess?

We assess whether the web server responds with an Access-Control-Allow-Origin header that includes a wildcard value (*), allowing any origin to access the resource.

What is the risk?

Using a wildcard in CORS headers creates a highly permissive environment where any external site can interact with your resources, which can:

• Lead to unauthorized access to APIs,
• Increase the risk of data leakage,
• Weaken the overall access control of your web services.

How can I check for overly permissive CORS whitelist in my web application?

Use Chrome Developer Tools (Network tab) to inspect the response headers of your web application. Look for the Access-Control-Allow-Origin header. If its value is *, update your configuration to restrict it to only trusted domains.

Directory Listing Exposure

What does Bitsight assess?

We assess whether a web application exposes directory listings. If a user visiting a folder path (like /assets/) sees a list of files instead of being redirected or served a default page.

What is the risk?

Exposing a directory listing can:

• Reveal the structure of your application,
• Disclose unlinked or sensitive files (e.g., debug logs, old scripts),
• Provide attackers with additional attack surface and reconnaissance information.

How can I check for directory listing exposure in my web application?

Manually test known folder paths in your application (e.g., /assets/, /uploads/, /admin/):

• If the browser shows a list of files and folders, the directory listing is enabled.
• Disable directory browsing in your web server settings (e.g., disable autoindex in Nginx or Options Indexes in Apache).