Code
Find security bugs
Audit your own code for the flaws that actually get exploited.
Fill it in
What to audit.
Which classes of flaw.
Your prompt
Audit [your repository or path] for: injection,authz,secrets This is DEFENSIVE work on code you own. Read it, find real flaws, and explain how to fix each one. Do not write an exploit, do not test against anything you were not handed, and do not touch a system that is not this codebase. For every finding, give the file and line, the concrete path from untrusted input to the dangerous operation, and the fix. A finding without that path is a guess, and a report full of guesses is worse than no report because it trains the reader to skim. Rank by exploitability, not by how alarming the category sounds. An injection behind an admin-only route matters less than a missing authorization check on a public one, and saying so is most of the value. Say explicitly what you did NOT cover, so nobody reads silence as a clean bill.
Use Find security bugsOpens with everything above already filled in.
Why this works
Two constraints do the work. It stays defensive, on code you own, with no exploit written and nothing probed that was not handed over. And every finding must carry the concrete path from untrusted input to the dangerous operation. That second rule separates an audit from a list. A model asked to find security bugs will produce plausible-sounding findings indefinitely; requiring the path forces each one to be traceable, and the ones that cannot be traced disappear before you read them.
Questions
- Will it try to exploit anything?
- No. It reads code and explains flaws. It does not write exploits and does not touch systems outside the codebase you point it at.
- Is this a replacement for a security review?
- No. It finds the classes of flaw visible in code, and it tells you what it did not cover so silence is never mistaken for a clean bill.