Verifiedapp Blog
Vibe Coding

AI wrote my backend — so who owns the security?

· 3 min read
#ai-coding#appsec#responsibility#vibe-coding

The question every vibe coder eventually asks

You described a feature, an AI tool wrote the backend, it works, you shipped. A few weeks in, a thought lands: if something is wrong in that code, whose problem is it? The honest answer is yours — and that is not a scolding, it is just how shipping works. The person who deploys owns what they deploy.

Why AI does not own it

An AI assistant is very good at one thing: building what you asked for. You asked for a signup form, a Stripe checkout, an upload endpoint — and you got working versions of exactly those. What you did not ask for, it did not add. Nobody types prompt me a Content-Security-Policy or keep this key off the client, so those parts quietly do not happen.

This is the core dynamic, and it is worth saying plainly: AI writes the code you asked for, not the security you did not mention. That is not a flaw in the tool. It is a gap in the request.

A simple ownership model

Think of it as three layers, and notice who is on the hook for each:

  • The framework handles the deep, invisible stuff — memory safety, request parsing, crypto primitives. You inherit this for free.
  • The AI handles the feature code — the routes, the queries, the UI you described. Accurate to your prompt, blind to what you left out.
  • You own the gap between what you asked for and what a safe production site needs. That gap is where almost all real findings live.

The good news: that gap is small, well-known, and checkable. It is not a mystery.

What usually sits in the gap

Across AI-generated sites, the same handful of things show up:

  • A secret key used in client code, so it ships in the browser bundle.
  • A .env or appsettings.json committed and deployed where it is reachable.
  • Missing security headers — no Content-Security-Policy, no HSTS — because frameworks rarely set them.
  • Old TLS protocols still enabled on the host.
  • A source map or backup file left in the public folder.

None of these are exotic, and none of them mean the AI did a bad job. They are normal hygiene, and they are normal precisely because the request never covered them. The same site that nails its feature requirements can miss every one of these, because they live in a different conversation — the one nobody had.

Owning it is one habit, not a rewrite

You do not need to stop using AI or audit every line by hand. You need one verification step between you wrote it and the world depends on it. An automated scan reads your live site the way an outside bot would and tells you what is actually exposed — so the part you own becomes visible instead of assumed. Scan your site and see exactly which part of the gap is yours to close.

Related reading

FAQ

If an AI tool wrote my code, is the vendor responsible for security?
No. The platform secures its own infrastructure, but the code you generate and deploy is yours to operate. Whoever ships the site owns its security posture, regardless of who or what wrote the lines.
Does using AI make my site less secure?
Not inherently. AI writes accurate feature code; it just does not add protections you never asked for. The risk is the omission, not the tool — and it is closed by a verification step, not by avoiding AI.
What should I check first on an AI-generated backend?
Start with secrets in client code, committed config files, missing security headers and outdated TLS. Those four cover the large majority of findings on AI-built sites and are all detectable by an automated scan.

Keep reading