6.6 - An API key can mint itself a more powerful key

[determined-001]

Complexity: Medium - 150 Points · type:security

Milestone: M2 - Multi-tenant platform

Band lever: hold-B (a leaked narrow key reaches seller funds)

Context
apps/api/src/routes/api-keys.ts gates the whole router on the
api-keys:manage scope, then accepts the scopes array from the request body
and issues a key carrying them.

Problem
Nothing checks that the requested scopes are a subset of the calling key's
scopes. Any combination of ALL_SCOPES is accepted, including
offramp:initiate. So a key deliberately issued narrow — say, an integration
key scoped only to api-keys:manage so it can rotate credentials — is
effectively a root key.

The escalation reaches money: POST /links/:id/cash-out accepts a caller-supplied
payoutFields object that overrides the seller's saved payout destination for
that cash-out, with no re-confirmation. Leaked narrow key → self-issued
offramp:initiate key → proceeds redirected.

What needs to be done

1. In the create-key handler, when the caller is authenticated by API key
   (rather than a browser session), reject any requested scope the calling key
   does not itself hold — 403, naming the offending scopes.
2. Leave session-authenticated callers able to request any scope: the seller
   logging in with their wallet is the authority the keys derive from.
3. Consider the same subset rule for any future key-update path.
4. Tests: narrow key requesting a broader scope is rejected; narrow key
   requesting an equal-or-narrower scope succeeds; session caller is unaffected.

Key files

• apps/api/src/routes/api-keys.ts:43 — create-key handler
• apps/api/src/services/api-keys.ts:56 — scope validation
• apps/api/src/middleware/ — where the auth variables distinguish key vs session
• apps/api/src/services/link-service.ts:944 — the payoutFields override this protects

Done when

• A key without offramp:initiate cannot create a key that has it.
• A wallet-session caller can still issue any scope they own.
• Regression test covers both arms.

---

Tracked in ISSUES.md — issue 6.6.

[Oluwasegun6921]

@Oluwasegun6921 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainer,
I’d like to take ownership of this issue. I’ll implement the required changes, test them properly, and submit a pull request for review.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Oluwasegun6921 to this issue.

[drips-wave]

Congratulations, @Oluwasegun6921! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Oluwasegun6921: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @Oluwasegun6921 as part of the Stellar Wave Program's 8th Wave 🥳

😎 @Oluwasegun6921: You earned 150 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.