examples

Public Table Exposure examples

These examples show how Public Table Exposure problems ship in real apps — and what fixes actually work when tested via direct API access.

Why Public Table Exposure examples matter

It leaks sensitive data or enables operational abuse because the database behaves like a public API endpoint with no server-side checks.

Example	Summary	URL
Public read on profiles table	A public profiles table accepted authenticated SELECTs so anyone could scrape user info.	/examples/public-table-exposure/public-read-on-profiles
Public write on invitations enables abuse	Allowing authenticated users to insert into the invitations table invited attackers to spam invites and rack up costs.	/examples/public-table-exposure/public-write-on-invitations

Examples are most useful when you can translate them into a repeatable fix pattern. This table highlights the “why” behind each fix:

Example	Root cause	Fix pattern	URL
Public read on profiles table	The policy only checked that `auth.uid()` existed, so the authenticated role could read every row.	Drop the broad policy, route the request through a backend endpoint, and return a curated view tied to the requester.	/examples/public-table-exposure/public-read-on-profiles
Public write on invitations enables abuse	No abuse controls existed, so attackers automated invites via the client API and overloaded the system.	Move the insert to a backend endpoint with rate limiting, validation, and logging, and revoke direct client writes.	/examples/public-table-exposure/public-write-on-invitations

Assuming authentication alone is sufficient and granting the authenticated role full table access.
Believing hidden UI components mean the table is private while the DB remains accessible.
Running large SELECTs or writes directly from client code for convenience instead of routing through backend checks.

Across these examples, the highest-leverage fixes share a theme: remove direct client access and make verification repeatable.

Backend-only access for sensitive operations (server endpoints enforce authorization).
Least-privilege grants: revoke broad privileges from anon/authenticated.
Small, testable policies if you intentionally keep client access — avoid complex conditions.
A verification step that proves direct access fails (not just that the UI hides data).

A direct API call returns rows/files even when the UI is supposed to restrict them.
RLS/policies exist, but access still succeeds (often because RLS is disabled or policies are too broad).
Permissions depend on the client behaving “nicely” (UI checks) rather than the database enforcing access.
After a migration, access behavior changes unexpectedly (drift).

Reproduce the issue once using direct API access (anon/authenticated) so you know it’s real.
Apply the fix pattern (backend-only access + least privilege) using a template.
Repeat the same direct access call and confirm it now fails.
Confirm the app still works via backend endpoints for authorized users.
Re-scan after the fix and add a drift guard for the next migration.

Re-run the same direct access test after every migration that touches auth, policies, grants, Storage, or functions.
Keep a short inventory of sensitive resources and treat them as server-only by default.
Review new tables/buckets/functions in code review with an access-control checklist.
If you intentionally allow client access, document the policy rationale and add tests for it.

If you like having a repeatable “proof”, add a small set of SQL checks to your process.

Confirm RLS status for tables involved (enabled/forced where appropriate).
List policies and read them as plain language: who can do what under what condition?
Audit grants to anon/authenticated and PUBLIC for tables, views, and functions tied to this topic.
If Storage/RPC is involved, explicitly audit bucket settings and EXECUTE grants.

These checks complement (not replace) the direct access tests shown in the examples.

If you’re here because you found this topic in a scan, the fastest path depends on whether the fix is a small config change or a workflow change.

Choose a template when you need a copy/paste change plus verification (tighten a policy/grant/bucket setting).
Choose a conversion when you need to change an access model end-to-end (unsafe → backend-only) with example transformations.
Choose an integration when the fix is a workflow pattern you’ll repeat (signed URLs, server-only RPC, backend endpoints).

If you’re unsure, start with the smallest template that removes direct client access, then add integrations for durability.

Teams often “fix” a topic but can’t prove it later. Save a few small artifacts so you can re-verify after migrations:

The direct access request you used before the fix (and the expected denial after).
A short boundary statement (who can access what, through which server endpoint).
The change you applied (policy/grant/bucket setting/EXECUTE revoke) and why.
The drift guard you’ll run after migrations (scan, checklist query, or release checklist item).

Glossary: Public Table Exposure → /glossary/public-table-exposure
Template: Lock down a public table (backend-only access) → /templates/access-control/lock-down-public-table

One fixed example is great — but the real win is preventing drift.

Write a one-sentence boundary statement (who can access what, through which server path).
Keep the one direct access test you used before the fix (and expect it to fail after).
Re-run the same test after migrations that touch policies, grants, buckets, or functions.

If you can re-run the test and it still fails, you’ve turned a one-time fix into a durable control.