Zero-Trust on the Web: Row Level Security and Defense in Depth

The Limits of Application-Only Authorization

Historically, web developers enforced security exclusively within web controllers or API route handlers:

// Fragile pattern: Any route forgetting this check leaks private data
if (!user.isAdmin) {
  throw new UnauthorizedException();
}
return db.posts.findMany();

If a junior developer or background worker misses a middleware check or makes a raw database query, records leak immediately.

Shifting Security to the Database Engine

With Postgres Row Level Security (RLS), security rules reside directly alongside the tables. Even if an attacker injects queries or accesses an open API endpoint, the database itself denies unauthorized rows:

create policy "Public can view published active posts"
  on public.posts for select
  using (
    status = 'published'
    and published_at <= timezone('utc'::text, now())
    and deleted_at is null
  );

Key Principles for Hardened Architecture

1. Never Trust the Client: Always re-verify session claims and role tables on every server action.
2. Strict Sanitization: Never render raw Markdown without AST parsing and whitelist-based HTML sanitization (rehype-sanitize).
3. Rate Limiting & Honeypots: Throttling anonymous endpoints stops automated credential stuffing and comment spam before it burdens compute or storage.

By combining database-level RLS, secure HTTP headers, and strict validation, you establish an unbreakable security perimeter.