Security basics for things you vibe coded

An AI writes code that satisfies your description. Your description almost certainly did not mention rate limiting, input validation or who is allowed to call what, so the code does not have them. That is not a failure of the model; it answered the question you asked.

These five checks cover most of what actually goes wrong. None require deep security knowledge and all of them can be handed back to the same assistant.

Get your secrets out of the code

The single most common problem. If an API key, token or password appears literally in a file, it is one public repository away from being scraped. Apps watch GitHub for exactly this and find keys within minutes.

Move every one into an environment variable. If a secret has ever been committed, rotate it. Deleting the line does not help, because the old commit still holds it.

// no
const key = 'sk-abc123realkeyhere';

// yes
const key = process.env.API_KEY;

Assume every input is hostile

Anything a user can type, an app command argument, a form field, a URL parameter, will eventually contain something you did not expect. Sometimes by accident, sometimes not.

Ask your assistant directly: "what happens here if the input is empty, enormous, or contains SQL or HTML?" It is good at this when asked and silent about it when not.

Check who is allowed to do what

A generated admin command usually has no permission check, because you did not say it needed one. Anyone who can see the command can run it.

For a Discord app that means checking roles before anything destructive. For a web app it means checking the session on the server, not just hiding the button in the interface. A hidden button is not a permission.

Add a limit to anything that costs money

If your project calls a paid API, someone will eventually call it in a loop. Put a per-user rate limit on it. The version of this story that ends badly is always a bill rather than a breach.

Keep your dependencies boring

AI sometimes suggests packages that are obscure, abandoned or hallucinated outright. Before installing something you have not heard of, check it exists, is maintained, and is the package the tutorial actually meant.

It also helps to install with scripts disabled, so a package cannot execute code at install time. That is the default on Spocket for the same reason.

A prompt that does most of this

Paste this into whichever assistant built the project: "Review this for security problems. Look for hardcoded secrets, missing input validation, missing permission checks on destructive actions, missing rate limits on anything that costs money, and dependencies that are unmaintained. For each, show me the line and the fix."

It will find most of it. Not all, but the gap between none of this and most of it is far larger than the gap between most and all.