Security is one of those things that feels invisible right up until it isn’t. Your app looks fine, users are signing up, everything works. Then one day someone finds your API keys sitting in plain text on GitHub, or a stranger figures out how to see every other customer’s data just by changing a number in the URL.
Neither of those is hypothetical. Both happen to vibe-coded apps regularly, and neither one shows up when you’re clicking around testing the app yourself.
Why AI tools don’t prioritise security by default
Ask an AI coding tool to “add a login page” and it will. Ask it to “let users upload a profile photo” and it will do that too. What it usually won’t do, unless you specifically say so, is think about who shouldn’t be able to log in, or what happens if someone uploads a file that isn’t actually a photo.
This isn’t the tool being careless. Security is invisible when it’s done right, which means it’s rarely the star of the demo code the tool learned from. A tutorial showing “how to build a login form in 10 minutes” is optimizing for speed and clarity, not for blocking brute-force attempts or hashing passwords correctly. The tool absorbed a lot of that kind of example, and it shows up in what it produces unless you push back.
There’s also a simpler reason: security requirements are rarely obvious from a feature description. “Add a comments section” doesn’t tell the tool whether users should be able to edit each other’s comments, or whether comment text should be sanitized before it’s rendered on the page. You know the answer. The tool has to guess, and it usually guesses toward “whatever gets the feature working.”
Seven security red flags you can check yourself
You don’t need to read code to check most of these. Here’s what to look for.
Exposed API keys. If your app calls services like Stripe, OpenAI, or a mapping API, those services give you a secret key. If that key ends up in your frontend code (visible in the browser) instead of staying on your server, anyone can copy it and rack up charges on your account, or worse, access your customer data through it. Open your browser’s dev tools, go to the Network tab, and look at what gets sent to the browser. If you see a key that starts with sk_ or similar, flag it.
No real authentication. Some vibe-coded apps have a login screen that looks convincing but doesn’t actually check anything meaningful behind the scenes. Try logging out and manually typing a URL that should require login, like /dashboard or /account. If it loads without asking you to sign in again, that’s a problem.
SQL injection. This is a classic where a form field gets typed straight into a database command without being checked first. A search box, a login form, even a comment field can be vulnerable. You can’t easily test for this yourself without some technical know-how, but it’s worth asking whoever built your app whether they used a query builder or ORM (which usually protects against this by default) rather than writing raw SQL strings by hand.
Open API endpoints. Your app likely talks to a backend server to fetch and save data. Try visiting those backend URLs directly (they often look like /api/users or /api/orders) while logged out. If you can see data you shouldn’t, the endpoint isn’t checking who’s asking.
Missing rate limiting. Try submitting your own login form or contact form repeatedly, fast, in a short window. If nothing stops you or slows you down, neither will it stop someone trying to guess passwords or spam your inbox.
Weak or default admin access. If your app has an admin panel, check whether the login still uses a default username and password, or a password you set once during development and forgot about. Attackers scan for exactly this.
No data separation between users. Log in as one test account, note the ID in the URL (something like /orders/1042), then change that number and see if you can view someone else’s order. This single check catches a surprising number of vibe-coded apps.
What actually happens when this goes wrong
The consequences aren’t abstract. A leaked API key can rack up thousands of dollars in unexpected charges before anyone notices. A missing permission check can expose every customer’s email, order history, or payment details to anyone who thinks to try it.
If you’re handling any personal data from users in the EU or UK, a breach like this isn’t just embarrassing. GDPR requires you to report qualifying breaches to the relevant authority within 72 hours of becoming aware of them, and failing to do so, or having inadequate security in the first place, can bring fines calculated as a percentage of your revenue. Small companies aren’t exempt just because they’re small.
There’s also the quieter cost: the customer who finds out their data leaked and tells three other people not to trust your app. That kind of damage doesn’t show up in a support ticket. It just shows up as churn you can’t explain.
A quick self-audit checklist
Set aside twenty minutes and work through this:
- Open dev tools and check the Network tab for exposed API keys
- Log out, then try to load a page that should require login
- Change an ID in the URL to see if you can access someone else’s data
- Try your own forms with rapid repeated submissions
- Check whether your admin login uses anything other than a strong, unique password
- Ask whoever built the app whether user input is validated on the server, not just in the browser
- Confirm whether personal data is encrypted at rest, not just in transit
If any of these turn up something concerning, don’t panic and don’t try to patch it yourself under pressure. A rushed fix to a security hole often introduces a second one.
Don’t wait for a breach. Get a security audit, and we’ll tell you exactly where your app is exposed and how to close it before someone else finds it first.