Supabase Row Level Security policy violations
A Row Level Security violation means Postgres rejected a write that the active policy did not allow. The protection worked, but the request can still reveal an application regression, a broken client, or an attempt to act outside the user's permissions.
Defencecore monitors supported Supabase database events for writes rejected by Row Level Security and brings suspicious activity into an investigation. The available table, application, role, and event context helps a responder understand what the policy stopped.
An RLS violation is not evidence that the policy was bypassed. It means the database rejected an operation, and the next step is to determine whether the request came from a client bug, a policy change, or hostile behavior.
What Defencecore watches for
- Database activity that Supabase identifies as a Row Level Security policy violation.
- Repeated rejected writes that merit investigation.
- Available database context that helps connect the event to an application or table.
Why the event matters
The policy blocked the operation, which is the intended security outcome. Normal application traffic should still not repeatedly request actions that its authorization model denies.
The activity may point to a policy regression or broken client after a release. Unexplained activity can also justify a broader review of the user, application, and affected data path.
What customers see
- The affected database context available in the Supabase event.
- A timeline and representative events for the investigation.
- Application, role, and operation details when the source event provides them.
How to interpret the detection
- The event means an operation was rejected; it does not mean data was changed or exfiltrated.
- An authorization error can be caused by application behavior or policy configuration rather than an attacker.
- The evidence should be evaluated alongside deployment history and application context.
First response
- Check whether an application or policy deployment occurred near the first event.
- Review the affected operation, active authorization context, and applicable policy before changing access.
- For legitimate traffic, correct the client or the narrow policy condition that should allow it.
- For hostile traffic, keep the policy protection in place and contain the actor at the appropriate layer.