Insecure Direct Object References (IDOR)

What “Insecure Direct Object References (IDOR)” means (plain English)

Attackers change IDs in requests and can read or modify objects they don’t own. Insecure Direct Object References (IDOR) is a practical security issue for teams using Supabase because exposed tables, storage, or RPC endpoints can return or mutate data beyond intended account boundaries.

How Insecure Direct Object References (IDOR) works in Supabase/Postgres (technical)

When APIs trust object IDs without verifying ownership via RLS or server logic, the database treats sequential or guessable references as valid, enabling enumeration and tampering.

Attack paths & failure modes for Insecure Direct Object References (IDOR)

• Insecure Direct Object References (IDOR): direct API bypass: A frontend endpoint uses GET /api/customers/:id and the caller can swap sequential IDs.
• Insecure Direct Object References (IDOR): migration drift regression: A new table or endpoint references object IDs but ships without additional validation.
• Insecure Direct Object References (IDOR): direct API bypass: No server-side ownership check existed, so attackers retrieved other customers’ data by incrementing the ID.
• Insecure Direct Object References (IDOR): migration drift regression: Security guardrails were missing, so the migration exposed unprotected direct references that attackers could abuse.
• The configuration doesn’t match what the UI implies (direct API access bypasses the app).
• Policies/grants drift over time and widen access without anyone noticing.
• Fixes are applied without verification, leading to false confidence.

Why Insecure Direct Object References (IDOR) matters for Supabase security

IDOR lets attackers touch arbitrary records or assets just by manipulating identifiers in the URL. If Insecure Direct Object References (IDOR) remains unresolved, attackers can automate enumeration and unauthorized writes at API speed. Treat it as a production reliability risk as well as a data security risk, because incidents spread quickly once clients discover weak access boundaries.

Common Insecure Direct Object References (IDOR) mistakes that lead to leaks

• Exposing incremental IDs in URLs without verifying ownership.
• Not tying the referenced table to auth claims via RLS.
• Relying on UI gating instead of server-side checks.
• Insecure Direct Object References (IDOR): direct API bypass: No server-side ownership check existed, so attackers retrieved other customers’ data by incrementing the ID.
• Insecure Direct Object References (IDOR): migration drift regression: Security guardrails were missing, so the migration exposed unprotected direct references that attackers could abuse.

Where to look for Insecure Direct Object References (IDOR) in Supabase

• Your grants, policies, and any direct client access paths.
• Storage and RPC settings (common blind spots).

How to detect Insecure Direct Object References (IDOR) issues (signals + checks)

Use this as a quick checklist to validate your current state:

• Try the same queries your frontend can run (anon/authenticated). If sensitive rows come back, you have exposure.
• Verify RLS is enabled and (for sensitive tables) forced.
• List policies and look for conditions that don’t bind rows to a user or tenant.
• Audit grants to anon / authenticated on sensitive tables and functions.
• Insecure Direct Object References (IDOR): direct API bypass: Never trust numeric IDs from the client.
• Insecure Direct Object References (IDOR): direct API bypass: Backend code must validate ownership.
• Insecure Direct Object References (IDOR): direct API bypass: Bind RLS policies to auth claims.
• Re-test after every migration that touches security-critical tables or functions.

How to fix Insecure Direct Object References (IDOR) (backend-only + zero-policy posture)

Mockly’s safest default is backend-only access: the browser should not query tables, call RPC, or access Storage directly.

1. Decide which operations must remain client-side (often: none for sensitive resources).
2. Create server endpoints (API routes or server actions) for required reads/writes.
3. Apply hardening SQL: enable+force RLS where relevant, remove broad policies, and revoke grants from client roles.
4. Generate signed URLs for private Storage downloads on the server only.
5. Re-run a scan and confirm the issue disappears.
6. Add a regression check to your release process so drift doesn’t reintroduce exposure. Fixes that worked in linked incidents:

• Insecure Direct Object References (IDOR): direct API bypass: Move the request behind a backend endpoint that validates ownership or enforces RLS, and reject IDs that don’t belong to the caller.
• Insecure Direct Object References (IDOR): migration drift regression: Add server-side ownership checks, tie referenced tables to RLS, and include automated checks for new endpoints in migrations.

Verification checklist for Insecure Direct Object References (IDOR)

