This measurement is meant to surface issues whereby a site redirects to a domain in a way that limits the security provided by HTTPS and HSTS headers. This leaves users vulnerable to being redirected to a spoofed or malicious version of the site.
The site sends a redirect response to the browser, redirecting it from HTTP to an HTTPS site at a different domain or subdomain. This prevents the browser from receiving an HSTS header for the original domain, as browsers ignore HSTS headers sent over plain HTTP, and the header for the new secure domain doesn't apply to the original domain. A correctly set HSTS header will prevent an attacker from intercepting and maliciously modifying the redirection to the new domain in the future.
Example request chain:
In the preceding request chain, the redirect occurs with a 302 (Temporary Redirect) to HTTPS but increases the risk of a Man-in-the-Middle (MITM) attack because a 301 (Permanent Redirect) is not used.
When a 301 response code is returned by a GET request to the root page of a web server, check the location response header against the following decision table.
|http://example.com||https://example.com||Yes, if https://example.com has a HSTS header|
|http://example.com||https://www.example.com||No, example.com will never send a valid HSTS header to the browser.|
|http://example.com||https://example.net||No, example.com will never send a valid HSTS header to the browser.|
|http://www.example.com||https://example.com||Yes, but only if https://example.com has a HSTS header set with the includeSubDomains flag. As such, we recommend a more straightforward redirect approach, for simplicity.|
Any HTTP site should redirect the browser to a secure (HTTPS) version of the same domain that was originally requested (or a higher-level version of that same domain). For example, http://www.example.com should only redirect either to https://www.example.com or https://example.com. This redirect should precede redirection to any other domain or subdomain.
How can this issue be resolved?
- I have fixed this
- Redirect to the final URL that is the same domain as the initial URL, preferably with HSTS in place. Validate with any redirect checker or at the command line with cURL (example: "curl -Il http://example.com>).
- I have a compensating control
- If a final URL is a different domain than the initial URL, a 301 redirect must be employed and the final URL should have HSTS in place with the includeSubDomains directive.
- This is not my IP or domain
- If the asset (IP or domain) is not owned by your organization, please submit evidence.
- I cannot reproduce this issue and I think it’s incorrect
- Choose this option if you feel that SecurityScorecard is reporting this issue incorrectly and you have not made an attempt yet to correct the issue in your environment. Please do your due diligence in validation. Validate with any redirect checker or at the command line with cURL (example: "curl -Il http://example.com) before submitting.