Unfortunately, there is no way to tell the risk level of any given site programmatically. While your site may not be at a high level of risk, the Observatory grades sites equally in an attempt to get site developers and operators familiar with these defensive security standards.
Note that while it may appear that some things — such as HTTPS or Subresource Integrity for sites that use CDNs — appear unnecessary, not including them puts users and the internet at large at risk.
While we'd love to say that any site that scores an A+ on the Observatory is perfectly secure, there's a lot more that goes making a website secure than what we can test. The Observatory tests for preventative measure against cross-site scripting attacks, man-in-the-middle attacks, cross-domain information leakage, cookie compromise, content delivery network compromise, and improperly issued certificates.
However, it does not test for outdated software versions, SQL injection vulnerabilities, vulnerable content management system plugins, improper password creation policies or storage procedures, and more. These are just as important as what the Observatory tests for, and site operators should not be neglectful of them simply because they score well on the Observatory.
The HTTP Observatory is designed around scanning websites, not API endpoints. This is not to say that it can't be used for API endpoints, just that the results may not reflect the actual security posture of the API.
Nevertheless, the various security headers expected by the HTTP Observatory shouldn't cause any negative impact for APIs that return exclusively data, such as JSON or XML. The recommended configuration for API endpoints is:
Content-Security-Policy: default-src 'none'; frame-ancestors 'none' Strict-Transport-Security: max-age=63072000 X-Content-Type-Options: nosniff
Hidden scans are simply marked as being hidden from home page lists such as the “Hall of Fame.” For users and organizations that need truly confidential results, it is recommended to download the Observatory scanner and run a private installation.
It is extremely difficult to assign an objective value to a subjective question such as “How bad is not implementing HTTP Strict Transport Security?” This is complicated by the fact that what may be unnecessary for one site — such as implementing Content Security Policy — might mitigate important risks for a different site.
The scores and grades offered by the Mozilla Observatory are designed to alert developers when they're not taking advantage of the latest web security features, as recommended in Mozilla's web security guidelines and server side TLS guidelines. Individual developers will need to determine which of these security technologies is right for their sites.
The current maximum possible score is 135 out of 100. The minimum score is always 0, regardless of how badly a site does.
For technical details, please see grade.py, and to see a list of the most recent “perfect” scoring websites, you can use the getRecentScans API.
Some tests award positive scores, such as +5 or +10 points. Why? Think of it as getting extra credit for going above and beyond the call of duty in defending your website.
These positive bonuses are specifically designed to encourage people to adopt new security technologies or tackle difficult implementation challenges. Over time, these bonuses may go away as baselines shift or new bonuses may appear as cutting-edge defensive security technologies are created. As these points are extra credit, they are only awarded if your site already achieves an A grade or better.
The following tests award extra credit points:
Secure, HttpOnly, and SameSite)'unsafe' declarations)X-Frame-Options (done via Content Security Policy)HTTP Public Key Pinning is targeted specifically towards large and/or sensitive websites and implementing it is considered optional. The only way to fail this test is to return an invalid header, such as one that doesn't contain a sufficient number of pins. Sites that do HPKP will get a small bonus on their final grade.
This test is checking whether your web server is making its initial redirection is from HTTP to HTTPS and on the same hostname before doing any further redirections. This allows the HTTP Strict Transport Security (HSTS) header to be applied properly.
For example, this redirection order is correct:http://example.com → https://example.com → https://www.example.com.
An incorrect (and penalized) redirection looks like this:http://example.com → https://www.example.com.
No problem! As long as you are explicit about your preference by using Content Security Policy's frame-ancestors directive, you will pass the X-Frame-Options test. For example, to allow your site to be framed by any https site, the following policy should pass the X-Frame-Options test:
Content-Security-Policy: frame-ancestors https:
A properly designed CSP policy that blocks the execution of inline JavaScript can accomplish everything that X-XSS-Protection can do and more. Sites with strong CSP policies that block inline JavaScript are therefore automatically opted out of the X-XSS-Protection test.
Note that X-XSS-Protection still provides some protection for older browsers — such as Internet Explorer — that do not support CSP. However, these protections should only be considered a weak defense against cross-site scripting attacks.
To reduce load on our third-party providers, the Mozilla Observatory always returns cached results from them. However, if you follow a link to your results for a third-party, most of them will offer the option to scan again. Their updated results will then be reflected in the Observatory.
ssllabs.com is a TLS/SSL scanner by Qualys that analyzes your combination of cipher suites, handshake methods, supported protocols, and resistance against a variety of TLS attacks and produces a grade that reflects how secure those choices are.
htbridge.com is a TLS/SSL scanner by High-Tech Bridge that analyzes your combination of cipher suites, handshake methods, supported protocols, and resistance against a variety of TLS attacks and produces a grade that reflects how secure those choices are. For sites that need it, it also tests your configuration against requirements set by HIPAA, NIST, and PCI-DSS.
tls.imirhil.fr is a TLS/SSL scanner by @aeris22. It is strongly forward-focused and tests for configurations that are not necessarily appropriate for general-purpose websites.
securityheaders.com is an HTTP header analyzer run by @Scott_Helme that performs scans similar to those done by the Mozilla HTTP Observatory, by testing HTTP headers. Why two sites that do the same thing? Well, when it comes to security, a second opinion can sure be handy!
hstspreload.org is the site run by Nick Harper that manages the HTTP Strict Transport Security (HSTS) preload list. The preload list is a directory of sites that have opted into having browsers connect to their website only over HTTPS, even before they have ever seen an Strict-Transport-Security HTTP header. This helps solve the trust-on-first-use issue, where a man-in-the-middle could prevent a user from ever upgrading to HTTPS and seeing the HSTS header.