Medium

INSERT policy "Members create tickets" has no WITH CHECK

Affected:: public.support_tickets
Category:: RLS Security
Confidence:: high
First detected:: 2026-08-12 11:04Z
Last verified:: 2026-08-16 09:41Z

Summary

Writes to public.support_tickets are not validated against the caller's tenant.

Why this matters

A caller can insert rows attributed to another organization, poisoning data another tenant will later read.

Evidence

Relation: public.support_tickets
Policy: Members create tickets
Command: INSERT
WITH CHECK: (none)

Facts above were derived by the scanner from database metadata. No model output is involved in the verdict.

Technical details

pg_policies.with_check is null for a write command, so PostgreSQL accepts any candidate row the caller supplies.

recommended remediation

Unlock Full Audit (Demo)

Bottom 35% of Supabase projects we've scanned.

Production-Ready Fixes

Ready to scan your own database?

Buy Remediation Credits — $19

Includes 5 Activation Credits

Add a WITH CHECK expression binding organization_id to the caller's tenant.

Current

Policy: Members create tickets
Command: INSERT
WITH CHECK: (none)

Recommended Review

This INSERT policy has no WITH CHECK expression.

DBXray cannot automatically generate the missing tenant constraint because it requires application-specific authorization logic.

Review this policy and add a WITH CHECK clause that binds a tenant column to the caller's identity.

Expected security effect

Row ownership validated on write
Cross-tenant write path removed

No migration generated — application intent required.

Compatibility risk

high

Clients that omit the tenant column on insert will need to set it, or a trigger should default it.

DBX never applies SQL to your database.