Security basics for vibe coding: what cannot be missing

What to check before publishing an AI-generated app: access control, keys, input validation and dependencies, with a short checklist and open sources.

info Quick Definition
Security basics in vibe coding are a short set of checks anyone can run before publishing an AI-generated app: who can see what, where keys live, which data is validated and which dependencies are used. They do not replace an audit, but they cover the most frequent mistakes.

Why is the risk high?

An AI generates code that works. That does not mean it is secure. In July 2025 Veracode published a study of more than 100 language models on 80 programming tasks: in 45% of the test cases the generated code introduced vulnerabilities from the OWASP Top 10. The models failed to protect against cross-site scripting (CWE-80) in 86% of cases, and in Java the failure rate exceeded 70% (Veracode, July 2025). These are controlled tasks and a study by a security company, not a measurement of your app. Even so, it is enough to take review seriously.

The reference framework for web applications is the OWASP Top 10. Its 2025 edition lists, among other categories, broken access control, security misconfiguration, software supply chain failures, injection and authentication failures (OWASP Top 10:2025). The checks below cover the ones that most affect people who build without writing every line by hand.

Can one user see another user’s data?

This is the first question, because broken access control tops the OWASP list. Its classic example is an address with an acct parameter carrying the account number: if the server does not check who owns it, changing that value is enough to see someone else’s account (OWASP, A01:2025). OWASP also sets two rules: deny by default, except for public resources, and enforce access in trusted server-side code, not in the browser.

Test with two different accounts and change identifiers in the address. Hiding a button does not count as a rule.

If your app uses Supabase and queries the database from the browser, the rule lives in the database as Row Level Security (RLS). Its documentation says a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that once RLS is enabled, no data is accessible with the publishable key until you create policies (Supabase, Row Level Security). Ask the AI to enable RLS and write per-user policies, then check them with two accounts. The details are in databases for designers and frontend vs. backend.

Where do keys live, and what do I do if one leaks?

No private key should be in the code that reaches the browser. The same Supabase documentation says a secret key must never be used in the browser or exposed to customers. Search the project for words such as key, token or secret, and review variables with a public prefix, which end up inside the browser’s code. Which key can go there and which cannot is covered in environment variables and secrets.

If a secret key was already published, GitHub says to consider it compromised. The most important step is to revoke it with the service that issued it; deleting it from the code is not enough, because it may remain in the repository history (GitHub, remediating a leaked secret). If revoking it would cause downtime, GitHub suggests generating a new one with the same permissions first and then revoking the old one.

How do I validate what users type?

Anything a user types can be anything. A basic test: type unusual characters into each field (quotes, angle brackets, very long text) and see whether the app breaks or shows something it should not.

OWASP’s input validation guide says to validate on the server even when the browser checks the same fields, and to define what is accepted and reject the rest rather than trying to recognize every malicious string. It also separates validation from the defenses against injection: parameterized queries for SQL, and context-aware output encoding for XSS (OWASP, Input Validation Cheat Sheet). If you do not know whether your code uses them, ask the AI where each query is built and where each piece of user text is displayed.

What do I do about dependencies?

The libraries the AI installs are third-party code. OWASP includes software supply chain failures (A03:2025) and recommends keeping an inventory of components, including dependencies of dependencies, and getting them only from official sources (OWASP, A03:2025).

In practice: review which packages were added in each change. If one appears that you did not ask for or do not recognize, ask why it is there and what would be needed without it.

What do I review at each publication?

A five-minute list you can repeat:

  • Do two accounts see only their own data, and can they not change identifiers in the address?
  • Are there secret keys in files the browser downloads or in the repository?
  • Do the fields reject unusual text without breaking the app?
  • Were dependencies added that you do not recognize?
  • Is there an error log that someone actually reads?

If any answer is no, the change is not ready for real users. Keep the date of each review next to the project: without a date you do not know when to repeat it. Addy Osmani recommends treating generated code like a junior developer’s work: it needs review and testing before it goes in (Osmani, Beyond Vibe Coding).

If the code is not yours and you do not understand it, start with reading code without knowing how to program. If the agent runs on your machine, see also sandboxing and permissions. And if you doubt the project should be vibe coded at all, review when not to vibe code.

Example

Illustrative example: a designer publishes an app so her clients can see their quotes. The demo works. The five-minute list reveals two problems: with two accounts, one client can see another client’s quote by changing the number in the address, and the email service key appears in a file the browser downloads. She asks for access to be verified on the server, moves the key into an environment variable that only the server reads, and revokes the old key at the email service. Then she repeats the test with both accounts. The demo did not show it, but the list did.

Common mistakes

  • Trusting that the AI already generated secure code.
  • Reviewing only the happy path with a single account.
  • Hiding a button and assuming the action is restricted.
  • Deleting a key from the code without revoking it at the service.
  • Validating only on screen.
  • Accepting new dependencies without asking why they are there.
  • Publishing without a plan to review errors afterwards.

Sources

Frequently asked questions

What should I check first for security?
Access control: that each user sees and changes only their own data, and that the rule is enforced on the server or in the database, not only on screen.
What happens if a secret key ends up in the code or in a repository?
Treat it as compromised. The most important step is to revoke it with the service that issued it and create a new one; deleting it from the file is not enough, because it may remain in the repository history.
Does AI-generated code always have security flaws?
Not always, but the risk is real. In a 2025 Veracode study, models introduced vulnerabilities in 45% of the test cases, so review is not optional.
Is it enough to review security once?
No. Review again whenever permissions, data or dependencies change, and before every significant publication.