The Security Checklist for AI-Generated Code

Security flaws in AI-generated code aren't random. Research into generated code keeps finding the same classes of vulnerability appearing at elevated rates — not because models are careless, but because they learned from the open internet, where insecure patterns are common. That's actually good news: a predictable weakness is one you can check for systematically.

Here's a checklist that covers the failure modes that matter most, roughly in the order they bite.

1. Find every place user input touches the app

Forms, URL parameters, file uploads, anything typed or pasted. Generated code often uses input directly — inserting it into the page, a query, or a command — without validation or escaping. That's the root of injection and cross-site scripting (XSS) problems.

Check: every input is validated on arrival, and anything rendered into the page is escaped or set as text, not raw HTML. Be suspicious of any generated code that assigns user data to innerHTML.

2. Hunt for secrets in the source

Models put API keys, passwords, and tokens wherever the code needs them — including directly in client-side files, where anyone can read them with view-source. Client code is public by definition.

Check: search the project for "key", "token", "secret", and "password". Anything real belongs on a server or in environment configuration, never in shipped files.

3. Confirm protected things are actually protected

An admin page that's merely unlisted is not protected. Generated apps frequently gate features with a client-side check — a passcode compared in JavaScript, a hidden route — that anyone can bypass by reading the code.

Check: every page or action that shouldn't be public has a server-side check, not just a hidden link or a front-end gate.

4. Review what the app sends and stores

Watch the network traffic while you use the app. Look for personal data going places it doesn't need to go, requests to services you didn't add, and sensitive values stored in plain browser storage where any script on the page can read them.

5. Vet the dependencies

Models sometimes import packages that fit the problem but that you never chose — occasionally ones that don't exist at all, a failure mode attackers have started to exploit by registering plausible-sounding package names. Every dependency is code you're shipping.

Check: read the import list. Remove what you don't need; verify what you keep is the real, maintained package.

6. Make failure private

Generated error handling often echoes raw error details to the user — stack traces, file paths, query fragments. Those are a map for an attacker.

Check: users see friendly messages; details go to logs you control.

Where Vibe Coder Playground fits: steps one and four are behavioral — you can't confirm them by reading code, only by watching the app run. The Playground shows the rendered DOM, network calls, and state of your own build as it executes, so you can see exactly what gets sent, stored, and rendered before a user ever does.

Make it a ritual, not a rescue

None of this requires a security background — it requires consistency. Run the checklist before anything goes live, and again after any large regeneration. Ten focused minutes here is the cheapest insurance in software.