Vibe Coding and Security: Authentication, Secrets, Vulnerabilities and Dead Code

Security Is Where Vibe Coding Hurts Most

This is the third article in the From Vibe Coding to Production series. We move up to Levels 2, 3, 4 and 5 of the pyramid, the ones that deal with security, and this is where vibe coding exposes you most.

The reason is simple: security is invisible. An insecure app behaves exactly like a secure one, until someone takes advantage. And when that happens, the founder pays the price. These are the four controls you have to clear before going to production.

Level 2: Authentication - Do Not Write It Yourself

One of the most common mistakes in vibe coding is dragging along a fully custom authentication module written from scratch. It is a mistake because authentication is one of those pieces where you should not reinvent the wheel.

Handling login, sessions, password reset and attack protection correctly is hard, and there are mature solutions that do it for you. If you want a managed third-party service, Clerk is an excellent choice. If you prefer to keep authentication inside your application, Auth.js does the job.

Relying on these solutions protects you from an entire category of vulnerabilities: broken logins, badly managed sessions, compromised accounts. It is one of the few cases where the most professional thing you can do is not write code.

Authorization and RLS: When One User Sees Another User's Data

Authentication answers "who are you". But there is a second question, just as critical and almost always forgotten in vibe coding: "what can you see?". That is authorization, and its core is Row Level Security (RLS), the visibility at the level of the single record and, in the most sensitive cases, at the field level.

The typical problem is this: the app has no role hierarchy, or no concept of roles at all. Data visibility is handled with a series of if statements scattered through the code, added as needed, because the average founder does not have the concept of "visibility scope" in mind. It works while there is one user. Then the second arrives, and you discover they can see the first one's data.

RLS done right makes the "who sees what" rule live at the data level, not in dozens of scattered conditions nobody can hold together anymore. It means defining roles and scope separation from the start, and applying record-level (and field-level) visibility in one place.

The catch is that all of this is almost always discovered late. And redoing it after the fact, when the app is already full of ifs and has no role model, is not a patch: it is a rewrite, with huge technical debt. It is one of those levels where paying for the foundation at the start costs a fraction of redoing it later.

Level 3: Secrets and the .env File - Where the Mistake Becomes a Bill

This is the mistake you do not see right away. You notice it later, when you get a bill that burns your entire OpenAI account overnight.

More and more often, inexperienced developers put environment files in publicly exposed paths, with API keys and tokens that end up indexed on the web. Once exposed, a key is compromised, full stop: deleting the file is not enough, it must be revoked and regenerated.

The ideal is not even to have a .env file: it is a setup that stores all variables inside the environment or a secret manager, so there is no physical point to steal. Add periodic token rotation and you drastically reduce the attack surface from the outside.

Level 4: Dependencies and Vulnerabilities - The Mandatory Check

This is the most critical part and, not by chance, the one most often ignored. It is not a refinement: it is a mandatory activity before going to production.

AI does not just write your code. It also brings in dependencies, the libraries your app relies on. And here there is a structural problem: models are trained on old versions, so they tend to suggest libraries that may be outdated or deprecated, sometimes with already published vulnerabilities.

That is why the first vulnerability to check is dependencies and deprecated code. Tools like Dependabot on GitHub warn you automatically when a library has a known flaw and propose the update. It is a check the average AI does not do for you: you have to know it and turn it on.

Level 5: Dead Code - the Flaw Nobody Maintains

Dead code looks like a tidiness problem. It is actually a security problem, which is why we deal with it here.

Vibe coding often leaves dead code behind: functions never called, forgotten endpoints, abandoned logic, parts that are no longer needed. Every line of dead code widens the attack surface of your app, because it belongs to logic that nobody maintains anymore and can hide flaws nobody checks.

There is also a practical point: when the application grows large, AI agents can no longer see all the dead code in it. The bigger the project, the more valuable a human check becomes, an expert who knows what to look for and remove. Keeping the codebase clean is not about aesthetics: it is about reducing the points from which you can be attacked. We discussed this in the guide on how to use AI without creating technical debt.

Security Is Not Optional

Authentication, secrets, dependencies and dead code are not details to fix after launch. They are the base that decides whether your app can host real users and real data without becoming a problem.

At Castaldo Solutions this is the hardening work we do most often on founder-built MVPs: we take something that works and make it secure before exposing it to the world.

In the next article we move up to Level 6 and tackle compliance as a process: the AI Act, Italy's Law 132/2025, fines, and why compliance must be designed in from the start.

Request a security check before going to production.