Finding Security Gaps

Models learn from public code, and most public code prioritizes clarity over safety. The statistical average of that corpus is an app with weak auth and trusting input handling.

So the baseline of generated software is demonstration-grade security. It works, it ships, and it leaks.

Finding the gaps is a deliberate adversarial pass, not something the happy-path demo will ever reveal.

The most common AI-introduced flaw is injection: SQL built by string concatenation, shell commands assembled from user input, templates that interpolate untrusted data.

The generated query looks normal until an attacker sends an apostrophe. Then the query becomes their query.

Hunt for any place where user input is glued into a command, query, or markup string.

Authentication asks who you are; authorization asks what you may do. Models routinely add login then forget to check ownership on each resource.

The result is the classic IDOR: change the id in the URL and read someone else's data. The endpoint authenticated you, but never verified the record was yours.

Check every data access for an ownership or role check, not just a logged-in check.

Ask for a working integration and the model will happily paste an API key inline to make the demo run. That key then lives in your git history forever.

Secrets belong in environment variables or a vault, never in committed code, client bundles, or logs.

Sweep for anything that looks like a key, token, or password hardcoded in the tree.

Generated frontends often enforce rules only in the browser: price calculated client-side, role checked in JavaScript, validation done in the form.

An attacker bypasses all of it by calling your API directly. Anything the client computes, the server must recompute and re-verify.

Treat every request as if it came from a hostile script, because it can.

Models validate the field you mentioned and ignore the rest. Length limits, type checks, allowlists, and format rules get skipped unless requested.

Unbounded input invites denial of service, oversized uploads, and malformed data corrupting downstream systems.

Validate at the trust boundary with explicit allowlists, not blocklists that attackers route around.

Helpful for debugging, dangerous in production: stack traces, SQL errors, and internal paths returned to the caller hand attackers a map of your system.

Models default to verbose errors because they make the demo easier to fix. Production needs generic messages to users and full detail only in private logs.

Separate what the user sees from what you record.

Login endpoints, password resets, and expensive queries without rate limiting are open to brute force and abuse. The model rarely adds throttling unasked.

An unlimited login endpoint is a credential-stuffing target. An unlimited search can be a denial-of-service lever.

Identify sensitive and costly endpoints and cap how often they can be called.

AI may pull in an outdated, abandoned, or even hallucinated package. Typosquatted dependency names are a real supply-chain attack vector.

Every import the model suggests is a trust decision. Verify the package exists, is maintained, and has no known critical vulnerabilities.

Run an audit tool and read what it flags rather than auto-upgrading blindly.

The most powerful prompt reframes the model from builder to adversary. Ask it to attack the code it just wrote.

A threat-modeling pass enumerates how each feature could be abused: what an attacker wants, what they control, and which assumption breaks first.

Adversarial review finds the gaps that constructive review walks right past.

No single control is enough. Validate input and use parameterized queries and check authorization and limit rates. If one layer fails, the next still holds.

Models tend to add one fix and declare victory. Real hardening layers controls so a single mistake is not catastrophic.

Security is a property of the whole system, reviewed as a whole.

Test your security review instincts.

AI defaults to insecure code: injection, broken authorization, secrets in source, client-side trust, weak validation, leaky errors, no rate limits, and risky dependencies.

Hunt them with an adversarial pass, threat-model each feature, and layer controls for defense in depth. Next, you will harden the reviewed app for production.