How to respond to a website security report as a small business
An email arrives saying your website has a security problem. Some of these are careful, useful reports; many are automated scans sent in the hope of a fee. Either way, the response is the same sequence: acknowledge, reproduce, check the facts against what your site actually serves, fix or restore what's yours, pass on what belongs to the platform, and reply. Don't pay and don't panic before you've checked.
First, sort the report
Read it twice and decide which of these it is. The category tells you who acts and how fast.
| What the report says | Usually | Who acts |
|---|---|---|
| Your page shows something it shouldn't: a key, a private phone number, a staff email | Real and yours | You, today |
| The site loads content you didn't add | Possibly tampering | You, now: see the hacked-site steps |
| A header is missing, or a generic scanner grade | Often automated, sometimes valid | You check, then decide |
| Something in the builder, the login or another customer's site | A platform issue | Anticode |
| "Pay us and we'll tell you the problem" | A fee request, not a report | Nobody pays; ask for details |
The response, step by step
- Acknowledge within a day or two. A short, polite reply: thank them, say you're looking into it, and ask for the exact address, what they did, and what they saw. Don't argue, promise money or admit anything you haven't checked.
- Reproduce it yourself. Open the page they name, on your own device, and look for exactly what they describe. If you can't reproduce it, say so and ask for more detail.
- Check your site's public security report. Every Anticode site serves one at
/.well-known/anticode-security, worked out from the published pages each time it's requested. It shows the checks each page passes, the exact Content-Security-Policy, what the pages load and from where, how forms are wired, the security baseline, and the result of the last integrity scan. Many scanner claims ("you allow inline scripts", "your form posts off-site") can be answered from it directly. - Look at the page you're publishing now. In the builder, run the release checklist, which runs every publish check (including Sentinel's security checks and the design gate) without publishing. If something you added recently fails, that's your answer.
- Fix it, or restore. If the problem is content, such as a phone number or a key pasted into a paragraph, remove it and republish; anything that looks like a secret should also be revoked or rotated wherever it came from. If a recent change caused it and you'd rather undo it, preview an earlier version in history, restore it and publish.
- Send platform issues to Anticode. If the report concerns the builder, sign-in, the dashboard or how sites are served, it isn't yours to fix. Forward it through the contact page with the reporter's details and their permission, and tell them you've done so.
- Reply with the outcome. Say what you found and what you changed, or why no change was needed, in plain words. Thank them by name if they'd like credit.
- Write it down. Date, report, what you checked, what you did. Next time it's quicker.
Requests for payment
Small businesses regularly get emails listing generic findings and asking for a "bounty". Unless you've published a programme offering rewards, you don't owe one. Reply once, asking for the specific page and steps to reproduce. A genuine reporter will usually send them; a fee-hunter usually won't. If the details turn out to be real, fix them; whether you then say thank you with a gift is your choice, not an obligation.
What Anticode already rules out
Some common report types can't apply to a design-engine page, and the public report lets anyone confirm that. Those pages ship no scripts at all and are served with script-src 'none', so cross-site scripting through the page has nothing to run. At publish, the server re-runs the checks that matter once a page is public (scripts, inline handlers, javascript: links, form targets, HTTPS), so a page failing them can't go live. Published files are hashed at publish and rechecked by a scan that reaches each site about once a day; a changed file is restored from a clean backup of the last ten published versions. A site that collects data can't be published until the account owner and the person publishing have two-factor sign-in on.
None of that covers what you type into the page. Most real reports about small sites are about content: a personal mobile number, an old staff member's email, a document link that should have been private.
How you know it's closed
- You reproduced the issue, or confirmed in writing that it doesn't apply.
- The live page and its public security report both show the fix.
- Any secret that was exposed has been revoked at its source, not just removed from the page.
- The reporter has had a reply, and platform issues have gone to Anticode.
Limits
Anticode gives you the public security report, the publish checks, version history and automatic backups. It doesn't answer reporters for you, run a bug-bounty programme on your behalf, or review content you wrote for private details. If you think the site has actually been changed by someone else, follow what to do if your website is hacked. For a routine self-check, see checking a website for security issues and the security report feature.
Questions people ask
Do I have to pay someone who reports a bug on my website?
No, unless you published a reward programme. Ask for the details, fix what's real, and thank them.
Where can I see what my Anticode site actually serves?
At /.well-known/anticode-security on the site's own address. It's public and computed from the live pages each time.
What if the problem is in Anticode itself?
Pass it to Anticode through the contact page with the reporter's details, and let the reporter know you've done that.