Skip to content

fix(middleware): reject CSRF TokenLookup that produces no extractors (v4) - #3149

Merged
vishr merged 1 commit into
labstack:v4from
orinnz:fix/v4-csrf-empty-extractors
Oct 22, 2026
Merged

vishr merged 1 commit into
labstack:v4from
orinnz:fix/v4-csrf-empty-extractors

Conversation

@orinnz

@orinnz orinnz commented Oct 3, 2026

Copy link
Copy Markdown

Backport of #3067 to v4.

If every source in TokenLookup is unknown (for example nope:nope), CreateExtractors returns an empty list without an error. The middleware is then created with nothing to check, so unsafe requests go through with no token validation. ToMiddleware now returns an error in that case, so the misconfiguration shows up at startup instead of silently turning CSRF protection off.

Added a case to TestCSRF_tokenExtractors. It fails before the change and passes after. go test ./... passes.

…in v4

A TokenLookup whose sources are all unknown (for example "nope:nope")
parsed without error but yielded zero extractors. With nothing to
check, unsafe requests were let through without any token validation.
Fail middleware creation instead, so the misconfiguration surfaces at
startup.

Backport of labstack#3067.

@vishr vishr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed as a minimal v4 backport of the existing v5 startup validation. A TokenLookup with no recognized extractors must fail configuration instead of silently skipping token validation. This fits the v4 bug-fix-only policy.

@vishr
vishr merged commit ea608ae into labstack:v4 Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants