The Lie We Tell Ourselves in the Browser
Here is a pattern that ships to production every single day:
if (user.tier === 'premium') {
renderTheExpensiveIntelFeed();
}
It looks like access control. It is not. It is a rendering hint. The data already left your server, traveled across the wire, and landed in a JavaScript bundle the user fully controls. The if statement decides whether to paint pixels — it decides nothing about who can read the bytes. Open the network tab, find the JSON, and the "premium" feed is yours for free.
The same illusion scales up. Middleware that redirects an anonymous visitor away from /dashboard feels like a wall. But middleware guards routes, and the interesting data does not live at a route — it lives behind an API call or a direct database query that an attacker can replay with curl and a stolen anon key. Every gate you build above the database is a speed bump. Useful for UX, worthless against anyone who opens the hood.
The only boundary that holds is the one evaluated inside the database, on every row, on every query, no matter who is asking or how. In Postgres that is Row Level Security.
What RLS Actually Changes
RLS moves the authorization decision from "did the application remember to check?" to "the row physically does not exist for this caller." When RLS is enabled and a policy says
create policy "own_rows" on intel_reports
for select
using (auth.uid() = owner_id);
then a SELECT * FROM intel_reports issued with a user's token returns only that user's rows — not because the app filtered them, but because the engine refuses to materialize anyone else's. Forget a WHERE clause in your API and you leak nothing. Get popped by an injection that turns a query into OR 1=1 and you still leak nothing. The policy is the floor, and the floor does not move.
This is the property you want: secure by default, even when the application is buggy, lazy, or compromised. Defense in depth means the innermost layer assumes every outer layer has already failed.
The Trap: Enabled Is Not the Same as Protected
Two switches, and people conflate them constantly:
alter table intel_reports enable row level security; -- switch 1
create policy ... on intel_reports ...; -- switch 2
Enabling RLS with no policy denies everyone (except the table owner and anything using the service-role key, which bypasses RLS entirely). That is a perfectly valid lockdown for server-only tables — audit logs, security events, webhook records — where nothing client-side should ever read a row.
But the more dangerous state is the inverse, and it is silent: a table where you wrote policies but never enabled RLS. The policies sit there, dormant, enforcing nothing, while the dashboard shows a reassuring lock icon and you move on. Verify the actual state, never the assumed one:
select
c.relname as table_name,
c.relrowsecurity as rls_enabled,
count(p.polname) as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policy p on p.polrelid = c.oid
where n.nspname = 'public' and c.relkind = 'r'
group by c.relname, c.relrowsecurity
order by rls_enabled, table_name;
Read that output as a checklist. A table with rls_enabled = false is wide open to anyone holding the anon key, regardless of how many policies you defined. A table with RLS on and policy_count = 0 is fully locked to clients — intentional for service-only tables, a bug for anything users need to read. Run this after every migration. The gap between "I added policies" and "policies are enforced" is exactly where breaches live.
A Tiering Model That Survives Contact
Most real products are not just "logged in vs. not." They are tiered: free, paid, and paid-more. The instinct is to scatter tier checks through the API. Resist it. Push the tier into the row-access decision so the database itself knows what a Free user may not touch.
-- Threat intel is a paid feature. The row simply does not exist for free users.
create policy "paid_members_only" on threat_intelligence
for select to authenticated
using (
exists (
select 1 from subscriptions s
where s.user_id = auth.uid()
and s.status in ('active', 'trialing')
)
);
Now the paywall is not a banner or a redirect — it is a fact about reachability. A Free user who scripts the API directly, replays a request, or inspects the bundle gets the same answer the UI gives them: nothing. The subscription table is the single source of truth, and it is consulted on every read. When a subscription lapses, access evaporates on the next query with zero deploy and zero cache to bust.
Keep the writes on the trusted side. Your Stripe webhook should run with the service-role key (which bypasses RLS) so it can update any user's subscription, while every browser-originated request runs as authenticated and is held to the policies above. Trusted server writes, constrained client reads — that asymmetry is the whole game.
The Operating Discipline
Database-level authorization is not a feature you add once. It is a posture you maintain:
- Enable RLS on every public table by default. Decide access explicitly, table by table. A table with no decision is a table you have not secured.
- Treat the service-role key like a root password. It bypasses every policy. It belongs in server environments only — never in a client bundle, never in a repo, never in a
NEXT_PUBLIC_variable. - Re-run the verification query in CI. A migration that creates a new table without RLS should fail the build, not surprise you in an audit six weeks later.
- Write the policy in the same migration as the table. The window between "table exists" and "table is protected" should be zero lines long.
The browser check stays — it makes the product feel right, hides what users should not see, and saves a round trip. But understand it for what it is: courtesy, not security. The wall is in the database. Build it there, verify it is load-bearing, and let every layer above it be the speed bump it was always going to be anyway.
Securing a tiered or multi-tenant platform and want a second set of eyes on the authorization model? That is the kind of work FLLC does. Get in touch.