HomeRulesBND007
BND007 · High severity

Exposed view may bypass underlying row-level security.

PostgreSQL views use the view creator's permissions by default. In an exposed schema, that can let an API caller bypass RLS that would apply when querying the table directly.

Detection condition

The rule reports a view that remains in a configured exposed schema when final migration state does not set security_invoker to true. BoundaryCI follows CREATE OR REPLACE, ALTER VIEW, and DROP VIEW changes and ignores temporary views.

Why it matters

Views normally check underlying permissions as the view owner. Table owners commonly bypass RLS, so an otherwise-correct policy may not protect rows reached through a definer-rights view exposed by the Data API.

Typical remediation

On PostgreSQL 15 or later, make the view a security-invoker view. Otherwise revoke access from anon and authenticated, or place the view in a schema that the API does not expose.

Use caller permissionssql
create view public.project_directory
with (security_invoker = true)
as
select id, organization_id, name
from public.projects;
Protect the boundary

Make tenant isolation a repeatable pull-request check.

Run the deterministic scanner locally without database credentials, then add Cloud only when your team needs shared history.

Find unsafe exposed views Read the quickstart