In its lifespan, Mozilla’s HTTP Observatory tool has scanned over 6.9 million websites, providing useful, actionable insights into how developers can improve web security and guard their sites against would-be attackers.

The HTTP Observatory tests website compliance with security best practices, mainly concerning the correct usage of HTTP headers. When a scan is complete, it provides a report to tell the user how well their site is doing, with an overall score and grade, and links to documentation explaining what they need to do to improve their security.

Today, we are delighted to announce that the HTTP Observatory’s new home is MDN! This blog post explains a little bit of the history behind the tool, how we got to where we are now, what the migration means for Observatory and MDN, and what Observatory tests.

Check out the new HTTP Observatory now.

A brief history of 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.

Moving the HTTP Observatory to MDN

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.

What does the HTTP Observatory test?

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.

FAQ

Should I implement all recommendations?

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.

If I get an A+ grade, does that mean my site is secure?

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.

Can I scan non-websites, such as API endpoints?

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:

HTTPCopy to Clipboard

Content-Security-Policy: default-src 'none'; frame-ancestors 'none'
Strict-Transport-Security: max-age=63072000
X-Content-Type-Options: nosniff

Can other people see my test results?

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.

When did the move occur?

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.