All stacks

Lovable · Supabase RLS check

Does your Lovable app protect its Supabase data with real RLS rules?

Lovable turns a prompt into a full-stack React app with a Supabase backend already wired up — auth, database tables, and edge functions included by default.

Database rules are flagged as not-tested on every URL scan — a connected repo scan reviews your migrations and policy files directly instead.

What we look at for Lovable

The checks that matter most for Lovable apps.

Wardloom always runs the full catalogue — these are the ones Lovable projects most often get wrong, based on how the tool tends to generate and deploy code.

Auth and session flaws

We review weak JWT secrets, missing rate limits, and insecure session patterns that show up in code and config.

Login is the front door. Soft session handling is how accounts get guessed, replayed, or shared without you noticing.

Env and config exposure

We look for server-only secrets used in the client, exposed dotfiles, and keys that belong behind the server wall.

AI scaffolds often put REACT_APP_ or NEXT_PUBLIC_ in front of secrets by habit. Config exposure is how private settings become public pages.

Common Lovable mistakes

What builders miss with Lovable.

  • Lovable creates Supabase tables quickly, but Row Level Security policies aren't always turned on for every new table.
  • A table with RLS enabled and zero policies quietly blocks all reads and writes — which can look like a bug, not a security control.
  • Policies copied between tables can reference the wrong column name and pass silently in testing.

What a scan like this can't see

Wardloom is honest about its limits. Database rules (Firestore RLS, Supabase RLS) is not something a read-only scan can verify from the outside — it requires a connected repo scan or a manual review. A clean result means nothing visible was wrong, not that everything was checked.

FAQ

Questions Lovable builders ask.