The 5 security checks Lovable's built-in scanner doesn't do

Lovable has made incredible progress in helping non-developers ship real web apps. And to their credit, they have built-in security checks that catch some basic issues. But there are critical classes of vulnerabilities that a built-in scanner architecturally cannot detect.

What Lovable does check

Lovable's security features include basic checks like ensuring HTTPS is used, checking for common HTTP security headers, and validating that environment variables are not exposed in client code. These are good first-line defenses.

The 5 checks it misses

1. Supabase RLS policy logic validation

Lovable can see that you have RLS enabled, but it cannot evaluate whether your policies actually protect data. A policy like USING(true) reads as "RLS enabled" but provides zero security. To validate policy logic, you need to connect to the actual Supabase project and query pg_policies, then analyze the SQL expressions. This requires database-level access that a code-generation tool does not have.

2. Cross-table data leakage through joins

Even if individual tables have proper RLS, data can leak through foreign key relationships. If table A has strict RLS but table B (which references table A) has USING(true), an attacker can read table A's data through table B's exposed API endpoint. Detecting this requires understanding the full relational schema and testing actual API responses.

3. Supabase service role key exposure

The Supabase service role key bypasses all RLS. If this key ends up in client-side code (which happens when AI tools confuse SUPABASE_SERVICE_ROLE_KEY with NEXT_PUBLIC_SUPABASE_ANON_KEY), your entire database is exposed regardless of your RLS policies. Detecting this requires scanning the built JavaScript bundles, not just the source code.

4. Auth flow vulnerabilities

AI-generated auth flows often have subtle issues: missing email verification, no rate limiting on login attempts, password reset tokens that do not expire, or OAuth callbacks that accept arbitrary redirect URIs. These are logic bugs that require dynamic testing of the actual authentication endpoints, not static code analysis.

5. Payment and billing logic bypass

Apps that integrate Stripe or other payment providers often have a gap between what the frontend thinks the user paid for and what the backend actually enforces. For example, an AI might implement a "Pro tier" check purely in the React component, with no server-side validation. An attacker can simply call the API endpoints directly, bypassing the frontend paywall entirely.

Why deep scanning matters

These five categories represent the most exploited vulnerabilities in AI-built apps. They all share a common trait: they require runtime analysis, not just code inspection. You need to actually connect to the database, send requests to the API, and observe the behavior.

This is exactly what Sekrd's deep scan does. We connect to your Supabase project, test every RLS policy, analyze your auth flows, check for exposed secrets in your built bundles, and verify that payment gates are enforced server-side. It takes two minutes and catches what code-level tools cannot.