Someone Reported a Security Bug in Your App
Someone reported a security bug in your app. The email is from a stranger, there may be a screenshot, there may be a hint about a reward, and it may read like a threat.
Someone reported a security bug in your app. The email is from a stranger, there may be a screenshot, there may be a hint about a reward, and it may read like a threat.
The first hour matters more than the next week, and the thing that goes wrong most often is not the fix. It is the silence.
Someone reported a security bug in your app: reply in hour one
Send an acknowledgement within a few hours, even if you have no idea yet whether the report is real. Four lines is enough:
Thanks for the report, we have received it and are looking into it. We will come back to you with an assessment within three working days. If you have a proof of concept or additional detail, send it to this address. Please hold off on public disclosure until we have replied.
That message costs nothing and does three things: it starts a record, it gives you a stated timeline, and it makes the request for restraint before rather than after the researcher gets frustrated. The single most reliable way to turn a helpful researcher into a hostile one is to not answer them. Most public disclosures of unfixed bugs are the end of a thread where nobody replied.
Do not agree to anything, do not concede the bug is real, and do not mention money. You have not assessed it yet.
Hours two to twelve: triage
Reports arrive in three broad qualities and they need different amounts of your attention.
Signal in the report | What it usually means | Priority |
|---|---|---|
A reproduction: exact request, exact response, a specific account or record | someone actually did the work | drop what you are doing |
A named class with a concrete path, for example IDOR on /api/orders/{id} | plausible, may or may not reproduce | verify today |
A scanner screenshot with a severity badge and no request | an automated scan, often a false positive | verify when convenient |
A missing security header, no exploit shown | real but usually low impact | batch with other hardening |
A payment demand before any detail | not a disclosure | see below |
The test that cuts through all of it: can you reproduce the impact yourself, from the information provided, in under thirty minutes? If yes, it is real and its severity is whatever you just saw. If no, ask one specific question rather than dismissing it. Genuine researchers answer specific questions readily.
Reproduce in a non-production environment where you can. If you have to reproduce in production, use your own account and log everything you do, because you are about to perform actions that will look exactly like an attack in your own logs.
Hours twelve to seventy-two: fix, then look wider
Fix the reported instance. Smallest possible change, deployed fast.
Look for the same mistake everywhere else. This is the step teams skip and it is the one that matters. If an object id was not authorisation-checked on one endpoint, grep for the pattern across all of them. The class of bug is almost never a one-off, and a scaffolded codebase in particular repeats its patterns faithfully.
Check whether it was exploited. Search your logs for the pattern the researcher used, over as long a window as you retain. If you cannot answer this question at all, that is itself a finding: how to add an audit log to an AI-built app covers the minimum trail.
Decide on disclosure. If user data was accessed by anyone other than the researcher, you are in incident territory rather than bug territory, and the sequence changes: work the AI incident response plan instead.
Write the regression test. A security fix without a test is a security fix that comes back.
Reply with specifics. What you found, what you changed, when it deployed, and whether you found other instances. Researchers care about this far more than they care about swag.
What AI-built codebases get wrong most often
Four patterns account for most of what gets reported against apps assembled quickly:
Missing authorisation on an endpoint that has authentication. The user is logged in, so the route feels protected, but nothing checks that the record belongs to them. Generated CRUD does this constantly.
Secrets that reached the client bundle. An API key placed in a variable that looked server-side and was not. The boundary is explained in environment variables and secrets in an AI-built app.
Row-level security assumed rather than enabled. The policy exists in the design and not in the database.
File uploads that trust the extension. Content type is never verified and the file is served back from the same origin.
If a report lands on one of these, check the other three before you reply. They travel together.
When the email is a shakedown
Some messages are not disclosures. The tells are a demand for payment before any technical detail, a deadline measured in hours, a threat to publish or to report you to a regulator, and no reproduction of any kind.
Handle it flatly. Reply once, in writing, saying you will assess any technical detail they provide and that you do not pay for reports received under a deadline. Do not negotiate, do not pay, do not get drawn into a thread. Then check independently whether there is anything real, because occasionally there is, and the person is just handling it badly.
Keep every message. If it escalates, the record is what you will need.
Set this up before the next one
Three things, roughly an hour of work total, that make the next report far cheaper:
A security contact that works. An address on your site, or a security.txt file at your domain root. Reports that cannot find a destination end up on social media.
A one-paragraph disclosure policy. What is in scope, what you ask for, what you commit to in return. CISA's coordinated vulnerability disclosure guidance is a reasonable model to shorten from.
A pre-launch check that catches the obvious classes. Most of what gets reported would have surfaced in a structured pass before shipping: see how to test an AI-built app before launch.
Frequently asked questions
Someone reported a security bug in my app, what do I do first?
Reply the same day acknowledging receipt and giving a timeline, before you know whether the report is real. Then try to reproduce it. Silence is what turns a helpful report into a public one.
Do I have to pay someone who reports a bug?
No, unless you run a bounty programme with published terms. Many researchers report with no expectation of payment. Someone demanding money before showing you anything technical is doing something other than disclosure. On timing: acknowledge within a day, assess within three, and note that researchers commonly allow 90 days before publishing.
How do I know if a security report is real?
Try to reproduce the impact yourself from the detail provided. A report that reproduces is real regardless of how it was written. A report that cannot reproduce and whose author will not answer a specific question usually is not.
Should I tell my users?
If the vulnerability existed but you find no evidence anyone other than the researcher used it, most regimes do not require notification. If data was accessed, it becomes a breach and the requirements are specific to your jurisdiction. That is a different playbook.
The wider set of things that break after launch, security aside, is covered in what to do when your AI-built app breaks in production, and the build-side fundamentals are in how to build an app with AI.
How did this land?
About the author
Staff Engineer, Platform
Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.
