How to Secure an App You Didn't Fully Write

You secure an app you didn't fully write by treating the AI as a junior developer whose work you have to review, not a finished contractor you can trust blindly. You don't need to understand every line — you need to check a short list of specific things and, where they're wrong, hand the fix back to the same AI tool in plain language. The five that matter most for a non-expert: get secrets out of the browser, make sure the server (not just the screen) decides who's allowed in, cap what a single user can spend and request, hide internal error details, and turn on monitoring. Each one is a question you can ask and a fix you can request without a computer-science degree.

The mindset shift: the AI is a junior developer

A junior developer can write a working feature fast and still leave the door unlocked, because they focused on making it work. That's exactly what an AI builder does. You wouldn't ship a junior's first draft to real customers without a review — and you shouldn't ship the AI's either. The difference is that you can't lean on the AI's judgment about what's safe, because it doesn't have any; it has patterns. So you hold the checklist, and the AI does the typing.

The five questions to ask (and how to fix each)

1. "Are any passwords or keys visible in the browser?"

API keys and credentials must live on the server, not in code that loads in the browser. You can check this yourself: open your live site, open the browser's developer tools, and search the loaded files for key or sk-. If you find a real key, that's the highest-priority fix. The instruction back to the AI: "Move this API key into a server-side environment variable and read it from the server, not the client."

2. "Does the server decide who's allowed in, or just the screen?"

If your app hides a page unless you're logged in, ask whether the server also refuses to send that page's data to someone who isn't allowed. Hiding a screen isn't protecting it. The fix request: "Add a server-side authorization check to every protected route and API endpoint, so the data isn't returned unless the user is verified and allowed."

3. "What's the most one user can cost me or demand from me?"

If your app calls an AI service, or does anything expensive, ask what stops one person from doing it ten thousand times. The fix request: "Add per-user daily limits and a per-endpoint rate limit, and set billing alerts on the AI API at 50%, 80%, and 100% of my expected spend."

4. "If something breaks, what does the user see?"

Trigger an error on purpose (enter bad input, visit a wrong URL) and read what comes back. If you see technical detail — file paths, database names, long stack traces — that's leaking. The fix request: "In production, return a simple, generic error message to users and log the technical detail privately instead."

5. "Will I know if it goes down?"

Ask how you'd find out if the app broke at 3 a.m. If the answer is "an angry email," add monitoring. The fix request: "Add error tracking and uptime monitoring, and give me one dashboard that shows if the app is up and whether errors are spiking."

When to stop and get help

This gets you to roughly production-safe — the common, dangerous holes closed. It is honestly not the whole of security. If your app handles money, health data, or anything regulated, or once you have real users and revenue, the responsible next step is professional: automated scanners and a genuine security review by a human who does this for a living. Knowing where your DIY pass ends is itself part of doing it well.

If you'd rather not assemble the five questions and their fixes yourself, the Vibe-Coded App Hardening Kit ($79) packages them: a plain-language antipattern catalog with the exact paste-back prompt for each, a checklist, and a monitoring template — written for the person who shipped an app they didn't fully write. For the bigger picture of what breaks and why, start with the vibe-coding security guide, and use the pre-launch check as your go/no-go.

No-code stacks tend to wire a model almost directly to data, which is precisely the path the free LLM Security Audit checks. Its gate fires only when every link of that path is weak, so bringing any single one up releases it. A self-assessment, not a penetration test.