Introducing the MDN HTTP Observatory

In 2016, then-Mozilla security engineer April King announced the original release of the HTTP Observatory tool. Originally conceived as an internal testing tool to help Mozilla developers apply security best practices to their own websites, the HTTP Observatory was packaged into a website that anyone could use after April looked in dismay around the web and saw how few sites were applying those best practices.

Since then, HTTP Observatory has exploded in popularity, with over 6.9 million websites being scanned a total of 47 million times! Mozilla's Infrastructure Security Team has regularly maintained the tool to improve the service, adding new tests as security best practices and standards are updated, and removing tests related to older technologies as they become obsolete.

That isn't the full story, however. The success of the HTTP Observatory hinges on two things.

• First of all, the site gamifies the process of improving website security — each set of test results comes with a score and a grade, and developers over the years have shown great enthusiasm about achieving that sometimes-elusive A+ Observatory rating!
• Second, HTTP Observatory helps developers make sense of website security requirements — which can often be rather opaque and difficult to understand — by providing understandable feedback on how to fix issues highlighted by its dozen or so tests. Related documentation can be found all in one place.

So what prompted the move to MDN? The short answer is that MDN and HTTP Observatory complement each other very well — they both have developer education and improving the health of the internet as core driving principles.

The longer answer is that HTTP Observatory is a well-respected tool in the web and security communities, but it hasn't seen a major update for quite some time. Mozilla decided that the tool deserved to evolve and find new audience members to benefit from the security knowledge contained within.

MDN is a popular site with a large audience of web developers who could benefit from this knowledge, so it seemed like a perfect new home. In addition, our team was very excited to update the tool's UI, functionality, and documentation, bringing it up-to-date and giving it some polish. This update was done in collaboration with Mozilla's Infrastructure and Security Risk teams; they provided expert advice to help us update the HTTP Observatory tests and documentation with confidence.

See the HTTP Observatory on MDN, and the Practical security implementation guides that accompany it.

The HTTP Observatory tests the following security features:

• Secure cookie configuration: Access to cookies should be locked down as much as possible, to prevent attacks such as Cross-site scripting (XSS) and Cross-site request forgery (CSRF).
• Cross-origin Resource Sharing (CORS): Limit cross-origin resource access to no more than necessary.
• Content Security Policy (CSP): Provides fine-grained control over the locations from which resources on a site can be loaded.
• Strict-Transport-Security: Enforces site connections via HTTPS only, to prevent manipulator-in-the-middle (MiTM) attacks.
• Correct redirection behavior to HTTPS on initial loading: Prevents attacks during initial loading.
• Referrer-Policy: Prevents leaking of sensitive information.
• Subresource Integrity (SRI): Verify that fetched resources are delivered without unexpected manipulation.
• X-Content-Type-Options: Enforce correct resource MIME types, to further mitigate XSS attacks.
• Content-Security-Policy: frame-ancestors and X-Frame-Options: Limit the ability of other sites to embed your site in an <iframe>, helping to prevent clickjacking.
• Cross-Origin-Resource-Policy: Prevent certain requests from other origins accessing resources on your site, to mitigate speculative side-channel attacks like Spectre.

Yes, you should do it if possible. There is no way to programmatically determine the risk level of any given site. However, while your site may not be high-risk, it is still worth learning about the defensive security standards highlighted by Observatory, and implementing them wherever you can.

We'd love to say that any site that gets an A+ Observatory grade is perfectly secure, but there are a lot of security considerations that we can't test. Observatory tests for preventative measures against Cross-site scripting (XSS) attacks, manipulator-in-the-middle (MiTM) attacks, cross-domain information leakage, insecure cookies, Content Delivery Network (CDN) compromises, and improperly issued certificates.

However, it does not test for outdated software versions, SQL injection vulnerabilities, vulnerable content management system plugins, improper creation or storage of passwords, and more. These are just as important as the issues Observatory does test for, and site operators should not be neglectful of them simply because they score well on Observatory.

The HTTP Observatory is designed for scanning websites, not API endpoints. It can be used for API endpoints, and the security headers expected by Observatory shouldn't cause any negative impact for APIs that return exclusively data, such as JSON or XML. However, the results may not accurately reflect the security posture of the API. API endpoints generally should only be accessible over HTTPS. 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

Anyone can choose to scan any domain, and the scan history for each domain is public. However, HTTP Observatory does not store user data related to each scan. In the old version of HTTP Observatory, users could choose to set their scan to "public" or keep it private (the default), and there was a "recent scans" list where domain names were listed. "Recent scans" was the main feature that users would potentially wish to opt-out from, but it is no longer supported, hence there is now no reason to provide the "public" flag.

The new HTTP Observatory was launched on MDN on July 2, 2024. The old Mozilla Observatory — containing HTTP Observatory plus other tools like TLS Observatory, SSH Observatory, and Third-party tests — has been deprecated and will be sunset in September 2024.

The MDN team has:

• Updated the user experience to improve the site's look and make it easier to use. For example, the recommendations highlighted by the test results are all shown together, instead of one at a time.
• Updated the accompanying documentation to bring it up to date and improve legibility.
• Changed the "rescan" checkbox and its underlying mechanics:
  • There is no longer a rescan parameter.
  • A site can only be scanned and a new result returned every 60 seconds.
  • Deep-linking into a report initiates a rescan if the previous scan data is older than 24 hours.
• Updated the tests to bring them up-to-date with latest security best practices:
  • Removed the out-of-date X-XSS-Protection test.
  • Removed the out-of-date Flash and Silverlight (clientaccesspolicy.xml and crossdomain.xml) embedding tests.
  • Added a Cross-Origin-Resource-Policy (CORP) test.
  • Updated the Referrer-Policy test to update the score modifier for referrer-policy-unsafe and remove the referrer-policy-no-referrer-when-downgrade result.

Not yet. The API will continue using the old test infrastructure for a while, therefore you will see some small differences between test scores returned by the API and the website. The API will be updated to use the new tests in a near-future iteration.

The previous Observatory site included specific results tabs containing TLS and certificate analysis data. The new one does not, and there are currently no plans to include these features: it provides a clear focus on HTTP data.

This test is checking whether your web server is making its initial redirection from HTTP to HTTPS, 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

As long as you are explicit about your preference by using the Content-Security-Policy frame-ancestors directive, you will pass the X-Frame-Options test. For example, to allow your site to be framed by any HTTPS site:

Content-Security-Policy: frame-ancestors https:

We would love you to try out the HTTP Observatory on MDN! Visit it now, scan your site, and fill out our HTTP Observatory survey to let us know what you think of the experience.

HTTP Observatory's documentation, which is linked from the test results, is now also found on MDN, in our Practical security implementation guides section. Again, read through it and let us know how it can be improved.