Conversation
…#16) Critical finding confirmed. The /api-keys self-service routes were registered under the plain authed group with no structural guard, so a narrow-scoped API key could call POST /api/v1/api-keys with scopes=["*"] and mint a wildcard successor for itself - one-hop privilege escalation that defeats the PR's own invariant that a service key's scope is an upper bound on what the caller can do. Took the strict option (approach 3 from the review prompt) because it's the only one that's safe by default: - RequireUserSession() middleware in middleware/apikey.go returns 403 with code apikey.user_session_required when CtxKeyAPIKeyScopes is set on Locals - i.e. the request came in with an API-key bearer. - server/router.go wraps GET/POST/DELETE /api-keys in an authed.Group("/api-keys", RequireUserSession()). JWT bearers still work, API-key bearers get 403 regardless of payload. Why not subset-check the scopes (approach 2)? Because that still lets an API key manage credentials, which means a leaked key can *revoke* the legitimate owner's other keys (denial of service) and rotate the leaked key itself (evading the owner's revoke). Strict "no credential management from API keys" is the simpler and more auditable contract; future admin tooling that legitimately needs it can use a JWT-exchange flow rather than a scope. Tests: - TestRequireUserSession_RejectsAPIKeyAuth: covers both the reject (API-key bearer → 403) and pass-through (JWT bearer → 200) paths. Regression for the escalation vector. go test -race ./internal/... clean, golangci-lint clean. Co-Authored-By: dede febriansyah <febriansyahd65@gmail.com>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
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
1 participant
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
Hotfix for a privilege-escalation path that landed with PR #16. The
/api/v1/api-keysself-service routes were mounted under the plainauthedgroup, so a caller presenting a narrow-scoped API key (e.g.scopes=["reports.read"]) could still callPOST /api/v1/api-keysand mint a wildcard-scoped successor for itself — one-hop escalation that defeats the PR's own invariant that a service key's scope is an upper bound on what it can do. Ships theRequireUserSession()middleware and wires the/api-keyssubtree behind it so credential management is only reachable from an interactive JWT session.Why
PR #16 review flagged this vector; the fix commit (
f0e4d1f) was ready on the source branch but the merge happened one commit earlier (a119779), so main shipped with the gap still open. This PR closes it.How
internal/adapter/http/middleware/apikey.go— newRequireUserSession() fiber.Handler. It checksc.Locals(CtxKeyAPIKeyScopes): when non-nil (i.e. the request came in on an API-key bearer) it returns 403apikey.user_session_required. When nil (JWT path) it callsc.Next(). Purely structural — there's no scope-math to get wrong.internal/infrastructure/server/router.go—/api-keysmoved into its own sub-group layered on top ofauthedwithRequireUserSession()as a second middleware. JWT bearers are unaffected; API-key bearers get a clean 403 regardless of payload.TestRequireUserSession_RejectsAPIKeyAuthcovers both legs (API-key → 403, JWT → 200) so a future refactor that removes the sub-group breaks the suite.Strict "no credential management from API keys" was chosen over a subset-scope check because the latter still permits a leaked key to revoke the owner's other keys (DoS) and to rotate itself (evading the owner's revoke).
Test plan
make lintclean (golangci-lint run ./...)make testclean (go test -race ./internal/adapter/http/middleware/...)curl -H "Authorization: Bearer gf_test_aaaaaaaaaaaa_<secret>" -X POST /api/v1/api-keys→ 403 withapikey.user_session_required; same call with a JWT → 201.Risk
/api/v1/api-keys. JWT callers see no change. API-key callers of those three endpoints now get 403 instead of succeeding — which is the intended security fix.Checklist
fmt.Printlnleft behindLink to Devin session: https://app.devin.ai/sessions/8fdfc20358514c97a766adca630a2527
Requested by: @dedeez14