Why "vibe-coded" apps get hacked: 5 mistakes we see constantly
Roundup · 7 min read
Speed and security trade off, whether you notice or not
AI-assisted development has made it normal to go from idea to a live, working app in a weekend. That's genuinely good, but the parts of an app that don't show up as a visible bug (a missing header, a key that shouldn't be public, a permissive database policy) don't get caught by "does it work?" testing, because the app works fine either way. Here are the five we run into most, in order of how often we see them.
1. Secrets leaked in client-side JavaScript
API keys, and especially Supabase's service_role key, ending up in the browser bundle because a server-only environment variable got read from a client component. The key works, the feature ships, and the key is now readable by anyone who opens dev tools. More on this →
2. Row Level Security left open
Supabase and similar backend-as-a-service platforms put your database one API call away from the public internet by design. RLS is the only thing deciding what's actually readable. A placeholder policy like USING (true), written during development and never tightened, leaves every row exposed even though RLS shows as "enabled." More on this →
3. Missing or weak security headers
No Content-Security-Policy, no HSTS, no X-Frame-Options: none of these break the app, so they're rarely the first thing anyone adds. Each one closes off a specific, well-understood attack: CSP against XSS, HSTS against protocol-downgrade attacks, X-Frame-Options against clickjacking. More on this →
4. Exposed .env and .git directories
A default server configuration, or a static export that includes the whole project directory, can leave .env or the entire .git folder reachable at a predictable URL. .git/config and .git/HEAD being fetchable often means the full commit history, and anything ever committed to it (including old secrets), is downloadable.
5. Outdated JavaScript libraries with known vulnerabilities
A dependency pulled in months ago and never updated can carry a publicly known, already-patched vulnerability. Attackers don't need to find a new bug. They check a site's loaded library versions against public vulnerability databases and see what's already documented.
The common thread
None of these are exotic. They're all things that are easy to check for once you know to look, which is the entire premise of Auditly: run the checks that matter automatically, instead of hoping someone remembers to do them before shipping.
Run a free preview scan →