fix(security): send a CSP on mis-cased forms of the proxied prefixes

Aperta
#376 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
nextjs, playwright, typescript
Ambito
security, web-dev

Direzione di ricerca

Run a production build and reproduce with curl -sI for each row in the table, starting with /App versus /super-admin. Then read outsideProxy in next.config.ts:26 alongside the case-sensitive matcher comment in src/proxy.ts, and compare with how /docs is already handled, since that path is the working precedent named in the issue. Any change must keep those two definitions in sync and be covered by a new mis-cased app-prefix case in e2e/csp.spec.ts, run in CI mode; done means exactly one enforced CSP per request across the table. Expect to experiment, as the plan's two directions are both untested.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: security bug priority: P2

Context

A request for a mis-cased form of a path the proxy covers (/App, /App/x, /Account, /Sign-In, /W/x, /P/x, /Auth/x, /Unsubscribe, and with #375 also /Super-Admin) gets the global 404 page with no Content-Security-Policy header at all: no nonce policy and no static baseline (frame-ancestors 'none', base-uri, form-action, object-src). The house rule is that every page carries a policy. Strict-Transport-Security and the other baseline headers are still sent, and only the not-found page is served this way, so no user data is involved.

Why: headers() sources in next.config.ts are compiled case-insensitively unless experimental.caseSensitiveRoutes is set (node_modules/next/dist/server/lib/router-utils/filesystem.js:134-149 and :448), so the negative lookahead in outsideProxy (next.config.ts:26) also excludes /App from the static policy. The proxy matcher is case-sensitive (src/proxy.ts, comment above config), so the proxy does not run for /App and sets no nonce policy either. /docs already has the opposite fix: the proxy matches mis-cased docs paths and the static policy keeps covering them.

Found by the Fable review of #375 (https://github.com/eddiejaoude/DevMacro/pull/375#discussion_r4554398694), observed on a production build of 974413b, signed out:

Request Status Content-Security-Policy
/super-admin 404 nonce policy
/Super-Admin, /Super-Admin/x 404 none
/No-Such-Top 404 static policy
/App, /App/x, /Account, /Sign-In, /W/x, /P/x, /Auth/x, /Unsubscribe 404 none

The last row is the same on integration/demo-2026-11 (8705a1b).

Plan

  1. Reproduce with curl -sI on a production build for each row above.
  2. Stop depending on a case-insensitive exclusion. Two directions, untested: have the proxy answer mis-cased forms of its own prefixes as it does for /docs, or send the static policy on every path and let the proxy replace it where it runs (check that a second policy is never enforced alongside the nonce policy).
  3. Keep outsideProxy and the proxy matcher in sync, as their comments ask.

Acceptance criteria

  • Every mis-cased form of a proxied prefix answers with exactly one enforced CSP (the static or the nonce policy)
  • Correctly cased proxied paths still carry only the nonce policy; paths outside the proxy still carry only the static policy
  • e2e/csp.spec.ts covers at least one mis-cased app prefix

Files and areas

next.config.ts, src/proxy.ts, e2e/csp.spec.ts. Non-goals: changing which paths the proxy covers, the policies' directives, or any route's not-found page.

Verification

curl -sI per row above on a production build, then e2e/csp.spec.ts in CI mode: all pass.


Branch: <issue-number>-csp-mis-cased-prefixes
Closes with a Closes #<issue-number> footer on the commit or pull request.

Model: anthropic/claude-opus-5-5 | Reasoning effort: low

Lingua principale
TypeScript
Stelle
1
Fork
1
Merge medio
6h 56m
PR unite (30g)
136

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eddiejaoude/StackDash

Tutte le issue di eddiejaoude/StackDash

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.