fix(api): harden API key management auth#2403
Conversation
|
Warning Review limit reached
More reviews will be available in 63 minutes and 50 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (45)
📝 WalkthroughWalkthroughThis PR hardens role-based access control (RBAC) authorization by refactoring middleware APIs to use optional defaults, removing legacy permission checks, updating route handlers across the platform to use simplified middleware wiring, enforcing RBAC at the database level through new policies and triggers, and expanding authorization tests with RLS-based validation. ChangesRBAC and authorization system hardening
🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Merging this PR will not alter performance
Comparing 
Footnotes
|
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
2d98712 to
0ceea8a
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
0ceea8a to
7489bf9
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
7489bf9 to
15a2742
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
15a2742 to
0f07372
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
0f07372 to
6d7e2b2
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
supabase/tests/26_test_rls_policies.sql (1)
377-393: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winAssert the new deny policies are actually restrictive.
This only proves the three policy names exist. If a future migration recreates any of them as
PERMISSIVE, the test still passes while the deny becomes ineffective against the existing owner allow-policies. Please addpg_policiesassertions forpermissive = 'RESTRICTIVE'and the expectedroles/cmdon these three new policies.As per coding guidelines: Add explicit deny policies for operations that must be impossible for user-facing roles, using RESTRICTIVE policies instead of relying on implicit deny.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supabase/tests/26_test_rls_policies.sql` around lines 377 - 393, The test currently only checks that policy names exist for table apikeys via policies_are but does not verify they are restrictive; add assertions that query pg_policies for the three deny policies (e.g., 'Deny anon delete on apikeys', 'Deny anon select on apikeys', 'Deny anon update on apikeys') and assert permissive = 'RESTRICTIVE' and that the role(s) and cmd columns match the expected values for each policy; locate this near the existing policies_are call for apikeys and add one assertion per deny policy checking pg_policies.permissive, pg_policies.roles and pg_policies.cmd to ensure the denies are actually restrictive.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@supabase/functions/_backend/public/apikey/auth.ts`:
- Around line 18-21: The code reads auth.authType without guarding for missing
auth; change the declaration to allow undefined (e.g., const auth =
c.get('auth') as AuthInfo | undefined) and update the guard to check for missing
auth first (if (!auth || auth.authType !== 'jwt' || !auth.userId) { ... }), and
when building the quickError payload use optional chaining for the authType
field (auth?.authType) so a missing auth produces the intended 401 instead of a
500; keep the same quickError call, errorCode, action and moreInfo variables.
In `@tests/apikeys-expiration.test.ts`:
- Around line 807-812: The test block removed an endpoint-level check, leaving
only direct Supabase/RLS reads (expectApiKeyCannotReadBaseOrg and
expectApiKeyCanReadBaseOrg); restore one HTTP-path assertion against the /apikey
endpoint in this block so middleware/header-parsing is exercised—add a single
assertion that the expiredKeyValue is rejected when calling the /apikey HTTP
route (alongside the RLS helper) and keep the validKeyValue HTTP-path check in
the other test block, referencing the existing helpers for RLS reads and the
/apikey route to locate where to add it.
In `@tests/apikeys.test.ts`:
- Around line 1030-1077: The test "plain key cannot update apikeys table
directly through RLS" leaves the created API key if an assertion fails; wrap the
cleanup DELETE call in a finally block so the seeded key is always removed.
Specifically, after creating the key (createResponse / createData), move the
fetch DELETE for `/apikey/${createData.id}` into a finally section that runs
regardless of test success, keeping the existing authHeaders and preserving the
rest of the assertions in the try block; ensure createData.id is available in
the finally (declare it in the outer scope if needed) so cleanup always
executes.
---
Outside diff comments:
In `@supabase/tests/26_test_rls_policies.sql`:
- Around line 377-393: The test currently only checks that policy names exist
for table apikeys via policies_are but does not verify they are restrictive; add
assertions that query pg_policies for the three deny policies (e.g., 'Deny anon
delete on apikeys', 'Deny anon select on apikeys', 'Deny anon update on
apikeys') and assert permissive = 'RESTRICTIVE' and that the role(s) and cmd
columns match the expected values for each policy; locate this near the existing
policies_are call for apikeys and add one assertion per deny policy checking
pg_policies.permissive, pg_policies.roles and pg_policies.cmd to ensure the
denies are actually restrictive.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9d385eca-b762-452d-a898-93a462ad60c4
📒 Files selected for processing (10)
cli/src/types/supabase.types.tssupabase/functions/_backend/public/apikey/auth.tssupabase/functions/_backend/public/apikey/delete.tssupabase/functions/_backend/public/apikey/get.tssupabase/functions/_backend/public/apikey/put.tssupabase/functions/_backend/public/apikey/scope.tssupabase/migrations/20260603120805_deny_apikey_management_from_api_key_auth.sqlsupabase/tests/26_test_rls_policies.sqltests/apikeys-expiration.test.tstests/apikeys.test.ts
💤 Files with no reviewable changes (1)
- supabase/functions/_backend/public/apikey/scope.ts
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
6d7e2b2 to
ed6303b
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
ed6303b to
a8fc38e
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
a8fc38e to
3991392
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@cli/src/types/supabase.types.ts`:
- Around line 3037-3045: The RPC type for app_versions_has_app_permission
incorrectly requires both p_apikey and p_user_id as non-null strings; update the
SQL RPC signature so the inactive auth parameter is nullable (make p_apikey OR
p_user_id NULLABLE/optional in the function definition for
app_versions_has_app_permission), deploy the migration, then regenerate the
TypeScript types (run the project type generation command, e.g. `bun types`) so
the generated supabase.types.ts reflects p_apikey and p_user_id as
nullable/optional and callers no longer need unsafe casts or dummy values.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 81ad7474-945a-4192-9133-1c57dfd028ca
📒 Files selected for processing (10)
cli/src/types/supabase.types.tssupabase/functions/_backend/public/apikey/auth.tssupabase/functions/_backend/public/apikey/delete.tssupabase/functions/_backend/public/apikey/get.tssupabase/functions/_backend/public/apikey/put.tssupabase/functions/_backend/public/apikey/scope.tssupabase/migrations/20260603120805_deny_apikey_management_from_api_key_auth.sqlsupabase/tests/26_test_rls_policies.sqltests/apikeys-expiration.test.tstests/apikeys.test.ts
💤 Files with no reviewable changes (1)
- supabase/functions/_backend/public/apikey/scope.ts
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
3991392 to
d1b7c51
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
d1b7c51 to
fea72cb
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fea72cb875
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
fea72cb to
507af66
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
supabase/functions/_backend/private/events.ts (1)
131-153:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDon't preflight
notifyConsolewith org-only access.Line 152 now rejects
notifyConsolerequests beforeappIdis derived and beforeresolveTrackingUserId()can authorize viaapp.read+ app ownership. App-scoped roles/API keys that are valid for one app but do not haveorg.readwill now get a false 403 on this legacy flow.Suggested fix
- // Legacy notifyConsole still sends the target org in `user_id`, so keep this - // preflight scoped to notifyConsole. Non-notify v2 events validate `org_id` - // inside resolveTrackingUserId(), where app ownership and org access diverge. - if (body.notifyConsole && requestedOrgId && !(await canAccessRequestedOrg(c, requestedOrgId))) - throw quickError(403, 'Forbidden', 'You cannot send events for this organization') - const requestedUserId = typeof body.user_id === 'string' ? body.user_id : undefined const appId = typeof body.tags?.['app-id'] === 'string' ? body.tags['app-id'] : typeof body.tags?.app_id === 'string' ? body.tags.app_id : undefined const { trackingUserId, orgId: verifiedOrgId } = await resolveTrackingUserId(c, requestedUserId, requestedOrgId, appId, trackingV2, Boolean(body.notifyConsole))Based on learnings: All changes to public APIs and plugin interfaces MUST be backward compatible; support both old and new behavior using version detection
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supabase/functions/_backend/private/events.ts` around lines 131 - 153, The preflight check currently calls canAccessRequestedOrg for notifyConsole requests and can incorrectly reject app-scoped keys; change the app.post handler so it does NOT run the org-only canAccessRequestedOrg/403 path for legacy notifyConsole flows and instead defers authorization to the later resolveTrackingUserId/app-level checks: specifically, only run the canAccessRequestedOrg check for the new trackingV2/org-id flow (when isTrackingV2(body.tracking_version) is true and requestedOrgId is present), and skip that check when body.notifyConsole is true so resolveTrackingUserId (or app.read + app ownership checks) can authorize the request.supabase/functions/_backend/public/apikey/get.ts (1)
18-24:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRequire JWT sessions for API-key list/read routes too.
Both handlers still only reject limited-scope keys, so full-scope API-key sessions can enter
/apikeylist/read management flows. That contradicts the hardening goal here and risks either continued access or misleading downstream 404/500 responses when the real failure is authorization. Add an upfrontauth.authType === 'apikey'rejection in both routes.Also applies to: 41-47
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supabase/functions/_backend/public/apikey/get.ts` around lines 18 - 24, The GET route handler registered with app.get('/', middlewareV2(), async (c) => { ... } currently only blocks limited-scope API keys via apiKeyHasLimitedScope, but must reject any request authenticated via API key; update the handler (and the similar read/list handler around the 41-47 range) to first check if c.get('auth') as AuthInfo has auth.authType === 'apikey' and immediately throw quickError(401, 'cannot_list_apikeys', 'You cannot do that as an API key', { apikeyId: apikey?.id }) before calling apiKeyHasLimitedScope or proceeding, so that full-scope API-key sessions are not allowed into the list/read flows; keep the existing limited-scope check for more specific messaging if desired.supabase/functions/_backend/public/apikey/delete.ts (1)
18-24:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReject all API-key sessions before the delete path.
This only blocks limited-scope keys, so full-scope API-key callers still reach API-key deletion. That breaks the JWT-only management contract for this PR and can either preserve delete access or turn an authorization failure into a misleading 404/500 downstream. Reject
auth.authType === 'apikey'up front here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supabase/functions/_backend/public/apikey/delete.ts` around lines 18 - 24, The route handler in app.delete('/:id', middlewareV2(), ...) currently only blocks limited-scope API keys but still allows full-scope API-key sessions to proceed; update the handler to reject any session where auth.authType === 'apikey' up front. Locate the app.delete handler and the auth variable (const auth = c.get('auth') as AuthInfo) and add a guard that throws quickError(401, 'cannot_delete_apikey', 'You cannot do that as an API key', { apikeyId: auth?.apikeyId ?? authApikey?.id }) (or similar) before calling apiKeyHasLimitedScope; remove or keep the existing limited-scope check only as a secondary/defensive measure so no API-key-based caller can reach the delete logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@supabase/functions/_backend/public/apikey/put.ts`:
- Around line 225-227: Add an upfront guard that rejects any non-JWT auth before
performing API-key mutations: check c.get('auth')?.authType (or auth.authType)
and if it's not 'jwt' throw quickError(401, 'invalid_auth_type', 'API key
management requires JWT', { requestId }). Replace relying solely on
apiKeyHasLimitedScope(authApikey) with this JWT-only check in the current
mutation handler (the block using auth.authType, apiKeyHasLimitedScope and
authApikey) and replicate the same JWT-only guard in the other mutation handler
that currently uses the limited-scope check (the analogous block later in the
file).
In `@supabase/migrations/20260603152530_harden_rbac_compat_cleanup.sql`:
- Around line 108-113: In the SECURITY DEFINER functions that return a JSON
object (the RETURN using jsonb_build_object), fully qualify the function call by
replacing jsonb_build_object(...) with pg_catalog.jsonb_build_object(...) so
that all references inside these functions are explicitly qualified; update the
RETURN statements that build the object containing 'status', 'org_id'
(p_org_id), 'migration_result' (v_migration_result) and 'rbac_enabled' to call
pg_catalog.jsonb_build_object, and apply the same change to the other instance
noted (the block around the second RETURN).
- Around line 55-58: The RLS policy "Allow org settings update via RBAC" on
public.orgs currently grants TO "anon", which allows API-key-authenticated
requests to bypass the intended restriction; update the policy to remove "anon"
so it only grants TO "authenticated" (keep the policy name and FOR UPDATE on
"public"."orgs" and leave any calls to public.rbac_check_permission_request(...)
intact—resolve API-key identity inside that helper instead of changing the
policy).
---
Outside diff comments:
In `@supabase/functions/_backend/private/events.ts`:
- Around line 131-153: The preflight check currently calls canAccessRequestedOrg
for notifyConsole requests and can incorrectly reject app-scoped keys; change
the app.post handler so it does NOT run the org-only canAccessRequestedOrg/403
path for legacy notifyConsole flows and instead defers authorization to the
later resolveTrackingUserId/app-level checks: specifically, only run the
canAccessRequestedOrg check for the new trackingV2/org-id flow (when
isTrackingV2(body.tracking_version) is true and requestedOrgId is present), and
skip that check when body.notifyConsole is true so resolveTrackingUserId (or
app.read + app ownership checks) can authorize the request.
In `@supabase/functions/_backend/public/apikey/delete.ts`:
- Around line 18-24: The route handler in app.delete('/:id', middlewareV2(),
...) currently only blocks limited-scope API keys but still allows full-scope
API-key sessions to proceed; update the handler to reject any session where
auth.authType === 'apikey' up front. Locate the app.delete handler and the auth
variable (const auth = c.get('auth') as AuthInfo) and add a guard that throws
quickError(401, 'cannot_delete_apikey', 'You cannot do that as an API key', {
apikeyId: auth?.apikeyId ?? authApikey?.id }) (or similar) before calling
apiKeyHasLimitedScope; remove or keep the existing limited-scope check only as a
secondary/defensive measure so no API-key-based caller can reach the delete
logic.
In `@supabase/functions/_backend/public/apikey/get.ts`:
- Around line 18-24: The GET route handler registered with app.get('/',
middlewareV2(), async (c) => { ... } currently only blocks limited-scope API
keys via apiKeyHasLimitedScope, but must reject any request authenticated via
API key; update the handler (and the similar read/list handler around the 41-47
range) to first check if c.get('auth') as AuthInfo has auth.authType ===
'apikey' and immediately throw quickError(401, 'cannot_list_apikeys', 'You
cannot do that as an API key', { apikeyId: apikey?.id }) before calling
apiKeyHasLimitedScope or proceeding, so that full-scope API-key sessions are not
allowed into the list/read flows; keep the existing limited-scope check for more
specific messaging if desired.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ab68b309-0943-4f4d-9fef-b38190517594
📒 Files selected for processing (34)
supabase/functions/_backend/files/files.tssupabase/functions/_backend/private/admin_credits.tssupabase/functions/_backend/private/create_device.tssupabase/functions/_backend/private/delete_failed_version.tssupabase/functions/_backend/private/devices.tssupabase/functions/_backend/private/events.tssupabase/functions/_backend/private/role_bindings.tssupabase/functions/_backend/private/set_org_email.tssupabase/functions/_backend/private/stats.tssupabase/functions/_backend/private/upload_link.tssupabase/functions/_backend/public/apikey/delete.tssupabase/functions/_backend/public/apikey/get.tssupabase/functions/_backend/public/apikey/post.tssupabase/functions/_backend/public/apikey/put.tssupabase/functions/_backend/public/app/demo.tssupabase/functions/_backend/public/app/index.tssupabase/functions/_backend/public/build/index.tssupabase/functions/_backend/public/bundle/index.tssupabase/functions/_backend/public/bundle/update_metadata.tssupabase/functions/_backend/public/channel/index.tssupabase/functions/_backend/public/device/index.tssupabase/functions/_backend/public/organization/audit.tssupabase/functions/_backend/public/organization/index.tssupabase/functions/_backend/public/statistics/index.tssupabase/functions/_backend/public/webhooks/index.tssupabase/functions/_backend/utils/hono.tssupabase/functions/_backend/utils/hono_middleware.tssupabase/functions/_backend/utils/rbac.tssupabase/functions/_backend/utils/supabase.tssupabase/migrations/20260603152530_harden_rbac_compat_cleanup.sqlsupabase/tests/26_test_rls_policies.sqlsupabase/tests/48_test_rbac_admin_rpc_execute_grants.sqltests/apikeys-expiration.test.tstests/apikeys.test.ts
💤 Files with no reviewable changes (2)
- supabase/functions/_backend/utils/hono.ts
- supabase/functions/_backend/utils/supabase.ts
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
507af66 to
721ad2b
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 721ad2be20
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
721ad2b to
3bdcec9
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3bdcec952b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
3bdcec9 to
4afc795
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4afc7956b5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
4afc795 to
e894097
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e894097d41
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
e894097 to
85614a9
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85614a9926
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
85614a9 to
a808090
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
a808090 to
ea45cf7
Compare
riderx
force-pushed
the
codex/rbac-apikey-management-hardening
branch
from
ea45cf7 to
e579add
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e579add339
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
1 participant
Summary (AI generated)
middlewareV2(['all', 'write']); handlers now authenticate first and enforce authorization through RBAC checks, API route guards, and RLS.use_new_rbacruntime gating while keeping the compatibility output field and old SQL compatibility helpers./apikeymanagement mutations: API-key sessions are rejected for update/regenerate/delete, while/apikeyread/list API-key compatibility remains and limited scoped keys are still filtered.orgsare closed,use_new_rbacis forced true, rollback cannot disable RBAC, andcli organization setnow callsPUT /organizationinstead of writingorgsdirectly.password_policy_configso moving CLI org settings to the API route does not drop the password-policy feature.Motivation (AI generated)
RBAC is now the authoritative authorization model. Leaving old key-mode write labels, app-side RBAC feature flags, and CLI direct org writes made the active security boundary ambiguous and could preserve upgrade/downgrade paths that no longer match the product model. This PR removes those stale surfaces while preserving intentional compatibility for old API-key read paths and old org payload shape.
Fix Justification (AI generated)
['all', 'write']route declarations are no longer the security boundary and were misleading./apikeyread/list compatibility: keeping API-key reads avoids breaking old compatible callers; scoped keys still use the existing limited-scope filter.orgsUPDATE is now authenticated-only and named-RBAC guarded; API-key org settings writes must go through the backend route wheremiddlewareV2,checkPermission, and API-key org policy checks run before the service-role write.cli organization setno longer relies on direct Supabaseorgs.update(...), so it does not need the old write RLS policy to stay open.min_lengthbounded to 6..72, matching the DB constraint.rbac_enable_for_orgremains service-role callable for old automation, but always returns RBAC enabled;rbac_rollback_orgis retained but cannot disable RBAC or delete bindings.Business Impact (AI generated)
This reduces the chance of API-key self-escalation, leaked-key damage, or accidental reactivation of legacy write behavior, while avoiding a breaking change for compatible API-key read/list callers and current CLI org-settings workflows.
Test Plan (AI generated)
bun lint:backendbun typecheck:backendbun run cli:typecheck && bun run typecheck:backend && bun run typecheck:frontendbun run cli:checkbun run supabase:db:resetPGSSLMODE=disable bunx supabase test db --db-url postgresql://postgres:postgres@127.0.0.1:60642/postgres supabase/tests/00-supabase_test_helpers.sql supabase/tests/26_test_rls_policies.sql supabase/tests/48_test_rbac_admin_rpc_execute_grants.sqlbun test --timeout 60000 tests/events.test.ts tests/apikeys.test.ts tests/apikeys-expiration.test.ts tests/organization-api.test.ts tests/audit-logs.test.ts tests/password-policy.test.tsbunx vitest run tests/organization-put-stripe-sync.unit.test.tsGenerated with AI