Common Security Gaps in AI-Built Websites

AI-built and vibe-coded websites tend to share a predictable set of security gaps: exposed secrets, client-side API keys, broken access control, injection, missing rate limiting and weak credential storage. These come from code that optimizes for a working demo rather than a threat model. This advisory explains each gap and gives a pre-launch checklist to verify your own site.

What we see in AI-built sites

AI coding assistants and vibe-coding platforms ship working features fast. They do not threat-model. When we assess sites built with tools like Cursor, Bolt, Lovable, Replit Agent or Claude Code, the same categories of weakness recur, because the generated scaffolding optimizes for a running demo rather than a hardened deployment. The gaps below are the ones our examiners find most often. This is a general advisory drawn from our audit practice, not a count of any single sample.

The recurring gaps

Exposed secrets and .env files
API keys, database credentials and tokens committed to the repository, left in client-side bundles or served from a publicly reachable .env. Once a key is public, rotation is the only fix.
Client-side API keys
Keys embedded in front-end JavaScript so the app can call a service directly. Anyone can read them in the browser and spend your quota or reach your data.
Broken or missing access control
Endpoints that never check whether the caller owns the record they request (insecure direct object reference). This is the flaw automated scanners miss most and attackers find first. See OWASP A01: Broken Access Control.
Injection
User input concatenated into SQL, shell commands or markup without parameterization or output encoding, which opens SQL injection and cross-site scripting. Reference: OWASP A03: Injection and MITRE CWE-89.
No rate limiting
Login, password-reset and API routes with no throttle, which invites credential stuffing, account enumeration and abuse of paid downstream services.
Missing security headers
Absent Content-Security-Policy, X-Frame-Options and HSTS, which leaves clickjacking and script-injection defenses off by default.
Weak credential storage
Passwords kept in plaintext or behind fast unsalted hashes rather than a slow adaptive function such as bcrypt, scrypt or Argon2.
Verbose errors and unrestricted uploads
Stack traces that leak file paths and query structure. Upload handlers that accept any file type or size without validation.

Why AI-built sites share these gaps

A generated code path that returns the right data in the demo looks finished. The missing ownership check, the absent rate limit and the hardcoded key are invisible until someone probes for them. Non-technical builders accept the output because it works. Developers using AI as an accelerator trust it more than they would trust a junior engineer's first draft, so review is lighter. The result is code that passes the happy path and fails the adversarial one.

What automated scanners cannot tell you

Off-the-shelf scanners are good at known signatures: reflected injection, missing headers, outdated libraries. They cannot reason about whether your authorization model is correct, whether a chain of individually minor findings adds up to full account takeover or whether business logic can be bypassed. Those require a person who reads the code and the request flow. A clean scanner report is not the same as a secure application. That gap is exactly where an examiner earns their fee.

Pre-launch checklist for an AI-built site

Before you put an AI-built site in front of real users, verify each item below. If you cannot confirm one, treat it as an open finding.

  • No secrets in the repository, the client bundle or a reachable .env. Rotate anything that was ever exposed.
  • Every data-returning endpoint checks that the authenticated user may access the requested record.
  • All database access uses parameterized queries. No string-built SQL.
  • User-supplied content is encoded on output. No raw untrusted HTML.
  • Login, signup, password-reset and sensitive APIs are rate-limited.
  • Passwords use bcrypt, scrypt or Argon2. No plaintext, no bare MD5 or SHA.
  • Content-Security-Policy, X-Frame-Options, HSTS and related headers are set.
  • Errors show a generic message to the user and log detail server-side only.
  • File uploads validate type, size and destination. Serve them from outside the web root where possible.
  • Dependencies are current and clear of known advisories.

The OWASP Application Security Verification Standard and the NIST Cybersecurity Framework are solid references if you want to go deeper than this list.

How we assess an AI-built site

Our review starts where scanners stop. We map the authentication and authorization model, test each endpoint for ownership enforcement, trace how secrets flow through the build and attempt the chained attacks that turn moderate findings into a breach. We verify every finding by hand to remove false positives, then deliver a report a non-technical founder can act on and a developer can fix. Engagements start at $1,500 CAD.