View grant exposes sensitive columns

Scenario: View grant exposes sensitive columns (what happened)

The frontend called a view that joined profiles, billing status, and flags, so the team granted SELECT to authenticated for speed.

What went wrong in View grant exposes sensitive columns (root cause)

The view began returning billing data and emails; attackers queried it directly and retrieved columns that were never meant for the browser.

What fixed View grant exposes sensitive columns (actionable change)

Revoke client access, replace it with a backend endpoint that returns a minimal, documented shape, and treat views/functions as API surfaces in your audits.

Why the fix works for View grant exposes sensitive columns

Backend responses are explicit and reviewable, so you stop shipping whatever the view returns to clients.

Takeaways you can apply

• Views become API surfaces when granted to clients.
• Column leaks happen quickly during schema changes.
• Backend endpoints enforce a stable response contract.
• Audit grants for views and functions as well as tables.

How to map View grant exposes sensitive columns to your own schema (make it concrete)

An example becomes actionable when you can point to the exact resource in your project.

1. Write down the resource under test (table name, bucket name, function name).
2. Write down the intended boundary in one sentence (who should be able to do what, and via which server path).
3. List the client code paths that currently reach the resource (direct SDK calls, REST calls, Storage downloads, RPC calls).
4. Pick one path and reproduce the risky behavior once (so you’re not guessing).
5. Apply the smallest fix that enforces the boundary, then re-test the same path until it fails reliably.

This prevents the common failure mode where a fix works for one UI flow but the underlying API is still reachable directly.

How to reproduce View grant exposes sensitive columns safely (so you can verify the fix)

1. Identify the exact resource involved (table name, bucket name, function name).
2. Attempt direct access using the same client credentials your app ships (anon/authenticated).
3. Record what succeeds (status code, rows returned, file downloaded) so you can repeat the same test after fixing.
4. If the example involves policies: confirm whether RLS is enabled and forced on the table.
5. If the example involves Storage: test both object fetch and listing behavior (enumeration often matters).

Signals that confirm the View grant exposes sensitive columns root cause

• You can access the resource without going through your UI or backend endpoint.
• Access is possible with anon/authenticated credentials even though the app implies it shouldn’t be.
• Policies/grants are broader than intended or not enforced (RLS disabled/not forced).
• The fix requires changing both configuration (grants/policies/bucket settings) and application call paths.

Verification checklist after fixing View grant exposes sensitive columns

1. Repeat the exact same direct access test you used for reproduction and confirm it fails (401/403).
2. Confirm the app still works via backend endpoints for authorized users.
3. Re-run a scan or checklist queries and confirm the exposure signal is gone.
4. Check other environments (staging/prod) — drift is a common cause of “fixed in dev” failures.

Variations and edge cases for View grant exposes sensitive columns

• The UI may hide a list view, but the REST endpoint can still be called directly.
• IDs and filenames are often enumerable; security should not rely on “hard to guess.”
• A fix that blocks SELECT may still leave INSERT/UPDATE exposed (or vice versa).
• Storage links can be shared or cached; signed URL TTL and bucket privacy both matter.
• RPC can bypass table policies if functions run with elevated privileges.

How to prevent View grant exposes sensitive columns from coming back (drift guard)

• Add a release checklist item or CI query that flags new public grants/policies/buckets/functions.
• Keep a short runbook: what to test directly when this surface changes.
• Re-scan after migrations and after any change to auth, policies, Storage, or RPC.

What to change in your codebase after fixing View grant exposes sensitive columns

Most exposure fixes fail because teams change config but keep the same client call paths.

A safer pattern is to make the authorized path explicit in server code:

• Create a backend endpoint for the operation (read/write/download/export).
• Enforce authorization in the endpoint (ownership, membership, tenancy).
• Return only the minimum necessary data (avoid overfetch).
• Update the frontend to call the backend endpoint instead of calling Supabase directly.

This turns the fix into an architectural boundary you can test and monitor.

Step-by-step remediation plan for View grant exposes sensitive columns (practical)

Use this as a practical sequence you can follow without guessing:

1. Identify every client code path that touches the resource (table/bucket/function).
2. Implement a backend endpoint that performs the operation with explicit authorization.
3. Deploy the backend endpoint first and validate it works for authorized users.
4. Switch the frontend to call the backend endpoint (feature flag if needed).
5. Revoke direct client access (grants, bucket settings, EXECUTE grants, broad policies).
6. Run the verification checklist: direct access must fail; backend must succeed.
7. Re-scan and confirm the exposure signal is gone.
8. Add a drift guard so the next migration can’t silently reintroduce it.

Post-fix monitoring for View grant exposes sensitive columns

• Watch for spikes in denied access after tightening permissions (it reveals missed app paths).
• Monitor Storage downloads and RPC calls for unusual patterns (automation and scraping often look different than real users).
• Re-run drift checks after migrations and environment changes so the issue doesn’t silently return.

Post-fix evidence checklist for View grant exposes sensitive columns

Keep these small artifacts so a teammate can validate the boundary quickly after a migration:

• A saved pre-fix direct access request (the one that succeeded).
• The same request after the fix (must be denied).
• A note describing the authorized backend endpoint path and the authorization rule it enforces.
• A drift guard item you can run after future migrations (scan, checklist query, or release step).

This reduces the chance of silent regressions and makes incident response faster.

Related links

• Topic: Client Role Grants (anon/authenticated) → /examples/client-role-grants
• Glossary: Client Role Grants (anon/authenticated) → /glossary/client-role-grants
• Template: Remove over-permissive RLS policies (adopt deny-by-default) → /templates/access-control/remove-over-permissive-policies