DrHeader Integration with DefectDojo

DrHeader Integration with DefectDojo

drHEADer is an open source tool, released under the MIT license by Santander UK's security engineering team, that audits the HTTP security headers an application returns. It compares response headers such as Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy, and Cache-Control against a policy defined in a YAML rules file, and reports headers that are missing, present when they shouldn't be, or set to values the policy doesn't allow. It runs as a Python library or a command-line tool and can print results as JSON for a single URL or a bulk list of URLs.

DrHeader Integration with DefectDojo

We run drHEADer in our deployment pipeline because header regressions are easy to introduce and easy to miss: one proxy change and the HSTS header is gone. On its own, drHEADer gives us a pass or fail list for the URLs we just checked. Importing its JSON into DefectDojo turns each policy violation into a Finding on the right Asset, deduplicated against earlier runs, with an owner and an SLA. When a fix is deployed, the next reimport closes the finding, and we have a record of how long the gap was open.

Why DrHeader Matters

Security headers are cheap defenses that block entire classes of browser-side attacks, but they live in web server, CDN, and framework configuration that changes often and is owned by different teams.

• drHEADer checks the response the user actually receives, after every proxy and CDN layer, rather than what one config file says.
• Its policy is a YAML file you can tune to your own standard, including required directives and allowed values.
• It reports both the observed value and the expected values, so the fix is usually obvious from the finding.
• Cross-origin isolation checks for Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy are available as an opt-in.
• Without tracking, header checks become a recurring spreadsheet exercise with no memory of what was fixed last quarter.

Advantages of This Integration

What we gained by sending drHEADer results to DefectDojo:

• Per-URL findings. Bulk reports carry the URL, which DefectDojo records as an endpoint and includes in the description, so the same rule failing on two hosts becomes two findings.
• Deduplication on title and description. Repeat scans of the same URL match existing findings instead of piling up duplicates.
• A real fix history. Reimporting into the same Test mitigates headers that are now compliant and reactivates any that regress.
• SLAs for configuration debt. drHEADer's severities map onto DefectDojo's scale, so header gaps are measured with the same SLA rules as other web findings.
• Context next to DAST. Header findings sit on the same Asset as DAST and pentest results, which helps when a reviewer asks whether a missing CSP makes a reflected XSS finding more serious.

How This Integration Works

DefectDojo imports drHEADer output with the DrHeader JSON Importer scan type.

1. Produce JSON. For a single URL:

drheader scan single --output json https://app.example.com > drheader-app.json

For several URLs, pass a JSON file containing an array of objects with a url key:

drheader scan bulk --output json urls.json > drheader-bulk.json

The parser accepts two layouts. A plain list of rule results (single URL) imports findings without an endpoint. A list of objects that each have a url and a report array imports each rule result with that URL as its endpoint. If the file isn't valid JSON, the import produces no findings rather than an error, so check the file if a Test comes back empty.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select DrHeader JSON Importer, and upload the file. To automate it, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=DrHeader JSON Importer" \
  -F "file=@drheader-bulk.json" \
  -F "product_name=customer-portal" \
  -F "engagement_name=Header Policy" \
  -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 "DrHeader JSON Importer" \
  --report-path "./drheader-bulk.json" \
  --product-name "customer-portal" \
  --engagement-name "Header Policy" \
  --auto-create-context

3. Reimport after each deployment. Send later reports to /api/v2/reimport-scan/ for the same Test so fixed headers are mitigated automatically.

Data Granularity: What Gets Imported

The parser creates one Finding per rule result. Mitigation, CWE, and references are not populated.

Use Cases

After every deployment: A post-deploy job runs a bulk drHEADer scan against the public entry points of an application and reimports the result. A missing header introduced by a CDN or ingress change shows up as a new finding within minutes of the release.

Enforcing a header standard across teams: A security team publishes one drHEADer rules file and runs it against every web Asset. DefectDojo metrics then show which teams meet the standard and which have open header findings past SLA.

Before a pentest: Clearing header findings ahead of a manual test keeps the pentest report focused on issues that need a human, and DefectDojo shows the testers what was already known and fixed.

Tracking a CSP rollout: Teams moving from a permissive Content-Security-Policy to a strict one can tighten the drHEADer policy in stages and watch findings drop on each reimport.

Operational Tips

• Prefer the bulk layout even for one URL. It records the URL as an endpoint and in the description, which keeps findings for different hosts apart.
• If you do use single-URL output, import each URL into its own Test. Without the URL in the description, identical rule failures on different sites share the same title and description.
• Version your drHEADer rules file alongside the pipeline. Changing expected values changes the description, and DefectDojo will treat the result as a new finding.
• drHEADer findings have no mitigation text, so add a note or a team template that explains your header standard when you assign the first batch.
• Risk-accept headers that genuinely don't apply (for example caching rules on a static asset host) with an expiration date rather than editing the rules file per team.
• Tag imports with the environment (for example tags=prod,headers) so staging and production results can be compared.