Write policy missing WITH CHECK

Scenario: Write policy missing WITH CHECK (what happened)

The team focused on SELECT and added a restrictive policy, but writes still happen directly from the client.

What went wrong in Write policy missing WITH CHECK (root cause)

Users could insert or update rows with another user_id or tenant_id, letting them impersonate or escalate privileges.

What fixed Write policy missing WITH CHECK (actionable change)

Move writes behind backend endpoints that enforce ownership and input validation, and mirror the read policies with proper WITH CHECK clauses.

Why the fix works for Write policy missing WITH CHECK

Backend writes let you enforce business rules and log attempts, which is harder to do in scattered policies.

Takeaways you can apply

• Write paths can be riskier than reads.
• Ownership must be enforced on inserts and updates.
• Backend endpoints enable validation and auditing.
• Test both read and write exposure, not just SELECT.

How to map Write policy missing WITH CHECK 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 Write policy missing WITH CHECK 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 Write policy missing WITH CHECK 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 Write policy missing WITH CHECK

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 Write policy missing WITH CHECK

• 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 Write policy missing WITH CHECK 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 Write policy missing WITH CHECK

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 Write policy missing WITH CHECK (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 Write policy missing WITH CHECK

• 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 Write policy missing WITH CHECK

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: Ownership-bound RLS Policies → /examples/ownership-bound-rls-policies
• Glossary: Ownership-bound RLS Policies → /glossary/ownership-bound-rls-policies