Skip to content

CSRF middleware planned before introducing any cookie-based auth #217

Description

@kilodesodiq-arch

Problem Statement. security.module.ts carries an explicit comment:

/**
 * WARNING:
 * If cookie-based session management or any browser-managed credentials are introduced
 * in the future, CSRF protection middleware MUST be implemented.
 */

There is no ticket tracking that future obligation. Re-introducing a cookie or
SameSite=None; Secure flow without realising the gap is a one-line PR away from a regression.

Why it matters. CSRF defences are only as good as their visibility. Embedding the
expectation into the source-of-truth PR queue prevents regressions.

Technical Context. Today the API is API-key-authenticated, custom-header-based, so
browsers do not auto-attach the credential. Adding cookie-parser (not currently
installed) would silently change the threat model.

Expected Outcome. An informational PR is opened that documents the existing CSRF
posture, the conditions under which it would break, and a CsrfMiddleware skeleton guarded
behind a feature flag.

Acceptance Criteria.

  • A new src/common/security/csrf.middleware.ts is registered only when
    CSRF_PROTECTION_ENABLED=true.
  • A CI test verifies CSRF is bypassed (current posture) and a second test verifies it
    blocks a forged POST when enabled.
  • A short docs/security/csrf-posture.md covers the contract.

Implementation Notes. Use csurf/csrf-csrf packages only if still maintained; else
build a 30-line double-submit-cookie middleware to keep the dependency surface small.

Files or modules likely to be affected. src/common/security/csrf.middleware.ts,
docs/security/csrf-posture.md.

Difficulty. Medium
Estimated effort. S



Backlog item #9 from `docs/maintainer-issue-backlog.md.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions