Your PostgreSQL Query Works. That's Exactly What Makes This Bug Dangerous.

Description and use

In a multi‑tenant SaaS, relying only on application code for tenant filtering can expose data. A Rust proxy verifies tenant context, maps to PostgreSQL roles, and works with RLS to prevent leaks.

Problem

Cross‑tenant data leaks can occur when a multi‑tenant SaaS application relies solely on application code for authorization, allowing a missing check to expose another customer’s data without triggering errors.

Outcome

By inserting a tenant‑verification layer between applications and PostgreSQL, the proxy prevents accidental cross‑tenant data exposure while complementing existing RLS and role grants.

Workflow

• 1. Client connects to proxy instead of PostgreSQL directly.
• 2. Proxy verifies signed tenant context during connection startup.
• 3. Proxy rejects invalid, expired, or missing tenant credentials.
• 4. Proxy maps verified tenant identity to a PostgreSQL role.
• 5. PostgreSQL executes query with role‑based access and RLS policies.
• 6. Proxy records operational metrics and attestation logs.

Evidence

If authorization depends entirely on application code, one missing check could expose another customer's invoice.

Source

I built an open‑source Rust proxy that sits between PostgreSQL clients and an existing PostgreSQL database.

Source

Verify signed tenant context during connection startup.

Source

Work alongside PostgreSQL grants and Row‑Level Security.

Source