Your app works. Every feature does what you asked, so it feels finished. But working and safe are two different things, and your agent optimized for the first. This chapter closes the security holes an attacker would walk through.
7.8.1AI skips security by default
Your agent turns a request into code that runs. Ask for a login and you get a working login. You never told it to stop someone from skipping that login, so nothing guarantees it does.
Security is the requirement nobody writes down, invisible until the day someone finds it missing. So you name the holes yourself, and check for each one.
7.8.2The holes attackers look for
Most breaches come through a short list of mistakes, and the OWASP Top 10 is the industry's running catalog of them. Four cause most of the damage in apps built fast.
Injection is user input treated as a command: form text that rewrites your database query, or input that runs a command on your server. Cross-site scripting, or XSS, is the same trick aimed at the browser, user text rendered as live code in someone else's browser.
Hold your app against this list before anyone else can:
[ ] Injection: every query and command uses
parameters, never glued-in user input
[ ] Access control: every request checks who you
are AND whether you may touch THIS record
[ ] Auth: passwords hashed, sessions expire, no
admin route open without a login
[ ] Secrets: no keys in the code or the browser
bundle, all read from the environment
[ ] Output: user text escaped on display, never
inserted as raw HTML
[ ] Dependencies: nothing with a known
vulnerability, kept up to date
7.8.3Enforce real auth and least privilege
Two doors guard your app. Authentication proves who someone is, the login. Access control decides what that proven person may do, and skipping it lets anyone signed in read everyone's records by guessing an id.
Then hand every user, and every part of the system, the least privilege that still gets the job done. The database account that never needs to delete tables should not be able to.
Rule of thumb: default to no access, then grant each role the minimum it needs.
Your keys are already out of the code, moved into the environment earlier, and you already validate input at the boundary. The security angle on that same habit is to sanitize or escape everything a user sends before it is shown on a page, so their text can never run as code in another user's browser.
7.8.4Get a real review before launch
Your agent can run a security pass, and it should. But it sees the code in front of it, not every way in, and it carries the same blind spots that wrote the holes to begin with.
So if your app handles payments, health records, or anything that hurts real people when it leaks, pay a human to review it before launch. A few hours of a security engineer's time costs far less than one breach.
This prompt runs the first pass for you:
Act as a senior application security engineer
auditing my app before launch. Check it against
the OWASP Top 10 and report only real, reachable
risks, not theory.
For each hole that applies, give me three things:
where my code is exposed, the exact fix, and how
to confirm it is closed. Start with the ones that
get exploited first:
- Injection: every query and command uses
parameters, no user input glued in.
- Access control: every request checks identity
and permission on the exact record touched.
- Auth: hashed passwords, expiring sessions, no
open admin routes.
- Secrets: nothing sensitive in the code or the
browser bundle.
- Output: all user text escaped, never rendered
as raw HTML.
Flag anything touching payments or personal data
as needing a human review, not just your pass.
My app: what it handles and who can reach it:
Do this now: paste the prompt, run the audit against the OWASP Top 10, and close every hole it flags before you ship; if your app touches payments or personal data, book a human security review too.
