Capgo - App Existence Oracle via GET /statistics/app/:app_id

An attacker possessing an app-limited API key can enumerate real sibling app IDs by sending GET requests to `/statistics/app/:app_id`. A nonexistent app ID returns a 401 `no_access_to_app` error, while a real sibling app ID outside the key's `limited_to_apps` scope returns a 500 `cannot_get_app_statistics` error with a `PGRST116` code indicating zero rows [ref_id=1]. This differential response creates an app existence oracle, breaking tenant isolation and allowing the attacker to discover valid app IDs belonging to the same account.

The vulnerability resides in `supabase/functions/_backend/public/statistics/index.ts` (lines 553-575), where the statistics endpoint first authorizes via `checkPermission()` and then uses an authenticated Supabase client to fetch the app row. The RBAC logic in `supabase/functions/_backend/utils/rbac.ts` (lines 257-285) and the SQL function in `supabase/migrations/20251222140030_rbac_system.sql` (lines 3592-3607) allow a scoped API key to pass the initial permission gate based on the broader owner-user principal, but the subsequent database query fails distinctively for real sibling apps outside the key's scope.

The advisory does not include a published patch diff, but the recommended fix is to ensure that the statistics endpoint returns a consistent error response (e.g., a generic 401 or 404) regardless of whether the app ID is nonexistent or exists but is outside the API key's scope [ref_id=1]. This would eliminate the differential error that allows attackers to distinguish real sibling apps from fake ones.