Les familles de failles d'une app vibecodée

A way of grouping the security defects most often found in an application built through vibecoding. Unlike the tells visible from outside, none of these can be read from the browser: they live in the code, the database and the configuration. They sort into four families according to who can exploit them, and at what cost. **Family 1, what has already been read.** A database readable by anyone, an API key sitting in browser-side code, passwords pushed to the repository, access tokens kept in browser storage. By the time you find the secret, it is public. **Family 2, what gives way in five minutes.** Passwords stored in plain text, an admin area reachable without authentication, six-character passwords accepted, email addresses never verified, guessable sequential identifiers, self-service promotion to administrator, a server accepting requests from any origin. **Family 3, what needs an attacker who is aiming.** A server that trusts whatever it receives, an API with no call ceiling, user text concatenated into a database query, a comment that executes in someone else's page, webhooks accepted without a signature, files uploaded with no type or size check. **Family 4, what decays on its own.** Browser permissions left open, error messages exposing the internals, dependencies never updated. Nothing breaks on launch day, everything gets worse afterwards.

Strengths

Limitations

Best for

Official site

View on Coeurdar