Confirming the hosting provider for the privacy policy surfaced this: the _headers file in this repo does nothing.
_headers is a Netlify and Cloudflare Pages convention. GitHub Pages has no mechanism for custom response headers and ignores the file entirely.
Verified against production:
$ curl -sI https://privkey.io
HTTP/2 200
server: GitHub.com
content-type: text/html; charset=utf-8
...
None of the headers _headers declares are present: no Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, or Permissions-Policy.
Clickjacking protection is absent in both places it was expected. X-Frame-Options: DENY is not served because _headers is inert, and the CSP in index.html is delivered through a <meta http-equiv> tag, where the spec requires frame-ancestors to be ignored. So privkey.io can currently be framed by any origin. The rest of the meta CSP (script-src, style-src, connect-src, form-action) does apply, so the CSP is not useless, only the framing directive is dropped.
Also missing as a consequence: HSTS, which matters because the apex domain has no preload protection on first visit, and nosniff.
Options, roughly in order of effort:
- Put Cloudflare in front of GitHub Pages (proxied DNS, free tier). Response headers become configurable via Transform Rules,
_headers stays meaningful if we later move to Cloudflare Pages, and HSTS gets a toggle. No change to the publishing flow.
- Move hosting to Cloudflare Pages or Netlify.
_headers then works as written and the file stops being a lie. Slightly larger change, and it moves us off the GitHub Pages path referenced in the privacy policy's subprocessor table.
- Stay on GitHub Pages and delete
_headers, accepting no security headers. Honest, but for a security consultancy's own site this is the weakest option and prospects do check.
Recommend option 1.
Whichever we pick, legal/privacy-policy.md §5.1 lists the hosting provider and §3.2 describes who holds the access logs, so a hosting change means updating both. Tracked as item 10a in legal/PUBLICATION-CHECKLIST.md.
Confirming the hosting provider for the privacy policy surfaced this: the
_headersfile in this repo does nothing._headersis a Netlify and Cloudflare Pages convention. GitHub Pages has no mechanism for custom response headers and ignores the file entirely.Verified against production:
None of the headers
_headersdeclares are present: noStrict-Transport-Security,X-Content-Type-Options,X-Frame-Options,Cross-Origin-Opener-Policy,Cross-Origin-Embedder-Policy, orPermissions-Policy.Clickjacking protection is absent in both places it was expected.
X-Frame-Options: DENYis not served because_headersis inert, and the CSP inindex.htmlis delivered through a<meta http-equiv>tag, where the spec requiresframe-ancestorsto be ignored. So privkey.io can currently be framed by any origin. The rest of the meta CSP (script-src,style-src,connect-src,form-action) does apply, so the CSP is not useless, only the framing directive is dropped.Also missing as a consequence: HSTS, which matters because the apex domain has no preload protection on first visit, and
nosniff.Options, roughly in order of effort:
_headersstays meaningful if we later move to Cloudflare Pages, and HSTS gets a toggle. No change to the publishing flow._headersthen works as written and the file stops being a lie. Slightly larger change, and it moves us off the GitHub Pages path referenced in the privacy policy's subprocessor table._headers, accepting no security headers. Honest, but for a security consultancy's own site this is the weakest option and prospects do check.Recommend option 1.
Whichever we pick,
legal/privacy-policy.md§5.1 lists the hosting provider and §3.2 describes who holds the access logs, so a hosting change means updating both. Tracked as item 10a inlegal/PUBLICATION-CHECKLIST.md.