docs(security): response-header hardening (app-level controls + #1567 gap)#560
docs(security): response-header hardening (app-level controls + #1567 gap)#560kriszyp wants to merge 2 commits into
Conversation
Add guidance for setting browser security-hardening headers (X-Content-Type-Options, X-Frame-Options, CSP, Referrer-Policy, HSTS, Permissions-Policy, Cross-Origin-*) at a reverse proxy/CDN rather than at the Harper origin. Also covers the risk of shared-cache storing authenticated/allowRead-gated responses when Harper does not emit Cache-Control. Cross-linked from reference/rest/headers.md See Also section. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds documentation on HTTP response header hardening and caching of authenticated responses, explaining how to configure browser security headers and cache-control at the edge layer. The review feedback points out a drafting instruction left in the text and suggests rephrasing it to be user-facing.
|
|
||
| CSP values are application-specific and intentionally omitted here — set them based on the origins your application legitimately loads scripts, styles, and media from. | ||
|
|
||
| > These defaults may tighten in future Harper releases. Frame the edge configuration as a deployment baseline, not a permanent substitute for origin-level headers. |
There was a problem hiding this comment.
This sentence contains an imperative drafting instruction ("Frame the edge configuration...") that appears to have been left in the final text by mistake. It should be rephrased to be user-facing.
| > These defaults may tighten in future Harper releases. Frame the edge configuration as a deployment baseline, not a permanent substitute for origin-level headers. | |
| > These defaults may tighten in future Harper releases. Treat this edge configuration as a deployment baseline, not a permanent substitute for origin-level headers. |
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-560 This preview will update automatically when you push new commits. |
…trols Lead with the mechanism that works on Harper-hosted (Fabric) deployments: a custom Resource can set response headers via context.responseHeaders.set(). Clearly state the gap — no built-in/config way to apply headers to auto-generated REST/GraphQL endpoints and no global default (tracked in HarperFast/harper#1567) — and demote the reverse-proxy/CDN guidance to a self-hosted fallback. Split into a dedicated reference/security/response-headers.md page (added to the Reference sidebar), replacing the section previously wedged into the auth-config page. Cross-linked from the auth Configuration page and rest/headers.md. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
kriszyp
changed the title
🚀 Preview DeploymentYour preview deployment is ready! 🔗 Preview URL: https://preview.harper-documentation.harperfabric.com/pr-560 This preview will update automatically when you push new commits. |
1 participant
Summary
Adds a dedicated Response Header Hardening page to the Security reference (
reference/security/response-headers.md), framed around the controls that actually work on the primary Harper deployment model — Harper-hosted (Fabric), where there is no customer-controlled reverse proxy / CDN / edge to configure.Framing (revised after reviewer feedback):
context.responseHeaders.set(name, value)(fromgetContext()on HTTP-triggered requests). Example setsX-Content-Type-Options: nosniffand notes where frame-options / CSP go. This is accurate to responses that flow through a custom Resource handler.Cache-Control: no-storefrom a Resource; key on identity if caching), with the missing built-in cache-control also referencing #1567.X-Frame-Optionsguidance kept conservative but explicitly app-specific.Placement: split into its own page rather than wedging into the auth-focused Configuration page. Added to the Reference sidebar (
sidebarsReference.ts) under Security, and cross-linked from the auth Configuration page andreference/rest/headers.md.Scope / what's deliberately NOT here
Identified during exploratory QA (D-177 / header-hardening theme) but tracked as separate engineering fixes and intentionally excluded — this PR is guidance only:
Vary: OriginmissingCache-Control/Vary: Authorizationat originSameSite/TTL hardening304 Not ModifieddropsVaryFiles changed
reference/security/response-headers.md— new pagereference/security/configuration.md— cross-link under Related (previous inline section removed)reference/rest/headers.md— cross-link in See AlsosidebarsReference.ts— sidebar entryTest plan
responseHeaders.set()example matches current API (getContext()→responseHeaders)Drafted by KrAIs (Kris's QA agent) from exploratory QA campaign findings D-177 + the header-hardening theme. Reworked per reviewer feedback (Fabric hosting has no customer edge). Opened as DRAFT for Kris's review before merging.
🤖 Generated with Claude Code