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

Abierto
  • ¿Algo no está bien?
#376 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
nextjs, playwright, typescript
Área
security, web-dev

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
1
Forks
1
Merge medio
6 h 56 min
PR fusionados (30 d)
136

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eddiejaoude/StackDash

Todos los issues de eddiejaoude/StackDash

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.