1. Attempt direct access using client credentials and confirm it fails.
2. Apply a backend-only fix pattern and verify end-to-end behavior.
3. Re-run a scan after changes and after the next migration.
4. Insecure Direct Object References (IDOR): direct API bypass: Never trust numeric IDs from the client.
5. Insecure Direct Object References (IDOR): direct API bypass: Backend code must validate ownership.
6. Insecure Direct Object References (IDOR): direct API bypass: Bind RLS policies to auth claims.
7. Insecure Direct Object References (IDOR): direct API bypass: Test API calls with swapped IDs to uncover leaks.
8. Insecure Direct Object References (IDOR): migration drift regression: Migrations can reopen IDOR vulnerabilities.

SQL sanity checks for Insecure Direct Object References (IDOR) (optional, but high signal)

If you prefer evidence over intuition, run a small set of SQL checks after each fix.

The goal is not to memorize catalog tables — it’s to make sure the access boundary you intended is the one Postgres actually enforces:

• Confirm RLS is enabled (and forced where appropriate) for tables tied to this term.
• List policies and read them as plain language: who can do what, under what condition?
• Audit grants for anon/authenticated and PUBLIC on the tables, views, and functions involved.
• If Storage is involved: review bucket privacy and policies for listing/reads.
• If RPC is involved: review EXECUTE grants for functions and whether privileged functions are server-only.

Pair these checks with a direct API access test using client credentials. When both agree, you can ship the fix with confidence.

Over time, keep a small “query pack” for the checks you trust and run it after every migration. That’s how you prevent quiet regressions.

Prevent Insecure Direct Object References (IDOR) drift (so it doesn’t come back)

• Add a repeatable checklist and re-run it after schema changes.
• Prefer backend-only access for sensitive resources.
• Keep one reusable verification test for “Insecure Direct Object References (IDOR): direct API bypass” and rerun it after every migration that touches this surface.
• Keep one reusable verification test for “Insecure Direct Object References (IDOR): migration drift regression” and rerun it after every migration that touches this surface.

Rollout plan for Insecure Direct Object References (IDOR) fixes (without breaking production)

Many hardening changes fail because teams revoke direct access first and only later discover missing backend paths.

Use this sequence to reduce both risk and outage pressure:

1. Implement and verify the backend endpoint or server action before permission changes.
2. Switch clients to that backend path behind a feature flag when possible.
3. Then revoke direct client access (broad grants, permissive policies, public bucket reads, or broad EXECUTE).
4. Run direct-access denial tests and confirm authorized backend flows still succeed.
5. Re-scan after deployment and again after the next migration.

This turns security fixes into repeatable rollout mechanics instead of one-off emergency changes.

Incident breakdowns for Insecure Direct Object References (IDOR) (real scenarios)

Insecure Direct Object References (IDOR): direct API bypass

Scenario: A frontend endpoint uses GET /api/customers/:id and the caller can swap sequential IDs.

What failed: No server-side ownership check existed, so attackers retrieved other customers’ data by incrementing the ID.

What fixed it: Move the request behind a backend endpoint that validates ownership or enforces RLS, and reject IDs that don’t belong to the caller.

Why the fix worked: The server now enforces identity before returning data, so swapping IDs no longer works.

Key takeaways:

• Never trust numeric IDs from the client.
• Backend code must validate ownership.
• Bind RLS policies to auth claims.
• Test API calls with swapped IDs to uncover leaks.

Read full example: Insecure Direct Object References (IDOR): direct API bypass

Insecure Direct Object References (IDOR): migration drift regression

Scenario: A new table or endpoint references object IDs but ships without additional validation.

What failed: Security guardrails were missing, so the migration exposed unprotected direct references that attackers could abuse.

What fixed it: Add server-side ownership checks, tie referenced tables to RLS, and include automated checks for new endpoints in migrations.

Why the fix worked: Proactive validation ensures regressions don’t reopen IDOR as features evolve.

Key takeaways:

• Migrations can reopen IDOR vulnerabilities.
• CI should enforce ownership and policy checks.
• Watch new endpoints that accept object IDs.
• Treat all ID parameters as attacker-controlled.

Read full example: Insecure Direct Object References (IDOR): migration drift regression

Real-world examples of Insecure Direct Object References (IDOR) (and why they work)

• Insecure Direct Object References (IDOR): direct API bypass — Direct object references allow attackers to bypass the UI.
• Insecure Direct Object References (IDOR): migration drift regression — A regression in a migration reintroduced IDOR exposure.

Related terms

• Broken Object Level Authorization (BOLA) → /glossary/broken-object-level-authorization
• Tenant ID Trusted from Client → /glossary/tenant-id-trust-in-client