Roadmap · updated 2026-05-25

One scanner.
Every backend policy.

OhMyPolicy is a policy scanner for modern backends. Supabase Row Level Security and Storage policies are live today. Firebase Security Rules, Clerk permissions, and general PostgreSQL RLS validation are next.

Today — live

Supabase RLS Live

Real anon-key HTTP probes against every public table. Per-table READ/WRITE exposure flags and ready-to-run Fix SQL with a Supabase SQL Editor deeplink.

Try it at ohmypolicy.com
Supabase Storage Live

Storage bucket public-access probing. Flags buckets that allow unauthenticated listing or downloads.

Included in every scan

Next — building

Supabase Realtime Q2 2026

Channel and broadcast policy validation. Flags realtime subscriptions that leak rows the corresponding RLS would have blocked.

Firebase Security Rules Q3 2026

Firestore REST exposure scanning with the public Web SDK API key. Same behavior-probe approach: real HTTP requests, no static rule parsing.

Feasibility spike planned after Supabase scanner hits product-market fit
Clerk Permissions Q4 2026

JWT-claim-based permission audit. Verifies that frontend-issued tokens cannot reach backend routes they should not.

User Simulator Q3 2026

Paste any JWT or pick a user — see exactly which rows the user can read or write across every table. Available as a paid tier across all supported platforms.

Planned — 2027 and beyond

General PostgreSQL RLS Planned

Same RLS validation engine for Neon, AWS RDS, Aurora, Cloud SQL, and self-hosted Postgres. RLS is a Postgres-native feature; OhMyPolicy expands beyond Supabase naturally.

CI / CD Integrations Planned

GitHub Action, GitLab CI, and CLI for blocking pull requests that introduce exposed tables. Pairs with the scheduled re-scan tier.

Want a platform prioritized? Email hello@ohmypolicy.com with your stack — votes shape the order.

Try the Supabase scanner

Why one scanner across platforms?

Every modern backend ships some form of client-side data access — Supabase via PostgREST, Firebase via the Firestore Web SDK, Clerk via JWT-stamped tokens. The exposure model is the same in every case: the public client holds a key that the server expects a policy layer to constrain. The same behavior-probe approach that catches Supabase RLS gaps catches Firebase Security Rules gaps. OhMyPolicy unifies that into a single scanner so security debt across stacks shows up in one report instead of three.

How dates work

Quarter labels are targets, not commitments. Priority shifts with what Supabase users actually need — for example, the User Simulator was pulled forward after early scanner users repeatedly asked "but what does this user actually see?". If you want a platform sooner, email us with your scan volume and use case.