fix(netlify): Add hardened website headers

[jkowall]

Summary

• Add a global Netlify header rule for the Jaeger website.
• Configure HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy for all paths.
• Leave CSP out of this PR after maintainer feedback; a stricter CSP can be tracked separately once it can avoid unsafe-inline and be validated against the site assets.

OpenSSF

Refs jaegertracing/jaeger#8600
Refs jaegertracing/jaeger#8484
Parent tracker: jaegertracing/jaeger#8481

Validation

• node TOML parse check for required header fields and no blocking CSP
• git diff --check
• npm run check:format
• npm run check:filenames

Note: local npm run build currently fails before rendering pages because Hugo cannot find the Docsy partial dark-mode-config.html in this checkout dependency state. The failure is unrelated to the netlify.toml header change.

[Copilot]

Pull request overview

This PR hardens the Jaeger documentation site served via Netlify by adding a global header rule that applies security-related response headers (CSP, HSTS, anti-sniffing, clickjacking protection, referrer policy, and permissions policy) across all paths.

Changes:

• Add a global [[headers]] rule for /* in netlify.toml.
• Configure Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yurishkuro]

Thanks for adding these hardening headers — the non-CSP ones (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy) are low-risk and worth keeping.

I'm hesitant about the Content-Security-Policy header though. The current CSP includes 'unsafe-inline' for both script-src and style-src, which means it doesn't actually block the main attack it's designed to prevent (injected inline scripts). So we're getting minimal security benefit while taking on real operational risk: anyone adding a new CDN source, analytics tag, or third-party script in the future will silently break the production site with no obvious cause — CSP violations only show up in browser devtools, not in build or deploy logs.

Two alternatives worth considering:

1. Drop the CSP header and merge everything else — the other five headers are cheap wins with no maintenance burden.
2. Add it as Content-Security-Policy-Report-Only instead — logs violations without blocking anything, so we can observe breakage before it affects users.

Given that this is a static docs site with no user-submitted content, I don't think the CSP as written meaningfully reduces our attack surface.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[jkowall]

Thanks, @yurishkuro agreed. I removed the blocking CSP from this PR and kept the lower-risk hardening headers.

I also updated the PR description to make the scope clear: this PR now covers HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy only. CSP can be handled separately once we can make it stricter and validate it against the site assets without relying on 'unsafe-inline'.