Not every security issue in AI-generated code is a subtle logic flaw. Many are the opposite: a setting, plainly visible, that turns a protection off. The pattern is always the same. The assistant hits an error, the quickest way to clear it is to disable whatever is throwing it, and the disabled setting ships as configuration. It works perfectly in development, so nothing signals a problem, and it only becomes an exposure once the app is live against a real network and real users. Here are the five that come up most, and how to recognize each in a diff.
1. TLS verification turned off
A database or API connection throws a certificate error, usually against a self-signed or local cert, and the fast fix is to stop checking certificates at all. The connection still looks encrypted, which is what makes it easy to miss, but with verification off anyone positioned between your app and the server can read or alter the traffic.
The shape to look for: a verification flag set to false, for example rejectUnauthorized: false. The fix is to supply the CA certificate instead of disabling the check. Details: disabled TLS verification and why HTTPS matters.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →2. A CORS wildcard with credentials
A cross-origin request gets blocked, and the fastest way to make it succeed is to allow every origin. Pair that with credentials and any website can make authenticated calls to your API as your logged-in user.
The shape to look for: an origin of "*", especially alongside credentials: true. The fix is to list your own domains instead of a wildcard. Details: a CORS wildcard origin and the CORS wildcard risk.
3. Session cookies missing their flags
A cookie set without httpOnly, secure, and sameSite works fine on localhost, which is exactly why the flags get left off. In production it means the session cookie can be read by scripts, sent over plain HTTP, and attached to cross-site requests.
The shape to look for: a cookie set with only a name and value, no flags. The fix is one line adding all three. Details: insecure session cookie flags.
4. Debug mode left on in production
Debug and verbose error modes are on during development because they are useful, and nothing forces them off before deploy. In production they turn every error into a detailed report of your internals: stack traces, file paths, sometimes configuration, handed straight to whoever triggered the error.
The shape to look for: a debug flag hardcoded to true, or a verbose error handler with no environment gate. The fix is to gate it on the environment and return a generic message in production. Details: debug mode in production and leaked stack traces.
5. Plain HTTP where HTTPS belongs
An internal call or an API base gets hardcoded as http:// because it works in local development, and that plain-text hop ships. Over HTTP, anything in that request, including tokens and data, travels in the clear.
The shape to look for: a hardcoded http:// URL for anything that carries data, or a service configured without forcing HTTPS. The fix is to use HTTPS everywhere and redirect HTTP to it. Details: HTTP instead of HTTPS.
The common thread
Every one of these reads as a small configuration choice, not a bug, which is why they slip through. In review, stop looking only for broken logic and add one more question to the pass: does this diff disable, widen, or skip a protection to make something work? That single question catches the whole class. It is step four of a five-part review pass worth building into your habit.
Frequently asked questions
Why does an AI tool disable security settings at all?
Because disabling the thing throwing an error is the shortest path to code that runs, and running code is what the assistant optimizes for. When it hits a certificate error, a blocked cross-origin request, or a cookie that breaks local testing, turning the check off makes the current step succeed. It has no way to weigh that against a production risk it cannot see, so it ships the setting that unblocks the moment.
These work fine in development. How do they actually cause harm?
That is exactly why they survive. Each one is invisible in development, where you are on localhost with clean data and no attacker. The harm shows up only in production against a real network and real users: a disabled certificate check lets someone intercept traffic, a CORS wildcard lets another site call your API as your user, a debug flag leaks your internals. The setting that was harmless locally becomes the exposure once it is live.
How do I catch these in review?
Look specifically for a protection being turned off, widened, or skipped. A verification set to false, a wildcard where a specific value belongs, a missing cookie flag, a debug or verbose mode left on. They are easy to spot once you are looking for the shape, because they are small and they read as configuration rather than logic. A scan will also flag them by pattern, which covers the ones a review misses.
Find the ones already shipped
Prevention helps the next diff. For the settings already live in code you shipped, a scan reads the repo and flags each of these by pattern, with the file and line, so you are not relying on remembering to look. We have scanned nearly 2,000 AI-built apps and insecure defaults are a steady part of what we find. Run a free scan and see which are in yours.