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.
Navigation
- Risk Vector Availability
- Risk Vector Integration
- Risk Vector Functionality
- Relation with Other Risk Vectors
- Scanning and Update Process
- Grading
Risk Vector Availability
When will Web Application Security be available?
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 will only begin impacting the rating after a Rating Algorithm Update. Our current tentative timeline for that to happen is in the second half of 2024. There is no commitment on that date at the moment, but it will never be before this date.
Risk Vector Integration
Will Web Application Security be included in the Risk Remediation Plan?
You will eventually be able to generate a Risk Remediation Plan (RRP) for this risk vector. We have not yet defined the timeline for this integration. At the moment of General Availability, no data analytics features are available; this means that RRP, Forecasting, and Peer Analytics do not include Web Application Security at the time of publication.
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. For example, in the Javascript Libraries with Known Vulnerabilities assessment, we list all javascript libraries that we could identify within a web application. Those marked with Pass are libraries in use but not known to contain any vulnerability, while those marked with Failed are libraries in use with at least one vulnerability. Another good example is the Cross-Domain Subresource Integrity Check assessment. In this case, those marked with Failed do not define the integrity attribute, while those marked as Pass 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.
Relation With Other Risk Vectors
What will happen to Web Application Headers?
The Web Application Security risk vector can be seen as an evolution of the Web Application Headers risk vector and will eventually replace it. However, they will be available in the portal simultaneously in the next few months. WAS is planned to replace WAH in the headline rating in an upcoming RAU. No estimate on the weight for this risk vector is available at this time.
There is one assessment related to TLS errors. How does it relate to SSL/TLS Configurations and Certificates risk vectors?
The TLS/SSL Certificates and Configuration 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
Can users request for a finding to be refreshed?
Yes. Users can use the standard refresh workflow available in the portal. Once a refresh is requested, the entire domain will be rescanned and all associated findings will be updated.
Are we 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.