fix(basic-auth): reject empty consumer password and fail closed - #13883
Closed
waterWang wants to merge 1 commit into
Closed
fix(basic-auth): reject empty consumer password and fail closed#13883waterWang wants to merge 1 commit into
waterWang wants to merge 1 commit into
Conversation
dosubot
Bot
added
size:L
waterWang
changed the title
waterWang
force-pushed
the
fix/basic-auth-empty-password
branch
from
August 26, 2026 08:06
91e1533 to
d0b6727
Compare
dosubot
Bot
added
size:M
RFC 8265 section 4.1 requires the OpaqueString password profile to be
non-zero-length. The consumer schema currently declares `password` as plain
`{ type = "string" }` with no minLength, so the Admin API accepts a consumer
whose password is an empty string. Such a consumer authenticates, appearing
protected while effectively having no secret. Once apache#13836 lands (split on the
first colon per RFC 7617), `user:` would also return 200 for an empty-password
consumer.
Fix:
- add `minLength = 1` to `consumer_schema.password` so the Admin API rejects
empty passwords on consumer create/update
- fail closed in `find_consumer` when either the presented or the resolved
password is empty, covering legacy empty-password consumers and
`$secret://` / `$ENV://` references that resolve to ""
Regression tests: consumer schema rejects empty password, Admin API rejects
empty consumer password, empty/whitespace-only passwords in the
Authorization header return 401.
Closes apache#13881
Member
|
Thanks but this issue has been fixed by another PR :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #13881 —
basic-authcurrently accepts a consumer with an empty password, allowing passwordless access.RFC 8265 section 4.1 (the OpaqueString password profile referenced by RFC 7617) requires a password to be non-zero-length. Today the Admin API accepts
password: ""becauseconsumer_schema.passwordis declared as plain{ type = "string" }with nominLength. Such a consumer authenticates, so it looks protected while it effectively has no secret. Once #13836 lands (split on the first colon per RFC 7617),user:would also return 200 for such a consumer.Changes
apisix/plugins/basic-auth.luaminLength = 1toconsumer_schema.passwordso the Admin API rejects empty passwords on consumer create/update.find_consumerwhen either the presented or the resolved password is empty. This also covers existing empty-password consumers and$secret:///$ENV://references that resolve to"".t/plugin/basic-auth.t— regression tests:foo:(empty password) returns 401foo:) returns 401Compatibility with #13836
This change is orthogonal to #13836 (which fixes parsing to split on the first colon). With or without #13836, an empty/whitespace-only password now fails closed with a 401.