Mozilla Observatory Integration with DefectDojo

Mozilla Observatory Integration with DefectDojo

Mozilla Observatory (the HTTP Observatory) is a free scanner that checks how well a website uses HTTP security headers and related browser protections. It tests a site's Content Security Policy, cookie flags, cross-origin resource sharing, HTTP Strict Transport Security, redirection to HTTPS, Referrer Policy, Subresource Integrity, X-Content-Type-Options, and X-Frame-Options, scores each test, and gives the site a letter grade. Mozilla's original service and its JSON API were retired in 2024, and the HTTP Observatory is now hosted by MDN Web Docs with a new Node.js scanner. DefectDojo imports Observatory results in JSON.

Mozilla Observatory Integration with DefectDojo

We use Mozilla Observatory results as a quick, repeatable check of the header and transport settings on our public sites, and DefectDojo is where those results get owners. A letter grade is useful for a dashboard, but it doesn't tell a web team which header to fix first or remind anyone when a regression slips in. Imported into DefectDojo, each Observatory test becomes a Finding with a severity based on its score penalty, so failing tests land in the right queue with an SLA, and passing ones are recorded as inactive.

Why Mozilla Observatory Matters

Security headers are cheap to deploy and easy to break. A CDN change, a new reverse proxy, or a framework upgrade can remove a header without anyone noticing.

• The Observatory checks the protections browsers enforce, such as CSP and HSTS, which reduce the impact of content injection and downgrade attacks.
• Each test reports the expected result and the actual result, so the fix is usually clear.
• Scores are weighted by impact, which gives a reasonable starting point for prioritization.
• It is free and fast, so teams can run it against every public hostname they own.
• On its own, a grade has no history. You can't tell when a header disappeared or how long it has been missing.

Advantages of This Integration

What we gain by sending Observatory results through DefectDojo:

• Severity from score penalties. The parser converts each test's score modifier into Low, Medium, or High, so the tests that cost the most points get the shortest SLA.
• Passing tests recorded, not lost. Tests that pass come in as inactive Findings, so the Test shows what was checked as well as what failed.
• Regression detection. Reimporting a new scan into the same Test mitigates issues that were fixed, adds new ones, and reactivates any header problem that returns.
• Ownership. Failing tests can be assigned to the web or platform team that owns the site, discussed in notes, risk-accepted, or pushed to Jira.
• Context with other web results. Observatory Findings sit on the same Asset as DAST and pentest Findings for the site, so header issues are part of the application's overall picture.

How This Integration Works

DefectDojo imports these results with the Mozilla Observatory Scan scan type.

1. Get a JSON result in the supported layout. The parser was built for the JSON produced by the original Mozilla HTTP Observatory tooling. It accepts either a plain object of test results keyed by test name, or an object with scan and tests keys, where each test has score_description, score_modifier, result, expectation, and pass.

The current MDN HTTP Observatory CLI (mdn-http-observatory-scan example.com) also returns scan and tests, but its per-test fields use camelCase names such as scoreModifier and don't include score_description. That output doesn't match what this parser reads, so test a sample from your scanner before building automation around it.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Mozilla Observatory Scan, and upload the file. For automation, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Mozilla Observatory Scan" \
  -F "file=@observatory.json" \
  -F "product_name=marketing-site" \
  -F "engagement_name=Header Checks" \
  -F "test_title=www.example.com" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Mozilla Observatory Scan" \
  --report-path "./observatory.json" \
  --product-name "marketing-site" \
  --engagement-name "Header Checks" \
  --auto-create-context

3. Reimport per hostname. Keep one Test per hostname and send later results to /api/v2/reimport-scan/ against it, so fixes and regressions show up as status changes.

Data Granularity: What Gets Imported

The parser creates one Finding per Observatory test, whether it passed or failed.

The parser doesn't record the scanned hostname as an endpoint, and it doesn't import the overall grade, score, response headers, or the per-test output data.

Use Cases

For a portfolio of public sites: A team with 30 marketing and product hostnames scans each one weekly and reimports into a Test per hostname. A missing HSTS header on one site shows up as a new active Finding instead of a slightly lower grade nobody checks.

After infrastructure changes: When a site moves behind a new CDN or load balancer, a scan and reimport right after the cutover shows whether any headers were dropped along the way.

For CSP rollouts: Teams moving from no CSP to a strict policy can follow the Finding title as it changes from "not implemented" to an unsafe policy to passing, with the history kept in DefectDojo.

For baseline standards: Security teams that require a minimum set of headers can report on active Observatory Findings across all web Assets and see which teams are out of compliance.

Operational Tips

• Name each Test after the hostname with test_title. Findings carry no endpoint, so the Test name is the only place the scanned site is recorded.
• Expect inactive Findings for passing tests. Filter on active status in dashboards so passes don't inflate counts.
• Some failing tests have a score modifier of 0 and arrive as Info. Review them once and decide whether they matter for your sites.
• When a test's result changes (for example from "not implemented" to "implemented unsafely"), the title changes too. On reimport, the old Finding is mitigated and a new one opens, which is an accurate record of the change.
• Because this scan type uses the Legacy algorithm, reimport matches on title and severity. Keep one hostname per Test so identical titles from different sites don't collide.
• Confirm your scanner's JSON field names before automating, since the current MDN scanner's output differs from the layout this parser reads.