Free Guide · Security Checks For Builders Without A Security Team
How to Security-Check Your App With AI Before You Ship
You don't need a security team. You need a second, more suspicious pass.
If you built an app, a site, or an automation with an AI tool like Anthropic's Claude, OpenAI's ChatGPT, Microsoft's GitHub Copilot, or Anysphere's Cursor, there's a good chance no one with security training ever looked at the result. That's fine for a weekend project. It stops being fine the moment real people start putting real logins, real payments, or real personal information into it. The same kind of AI tool that helped you build the thing can also help you check it, if you point it at the right questions in the right order, and refuse to trust its first answer.
Ask an AI tool to review your code the way an attacker would, one risky area at a time: logins and accounts, payments, anything that reads another user's data, admin pages, secrets and keys, file uploads, and anything that sends a user's own text to an AI model. For each finding, ask where exactly it is (file and line) and how someone could actually exploit it, then run a second pass that tries to prove the finding wrong before you touch any code. Fix the real problems first, in order of how much damage they could do, and re-check the area you just changed.
Published
Free lesson · no account neededMeet ClaudeWhy Claude?6 minStart the free lessonKey Takeaways
- Review your app area by area, like an attacker would: logins, payments, anything reading another user's data, admin pages, secrets, uploads, and anything that sends user text to an AI model.
- Treat every finding as a claim to test, not a fact: a second pass that tries to disprove it catches the false alarms before you waste time fixing them.
- Fix problems in order of real damage, not in the order the AI listed them, and re-check the area you just changed before moving on.
- An AI reviewer reads your code, not your live settings: hosting rules, database permissions, and any key sitting in a dashboard are all invisible to it.
- Never paste a real password, API key, or other live secret into a chat while doing this, and get a human security reviewer for anything handling money or health data.
Copy and Paste
Prompts You Can Use Today
A full area-by-area pass
Review this codebase the way an attacker would, one area at a time: logins and account recovery, payments, anything that reads another user's data, admin or internal pages, secrets and API keys, file uploads, and anything that sends a user's own text to an AI model. For each area, list every real issue you find with the exact file and line, and explain in plain terms how someone could actually exploit it.
Start here on a whole project. Expect this to take a few passes on anything larger than a few files.
Logins and accounts
Focus only on how this app handles logging in, signing up, resetting a password, and staying logged in. Check whether one user could get into another user's account, whether a password reset link could be guessed or reused, and whether a session stays valid for longer than it should. Point to the exact file and line for each issue and describe the attack step by step.
Run this on its own even if you've already done a full pass; login flows hide the kind of logic bugs a general scan skips over.
Payments and anything involving money
Look only at the parts of this app that touch money: checkout, refunds, discount codes, and anything that changes a price or a balance. Check whether the price or amount a user pays is ever trusted from something the browser sent, rather than recalculated on the server, and whether any of these actions could be repeated or replayed to get an unintended result. List each issue with its exact location and the concrete way someone could abuse it.
If this app moves real money, treat anything found here as urgent and get a human reviewer before you ship, not just this AI's second pass.
Admin pages and other users' data
Check every page and every API endpoint that an admin or internal user can reach, plus anything that returns data belonging to a specific user. For each one, tell me what actually stops a logged-in regular user, or someone with no account at all, from reaching the same page or the same data by changing an ID or a URL. Flag anything that relies only on hiding a link rather than checking who's asking.
This area catches the single most common real-world bug: a page that's reachable by anyone who knows or guesses its address.
The disprove pass, run after the first review
Here is a list of security findings from an earlier review of this codebase: [paste the findings]. For each one, try to prove it is NOT actually exploitable: look for a check elsewhere in the code, a framework default, or a setting outside the code that would stop the attack you described. Mark each finding as still real, likely a false alarm, or uncertain, and explain your reasoning for each one.
This step is what separates a useful review from a list that scares you into fixing things that were never broken. Don't skip it.
Anything that sends a user's own text to an AI model
Find every place in this app where text a user typed, uploaded, or pasted gets sent to an AI model, including file uploads later read by that model. For each one, explain what would happen if that text contained hidden instructions aimed at the AI itself rather than at a person, and whether the app gives that AI call any ability to take an action, like sending an email or changing data, based on what it reads.
This is the one risk area that's genuinely new. A normal web security checklist from a few years ago won't mention it at all.
The Basics
What a security check with AI actually means
Strip away the specific tool, Anthropic's Claude, OpenAI's ChatGPT, Microsoft's GitHub Copilot, or Anysphere's Cursor, and a useful AI security check always follows the same shape.
It reads your code the way an attacker would
Instead of asking an AI tool whether your code looks fine, the useful question is narrower and meaner: how would someone break this on purpose? That single change in framing is most of what makes a review actually find something.
It works one risky area at a time, not as one giant scan
A vague request to "check my app for security problems" tends to come back vague. A request scoped to one area, like logins or payments, gives the AI a narrow enough target to actually reason about, and gives you a shorter, more specific list to act on.
Every finding is a claim worth testing, not a verdict
An AI tool can describe a plausible-sounding attack that doesn't actually work against your code, because a check elsewhere stops it. Treating the first list of findings as a starting point, not a conclusion, is what the rest of this guide is built around.
The fix matters more than the find
A long list of findings feels productive and isn't, on its own. The actual goal is a short list of real problems, fixed in the order they'd actually hurt you, with the area you changed checked again afterward.
Where To Look
The parts of your app worth checking first
Most apps have a small number of places where a real security problem would actually matter. Point an AI review at these before anywhere else.
Logins and accounts
Signing up, logging in, resetting a password, and staying logged in. A bug here can let one person into another person's account entirely, which is about as bad as a security bug gets.
Payments and anything involving money
Checkout, refunds, discount codes, subscriptions, or anything that changes a balance. These are worth extra caution because a bug here has a direct dollar cost, not just an inconvenience.
Anything that reads another user's data
A profile page, an order history, a downloaded file, or an API response. The question to ask is simple: what actually stops me from swapping in someone else's ID and seeing their data instead of mine?
Admin pages and internal tools
Anything meant only for you, a staff account, or an internal dashboard. These pages are frequently protected by nothing more than not being linked anywhere, which stops no one who guesses or finds the URL.
Secrets and API keys
Anything that lets your app talk to a database, a payment processor, or another service on your behalf. A key that ends up visible in code a browser can download is no longer a secret at all.
File uploads, and anything that sends a user's text to an AI model
An upload handler that trusts a file's name or type too much, and any feature where a user's own words, or an uploaded document's contents, get read by an AI model that can then take an action.
The Process
Seven steps that keep the review honest
Start by picking the handful of areas from the list above that your app actually has. A simple internal tool with no payments and no logins doesn't need a payments review; a public-facing app with accounts and a checkout needs both, plus everything in between. Trying to review all of it in one pass tends to produce a shallow list; reviewing one area at a time, with a prompt scoped to that area alone, tends to produce a shorter but far more useful one.
For each area, ask the AI to point at the exact file and line for anything it finds, and to explain in plain terms how someone would actually carry out the attack it's describing, step by step. A finding you can't picture happening is a finding you can't properly judge. If the explanation is vague, hand-wavy, or depends on something that isn't true about how your app actually works, that's a sign the finding needs more scrutiny, not less.
Before you change a single line of code, run a second pass whose only job is to try to disprove the first pass's findings. Paste the list back in and ask the AI to argue against each one: is there a check elsewhere in the code, a framework default, or a setting outside the code itself that would stop the attack it described? This step catches the confident-sounding false alarms that an AI review produces fairly often, and it's the single habit that most separates a useful review from a scary-looking list.
Once you have a shorter list of findings that survived the disprove pass, fix them in order of how much real damage each one could do, not in whatever order they happened to be listed. A bug that exposes every user's data outranks a cosmetic issue on an admin page nobody but you ever visits, even if the AI happened to describe the cosmetic one first.
After each fix, ask the AI to look at just the part of the code you changed, specifically for whether the fix introduced a new problem or left the original one only partly closed. A rushed fix is one of the more common ways a real app ends up with a second, slightly different version of the same bug a week later.
Why This Matters Right Now
AI is finding more bugs than people can review
This isn't a hypothetical concern about some future version of these tools. It's already visible in one of the most carefully reviewed pieces of software in common use. PostgreSQL, the open-source database that a large share of the internet's apps run on, is expected to ship its next major version, PostgreSQL 19, later than its usual window of mid-September to mid-October, likely slipping into November 2026 instead.
Robert Haas, a longtime PostgreSQL project committer, wrote about why in a blog post at the end of October 2026: AI tools are now finding bugs faster than the project's human reviewers can check the proposed fixes. Comparing the same stretch of the calendar, April 8 through September 25, in 2025 versus 2026, commits to the project's main development branch rose from 1,037 to 1,443, and the number of fixes that had to be back-ported into the prior stable release, because the bugs they addressed turned out to affect it too, rose from 248 to 433.
Haas's point wasn't that this is a disaster. It was narrower and more useful than that: AI can draft a fix, and increasingly can find the bug in the first place, faster than it used to take a person to do either. What it can't do on its own is decide that the fix is actually correct and actually safe. A human still has to read it and sign off. That's the same lesson this whole guide is built around, just playing out at a much larger scale than one person's side project.
Honest Limits
What an AI review can't see
An AI tool reviewing your code is genuinely useful, and it is not the whole picture. Keep these limits in mind before you treat a clean-looking result as a clean app.
It reads your code, not your live settings
A database's access rules, a cloud storage bucket's permissions, and an API key sitting in a hosting dashboard all live outside your codebase. An AI reading only your code has no way to see any of them, so a review of the code alone can miss a problem that lives entirely in how a service is configured.
It can sound confident and still be wrong
A described attack can be detailed, specific, and not actually work, because something elsewhere in the app already stops it. That's exactly why the disprove pass earlier in this guide exists: a false alarm written with total confidence is still a false alarm.
Money and health data deserve a human reviewer too
For an app that handles payments, medical information, or anything else with serious real-world consequences if it goes wrong, treat an AI review as a strong first pass, not a replacement for a person with security training looking at it before real users arrive.
An answer today can be stale next month
You add a feature, change a dependency, or move to a new hosting setup, and the risk picture shifts with it. Treat this as a check you repeat before each real release, not a one-time pass you can forget about once it's done.
Staying Safe While You Check
A few habits worth keeping
Never paste a real password, a live API key, or any other working secret into a chat window while you're doing this, even with a tool you trust. Use a placeholder like YOUR_API_KEY_HERE in the code you share, and describe what the real value would be rather than pasting it. A chat transcript is one more place a secret can leak from, and it's an easy one to avoid.
If part of what you're checking is a tool like Claude Code that runs commands directly on your machine with your own permissions, or an agent that clicks and types on your behalf, those come with their own separate safety habits beyond what this guide covers, worth reading on their own before you lean on either one for anything that matters.
Treat this whole process as a habit that happens before every real release, not a one-time audit you check off and move past. The areas worth checking, and the specific risks inside each one, will keep changing as your app grows new features, so the review that cleared last month's version doesn't automatically clear this month's.
Reviewing your own code is a skill, and it compounds
Knowing the checklist is step one. Nightschool AI's free curriculum teaches the underlying skill of working closely with an AI tool on real code, including the habit of questioning its first answer, so this gets easier every time you do it.
Frequently Asked Questions
What does it actually mean to "security-check" an app with AI?
It means asking an AI tool to review your code the way an attacker would, one risky area at a time, rather than asking a vague question like whether the app looks safe. You then test each finding before fixing it, and fix the real problems in order of how much damage they could do.
Which parts of my app should I check first?
Start with logins and accounts, anything involving payments, anything that reads another user's data, admin or internal pages, secrets and API keys, file uploads, and anything that sends a user's own text to an AI model. Not every app has all of these; check whichever ones your app actually has.
What should I actually ask the AI to look for?
Ask it to find real, exploitable problems in one area at a time, and for each one, to name the exact file and line and describe step by step how someone would actually carry out the attack. A finding with no concrete attack behind it is harder to judge and more likely to be a false alarm.
Why does a finding need a second look before I fix it?
AI reviews produce confident-sounding findings that sometimes don't hold up, because something elsewhere in the code already prevents the attack described. A second pass that tries to disprove each finding catches these false alarms before you spend time fixing something that was never actually broken.
What can an AI miss when it reviews my code this way?
It only sees your code, not your live settings: a database's access rules, a cloud storage bucket's permissions, or an API key sitting in a hosting dashboard are all invisible to it. It can also describe a plausible attack that doesn't actually work, which is why the disprove pass matters.
Is it safe to paste my code into Claude, ChatGPT, Copilot, or Cursor for this?
Sharing ordinary application code with these tools is the normal way this kind of review works. What you should never paste in is a real, working secret: a live password, API key, or access token. Use a placeholder in its place and describe what the real value would be instead.
Do I still need a human security reviewer if I do all of this?
For a low-stakes personal project, a careful AI-assisted review along these lines is often enough. For anything handling payments, medical information, or other data where a mistake has serious real-world consequences, treat this guide as a strong first pass and still get a person with security training to look at it before real users arrive.
Why is AI-assisted bug-finding suddenly a bigger deal right now?
PostgreSQL, widely used database software, is shipping its next major version later than usual, likely slipping into November 2026. A project committer, Robert Haas, wrote in late October 2026 that AI tools are now finding bugs and drafting fixes faster than human reviewers can check them, which is exactly the review bottleneck this guide is built to help you manage for your own project.
Does this replace keeping an AI agent out of my sensitive accounts?
No, that's a different kind of risk. Reviewing your code for security problems is about the app itself; letting an AI agent click and type on your behalf, if you also do that, needs its own separate precautions around which accounts it can reach and what it's allowed to do without asking first.
Is Nightschool AI affiliated with Anthropic, OpenAI, Microsoft, or Anysphere?
No. Nightschool AI is independent and is not affiliated with or endorsed by Anthropic, OpenAI, Microsoft, or Anysphere. Claude, ChatGPT, GitHub Copilot, and Cursor are products of their respective companies, named here only to describe what they are and how they're commonly used.
A careful second look, every time you ship
The checklist matters less than the habit of not trusting the first answer.