⇤ How is the Diligence Risk Category Calculated?
In these assessments, we ensure the application design includes controls to reduce the exposure of critical and sensitive information.
Table of Contents
- Secure Cookie Set on an Insecure Channel
- Session Token in URL
- Mixed Content
- HSTS Preload Directive Present
- Cookie SameSite Attribute
- Cookie SameSite Blocked
- Unsafe Referrer Policy
Secure Cookie Set on an Insecure Channel
The Secure flag instructs the browser to never pass a cookie over an insecure (e.g. non-HTTPS) channel; however, occasionally some websites set these cookies over insecure channels, defeating the purpose of the Secure flag. Some modern browsers will even ignore secure cookies set over an insecure medium.
Framework References
Organization | Framework |
---|---|
OWASP | A02:2021 - Cryptographic Failures |
CWE | CWE-319: Cleartext Transmission of Sensitive Information |
Grading
These findings are always NEUTRAL; they do not impact your rating.
Mitigation
Website owners should ensure their site is accessible through a secure connection. If that is not possible, they should ensure that the application does not depend on cookies with the Secure flag set.
Session Token in URL
Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked, or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.
Framework References
Organization | Framework |
---|---|
OWASP | A04:2021 - Insecure Design |
CWE | CWE-598: Use of GET Request Method With Sensitive Query Strings |
Grading
We issue and informational finding (NEUTRAL) when we find tokens that may be used as session identifiers being passed in a URL field.
These findings are always NEUTRAL; they do not impact your rating.
Mitigation
Even if this is an informational finding, users are advised to ensure that no session identifiers or otherwise sensitive information are passed via URL GET parameters.
Mixed Content
Some websites will load insecure resources using HTTP even though the sites are being served over HTTPS. This is a security risk.
Framework References
Organization | Framework |
---|---|
OWASP | A02:2021 - Cryptographic Failures |
CWE | CWE-319: Cleartext Transmission of Sensitive Information |
Grading
Whenever an HTTPS website is visited, we list every resource that is insecure content (HTTP). Depending on the type of content, a web browser may block it from loading (blocked) and try to load it via a secure channel (HTTPS) (upgraded).
Usually, the content that is blocked is more security sensitive, so we grade mixed content events using the following scale:
Mixed Content Event Status | Description | Weight |
---|---|---|
Content Upgraded | The resource was automatically upgraded to HTTPS | 0.1 |
Content Warning | The resource could not be upgraded to HTTPS and was made available using HTTP (excluding insecure FORM resources) | 1.0 |
Content Blocked | The resource could not be upgraded to HTTPS and was blocked by the browser (including insecure FORM resources) | 10 |
For each website, we add the weights of these events and calculate a mixed content score, issuing the following grades based on its value:
Condition | Grade |
---|---|
mixed_content_score >= 10 | BAD |
1 <= mixed_content_score < 10 | WARN |
Mixed_content_score < 1 | FAIR |
Mitigation
The best strategy to avoid mixed content blocking is to serve all content as HTTPS instead of HTTP. Website owners should ensure that every resource loaded from an HTTPS website is loaded securely.
HSTS Preload Directive Present
HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking.
It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.
Framework References
Organization | Framework |
---|---|
OWASP | A02:2021 - Cryptographic Failures |
CWE | CWE-319: Cleartext Transmission of Sensitive Information |
Grading
Condition | Grade |
---|---|
The Strict-Transport-Security header is set with the preload directive. | GOOD |
Mitigation
Website owners should configure HSTS headers correctly.
Cookie SameSite Attribute
SameSite attributes prevent cookies from being passed to cross-origin browsing contexts and are one mitigating technique to prevent cross-site request forgery.
Framework References
Organization | Framework |
---|---|
OWASP | A01:2021 - Broken Access Control |
CWE | CWE-1275: Sensitive Cookie with Improper SameSite Attribute |
Grading
These findings are always NEUTRAL; they do not impact your rating.
Mitigation
In general, session and other tracking cookies should be explicit about how permissive the use of the cookie can be across origins. The current default behavior on most modern browsers is SameSite=Lax, which may be too permissive for session cookies on some web applications.
Cookie SameSite Blocked
The SameSite cookie attribute allows website owners to restrict where and when cookies may be sent. It allows for greater control over the use of third-party tracking cookies on a given website and helps to prevent attacks such as Cross-Site Request Forgery (CSRF).
Framework References
Organization | Framework |
---|---|
OWASP | A01:2021 - Broken Access Control |
CWE | CWE-1275: Sensitive Cookie with Improper SameSite Attribute |
Grading
Condition | Grade |
---|---|
No issues with blocked cookies exist. | GOOD |
At least one of the following issues exists:
|
FAIR |
Mitigation
As of July 14, 2020, Google Chrome and most browsers have adopted the default cookie policy of SameSite=Lax. This means that for third-party cookies to be sent when loading external resources, they need to be explicitly set with the SameSite=None policy as well as the secure flag to be loaded.
Unsafe Referrer Policy
The Referrer-Policy header tells the browser what referrer information should be passed on to navigation. In some policy configurations, sensitive user data may be leaked outside of secure channels.
Framework References
Organization | Framework |
---|---|
OWASP | A02:2021 - Cryptographic Failures |
CWE | CWE-319: Cleartext Transmission of Sensitive Information |
Grading
We scan each website looking for the Referrer-Policy: unsafe-url
header.
This header specifies that this website will pass its referrer information in full to other linked sites, including any query parameters, if present.
We issue a single FAIR finding for websites containing the unsafe-url Referrer Policy.
Condition | Grade |
---|---|
The website contains the unsafe-url Referrer Policy. | FAIR |
Mitigation
Website owners should avoid leaking internal URLs to third parties when possible.