Restrict plan max RPC to authorized org callers

[riderx]

Summary (AI generated)

• Added migration [supabase/migrations/20260308074500_fix_get_current_plan_max_org_access.sql] to harden public.get_current_plan_max_org(uuid).
• Added an authorization guard using get_identity_org_allowed and check_min_rights('read', ...) so callers must be authorized for the requested org.
• Removed anonymous execution from the function and kept execution permissions scoped to authenticated and service_role.

Test plan (AI generated)

• Ran bun lint.
• Reviewed and committed migration diff against origin/main.
• Reviewed function-level diff before creating the PR.

Screenshots (AI generated)

• Not applicable (backend-only migration/security change).

Checklist (AI generated)

• My code follows the code style of this project and passes bun lint.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• My change has adequate E2E test coverage.
• I have tested my code manually, and I have provided steps how to reproduce my tests.

Summary by CodeRabbit

• Security
  • Strengthened authorization for accessing organization plan metrics so only authorized roles can retrieve plan limits; anonymous or insufficiently privileged callers are denied.
• Tests
  • Added coverage verifying unauthorized/anonymous access is blocked and plan-access behavior for authenticated scenarios.

[coderabbitai]

Warning

Rate limit exceeded

@riderx has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 2 minutes and 51 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 71ccc108-5edb-4fe8-b5ea-4510c391a1ac

📥 Commits

Reviewing files that changed from the base of the PR and between 378d7fe and f30cbcc.

📒 Files selected for processing (1)

• supabase/migrations/20260308203334_fix_get_current_plan_max_org_access_cli.sql

📝 Walkthrough

Walkthrough

Adds a SECURITY DEFINER PostgreSQL function public.get_current_plan_max_org(orgid uuid) that returns plan metrics (mau, bandwidth, storage, build_time_unit). The function enforces permission checks (via get_identity_org_allowed and check_min_rights), is owned by postgres, and grants EXECUTE only to authenticated and service_role.

Changes

Cohort / File(s)	Summary
New Security-Restricted Function supabase/migrations/20260308203334_fix_get_current_plan_max_org_cli.sql	Adds get_current_plan_max_org(uuid) as LANGUAGE plpgsql STABLE SECURITY DEFINER, performs identity/rights checks (get_identity_org_allowed, check_min_rights), returns org plan metrics by joining orgs, stripe_info, and plans; sets owner to postgres and adjusts EXECUTE privileges.
Tests Updated supabase/tests/08_plan_functions.sql	Increments test count and adds an anonymous-authentication test asserting anonymous calls to get_current_plan_max_org return zero rows (permission denied behavior).

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant DB as DB Function: get_current_plan_max_org
  participant Identity as get_identity_org_allowed
  participant Rights as check_min_rights
  participant Data as orgs/stripe_info/plans

  Client->>DB: CALL get_current_plan_max_org(orgid)
  DB->>Identity: derive requesting_user(orgid)
  Identity-->>DB: requesting_user / allowed_orgs
  DB->>Rights: check_min_rights(requesting_user, orgid, 'org.read')
  Rights-->>DB: allowed / denied
  alt allowed
    DB->>Data: query orgs JOIN stripe_info JOIN plans
    Data-->>DB: plan metrics
    DB-->>Client: return rows (mau, bandwidth, storage, build_time_unit)
  else denied
    DB-->>Client: return 0 rows (log deny)
  end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Fix 2FA enforcement in RBAC checks #1512: Adds public.get_current_plan_max_org usage paths and ties into the same check_min_rights permission logic referenced by this change.
• fix(api): allow org password verify #1547: Modifies org-level RBAC helpers and no-password-policy RBAC RPCs that overlap with get_identity_org_allowed/check_min_rights patterns used here.
• feat: 2FA enforcement - database #1300: Updates check_min_rights behavior (2FA/enforcement) which directly affects authorization performed by the new function.

Poem

🐰 I hopped to the DB with a curious glance,
Wrote a tiny guard so plans stand no chance,
Only true friends can peek at the store,
Anonymous knocks — they get zero, no more.
A carrot for safety, a nibble, encore! 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: restricting the plan max RPC function to authorized org callers, which matches the security hardening implemented in the migration.
Description check	✅ Passed	The description covers the key aspects: summary of changes, test plan details, and a completed checklist section. All critical information about the security enhancement is documented.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch riderx/fix-plan-rpc-leak

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

supabase/tests/08_plan_functions.sql (1)

53-53: Minor: Consider explicit type cast for count comparison.

count(*) returns bigint, while 0 is an integer literal. While PostgreSQL handles this implicitly, an explicit cast improves type clarity.

Proposed fix

-        0,
+        0::bigint,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@supabase/tests/08_plan_functions.sql` at line 53, The test compares count(*)
(which yields bigint) to the literal 0; change the literal to an explicit bigint
cast (e.g., use 0::bigint or CAST(0 AS bigint)) wherever the literal appears in
the assertion in the 08_plan_functions.sql test so the types match the count(*)
result and avoid implicit coercion.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@supabase/tests/08_plan_functions.sql`:
- Line 53: The test compares count(*) (which yields bigint) to the literal 0;
change the literal to an explicit bigint cast (e.g., use 0::bigint or CAST(0 AS
bigint)) wherever the literal appears in the assertion in the
08_plan_functions.sql test so the types match the count(*) result and avoid
implicit coercion.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: fa50bd7a-72cb-4bbe-a04d-1af93d365ec8

📥 Commits

Reviewing files that changed from the base of the PR and between c088165 and 378d7fe.

📒 Files selected for processing (2)

• supabase/migrations/20260308203334_fix_get_current_plan_max_org_access_cli.sql
• supabase/tests/08_plan_functions.sql

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud