Cursor · Supabase RLS check
Cursor is an AI-native code editor. It writes and edits code fast, but you're still the one wiring up hosting, environment variables, and deployment.
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 Cursor
Wardloom always runs the full catalogue — these are the ones Cursor projects most often get wrong, based on how the tool tends to generate and deploy code.
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.
We check whether your cross-origin rules are wide open, especially wildcards paired with credentials.
Loose CORS lets other sites call your APIs as if they were yours. Tight origin policy keeps browser traffic on the paths you meant to allow.
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 Cursor mistakes
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