#197: security response headers and an explicitly restrictive CORS policy #252
No reviewers
Labels
No Label
area:auth
area:docs
area:export
area:ops
area:storage
area:supply-chain
auth
backend
blocked
collab
deployment
docs
effort:L
effort:M
effort:S
frontend
plugins
qa
vs-nfd
vs-nfd:blocker
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: stwaidele/dorfteich#252
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/197-security-headers"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes-manually: #197 (issue closed after green pipeline, per repo convention).
Hand-rolled security-header middleware instead of helmet (supply-chain minimalism; every value deliberate): HSTS without includeSubDomains, nosniff, Referrer-Policy no-referrer, X-Frame-Options SAMEORIGIN (not DENY -- the plugin sandbox frame embeds same-origin and its CSP has no frame-ancestors, so this header governs), minimal deny-all Permissions-Policy.
CORS: no foreign origin is granted anything; only the APP_BASE_URL origin is echoed (browsers never consult CORS there, being same-origin), Vary: Origin on every response, no preflight handling needed.
Wired via AppModule MiddlewareConsumer so createTestApp boots the identical middleware. Tests: security-headers.e2e.test.ts (5 cases, incl. foreign origin gets no ACAO and headers on 404s) + frame assertion in plugins.e2e.db.test.ts. Docs: security.md rationale table.
Evidence: api full suite 469 green vs fresh dorfteich_t197, typecheck+lint green.
e606b869d8to3c62b7b773