Capgo - Authorization Bypass in API Key Management via App-Limited Keys

An attacker who possesses an API key created with `mode=all` but restricted to a single app via `limited_to_apps` can send authenticated requests to the `/apikey` endpoints. The handlers only check for `limited_to_orgs` and do not enforce the `limited_to_apps` boundary, so the attacker can list, modify, or delete any sibling API key belonging to the same account, including unrestricted account-level keys [ref_id=1]. This is an authorization bypass (improper enforcement of access restrictions).

The vulnerability resides in the public API key management handlers: `supabase/functions/_backend/public/apikey/get.ts`, `put.ts`, `delete.ts`, and `post.ts`. The handlers accept `middlewareV2(['all'])` and reject keys with `limited_to_orgs` but fail to reject keys with `limited_to_apps`, allowing an app-scoped key to enumerate, update, and delete sibling API keys outside its declared app scope [ref_id=1].

The advisory does not include a patch diff, but the fix would require the API key management handlers to reject requests where the authenticating key has `limited_to_apps` set and the target operation involves a key outside that app scope. Currently the handlers only reject keys with `limited_to_orgs`, leaving the `limited_to_apps` boundary unenforced for read, update, and delete operations on sibling keys [ref_id=1].