How to Handle Security Bug Reports and Beg Bounty Emails

Most "I found a vulnerability in your website, what is the bounty?" emails are beg bounties: copied scanner output about low-risk settings, sent to many small sites in the hope that someone pays. A few are real reports that deserve a fast, grateful reply. You can tell them apart in about 15 minutes: don't click anything, look for exact steps and a specific URL, reproduce the issue on your own test account, and ask whether someone could read or change other people's data, take over accounts, run code or spend your money. Reply politely, fix by severity, and never pay because someone threatens you. Then publish a security contact, a short disclosure policy and a security.txt file, so real reports reach you and the noise has rules to point at.

This guide is for solo and small-team SaaS founders with no security team and no bug bounty program. The product, founder and emails in it are made up. The standards, policies and laws mentioned are real and linked, but nothing here is legal advice.

What is a beg bounty, and how is it different from a real report?

"Beg bounty" is the name security people use for unsolicited reports that exist mainly to get paid. Troy Hunt, who runs Have I Been Pwned, describes it as someone begging for a bounty from a site that never offered one, and credits Chester Wisniewski and Michael Argast for coining the phrase. Sophos laid out the usual pattern in its warning about bogus bug reports: find a contact address, paste scary text from a scanning tool, then ask for payment for the "find", a contract to "fix" it, or both.

The findings are usually visible to anyone with a free checker. Hunt cites DMARC records and a missing Content Security Policy, found with point-and-shoot tools like SSL Labs and Security Headers.

The findings you will see most often

• Email records. "Your domain has no DMARC record." Worth fixing for spoofing and deliverability, but not a hole in your app.

• Clickjacking. A marketing page lacks an X-Frame-Options or frame-ancestors header. It matters where a click changes something important, rarely on a static homepage.

• Missing security headers or version disclosure. A letter grade, or your server naming its software version. Good hygiene, low impact alone.

• Self-XSS. Script that only runs if users paste it into their own browser. Nobody can trigger it for someone else.

• No rate limit on login or password reset. Sometimes real. Check whether your auth provider or firewall already limits attempts.

• "Your .git folder is exposed." Often real and serious, because your repository history may contain secrets. Check it the same day.

The last two are why you can't bin everything with "bounty" in it. The tone of an email tells you how much to trust the sender, not whether the bug exists.

Signals that separate noise from a real report

What should you do in the first 15 minutes?

The goal is to decide how worried to be without making things worse.

1. Don't open attachments or odd links. A fake bug report makes a good phishing lure because it makes you anxious and curious at once. Read the email body only.

2. Don't reply yet. A panicked "please don't publish this!" tells the sender you are an easy target.

3. Write the claim in one sentence: what, where, and what an attacker gets.

4. Reproduce it safely. Use your own test accounts. If the claim is "user A can see user B's data," create two accounts and try it. Never pull a real customer's data to prove a point.

5. Rate it with the four questions below.

6. Log it in a sheet: date, sender, your one-line claim, reproduced or not, severity, status, reply sent and credit. Log it even if it is nothing; the same finding will come back.

How bad is it? Four plain questions

You don't need a scoring system yet. With this bug, could someone outside your company:

• read other users' data, or your own private data and keys;

• change or delete other users' data, or take over their accounts;

• run their own code on your servers;

• spend your money, for example by abusing an API key, sending email from your account or running up a cloud bill.

Any yes means urgent: start today. Four noes, plus a victim who would have to do something odd, means low priority. Most beg bounty findings land there.

How should you reply to each kind of email?

Short, calm and factual works for all three. These replies are illustrative.

Keep these as saved drafts, so you write them once in a calm moment instead of fresh every time your stomach drops.

Do you have to pay someone who reports a bug?

No. If you never published a bounty program, nobody is owed money for an unsolicited report.

Be careful even with small gestures. Wisniewski wrote up what happened to the open-source project TYPO3 in a Sophos piece on rewarding beg bounty hunters. The team sent branded swag to someone who reported a server version string. The recipient had more than 13,000 Twitter followers and posted about it, and reports of little or no value went up 5x to 10x. His advice: "I recommend only paying or rewarding security reports submitted through officially sanctioned programs."

A sensible default:

• no money for scanner findings;

• public thanks for anyone who reports a real issue responsibly;

• optionally, a small fixed thank-you for issues that hit the four questions above, decided after the fix and stated in your policy so it is never a negotiation.

What if the sender threatens to go public?

Don't pay and don't bargain. A threat to "leak" or publish unless you pay is extortion. In the TYPO3 story, a reporter who didn't get a bounty threatened to leak the company's information across social networks, then went back to begging when that didn't work.

• Keep the full emails, with headers. Don't delete anything.

• Send one line saying you don't pay under pressure, then stop.

• Check the claim anyway. If a real bug sits behind the threat, fixing it protects your users and removes the threat's power.

• If the threat is specific or you think data was taken, report it to your local police or national cybercrime reporting service and get proper advice.

How do you make it easy for real researchers to reach you?

Troy Hunt's post opens with the opposite problem: people who found real breaches and couldn't get the company to answer. You want that person to reach you in minutes. Three small things do it.

A security contact address

Create a security@ address on your domain that forwards to everyone who can fix things. It is a long-standing convention that RFC 9116 itself points to. Add a filter so these emails never land in a low-priority tab.

A short vulnerability disclosure policy

A vulnerability disclosure policy, or VDP, is one page that says what researchers may test, how to report, and what you promise in return. Don't start from a blank page. The US agency CISA publishes a free VDP template written for government agencies, and its plain-English sections adapt well to a small company. disclose.io offers a policy generator, ready-made safe harbor language and security.txt help, and says plainly that none of it is legal advice.

For a small SaaS, keep it to these parts:

• Scope. Which domains and apps are covered. Leave out services you don't run, like your payment provider, and point people to those vendors' own policies.

• Rules. Test only on accounts you own, stop and report as soon as you see other people's data, and no denial of service, social engineering or physical testing. The CISA template has wording for all of it.

• Safe harbor in plain words. If someone follows the policy in good faith, you won't pursue legal action against them.

• How to report. The security@ address, plus what you need: URL, steps to reproduce, impact.

• A response time you can keep alone. The CISA template acknowledges reports within 3 business days.

• Rewards. Say you don't run a paid bounty, and what you do offer, such as public thanks.

The rewards line turns "what is your bounty?" into a link you paste.

A security.txt file

security.txt is a small text file that tells researchers where to report, defined in RFC 9116, and securitytxt.org has a form that builds one for you. The rules worth knowing:

• Serve it at /.well-known/security.txt over HTTPS, as plain text.

• Contact is required. Use mailto: for email or a full https:// link.

• Expires is required, exactly once. The RFC recommends a date less than a year ahead.

• Policy and Acknowledgments are optional links to your policy and thanks page.

A minimal file for a small product looks like this:

• Contact: mailto:security@example.com

• Expires: 2027-10-01T00:00:00.000Z

• Policy: https://example.com/security/disclosure

• Acknowledgments: https://example.com/security/thanks

Two caveats from the RFC itself: publishing the file can bring more automated, low-quality reports, and the file doesn't give anyone permission to test your site; your policy decides that. If you also need a customer-facing security page for buyers, the MakerHunt guide to writing a security page that unblocks your first B2B deals covers that side, and your disclosure policy can live as a short section linked from it.

How do you fix the bug and close the loop?

Fix in order of the four questions, not of how loud the email was. Once a real fix is live:

1. Check whether it was used. Search your access logs for the endpoint or pattern in the report, as far back as they go, and note the result, including "no signs of use."

2. Rotate anything exposed. If keys, tokens or passwords could have leaked, for example through an exposed .git folder, change them now. If the report touches your admin, cloud or payment accounts, also check the 2FA and recovery setup from the IndieHunt guide to protecting your indie SaaS from account lockouts.

3. Tell the reporter. Say it's fixed, invite a retest, and confirm how they want to be credited.

4. Thank them publicly. A thanks page with date, name and a vague one-line description costs nothing, and RFC 9116 has an Acknowledgments field for it.

When do you have to tell users or a regulator?

Not legal advice; rules differ by country. Under the GDPR these duties apply to a personal data breach, where personal data was actually exposed, lost or changed, not just to a bug existing. If that happened and it is likely to put people at risk, the European Data Protection Board's guide for small businesses says you must notify the relevant data protection authority within 72 hours of becoming aware of it where feasible, tell affected people without undue delay if the risk is high, and record every breach even when you decide not to notify. The UK regulator's 72-hour guide for small organisations adds that the clock starts when you discover the breach, not when it happened. If your logs show someone reached other people's data, get advice that day.

When is a real bug bounty program worth it?

A VDP is not a bounty. A VDP says "here is how to report, and we won't come after you." A bounty adds "and we pay for valid findings," which brings more researchers, more reports and more triage.

Platforms such as HackerOne, Bugcrowd, Intigriti and YesWeHack run bug bounty programs, and some also offer managed VDPs with triage, so someone else filters the noise first. Ask them for pricing directly. Consider it when most of these are true:

• bigger customers ask about it in security reviews;

• valid reports arrive regularly, not only scanner noise;

• you have budget for rewards and time to fix what comes in.

Until then, a VDP and fast, polite replies cover most of what a small product needs.

A made-up week: three security emails at Mossdial

Mossdial is a made-up appointment reminder app for small physiotherapy clinics, run by a made-up founder, Marisol, from Valencia. One week, three emails arrive.

Monday: "Critical vulnerability, what is your bounty?" No steps, a header-scanner screenshot, and details promised "after we discuss reward." The headers are missing on the marketing site, which has no login. Marisol logs it as low, adds the headers anyway, and sends the scanner-finding reply with her policy link. Two days later the same text arrives from a new address. She marks it as a duplicate and doesn't reply.

Wednesday: a real one. A researcher writes that changing the appointment ID in a reminder settings URL shows another clinic's reminder text, including patient first names. Marisol reproduces it in 10 minutes with two test clinics: a yes to the first question, so urgent. She ships an ownership check that evening, finds only the researcher's test requests in her logs, writes down that decision and her reasoning, and replies with thanks and a credit on her new thanks page.

Friday: a threat. A new sender claims to have "patient data" and will post it unless she pays. No sample, no steps. She keeps the email, sends the one-line no-payment reply, checks the logs again, finds nothing new, and stops replying. Most of her week's security time went on the real bug.

A 7-day setup plan

The days are a planning guess. If you only do two, do the security@ address and the reply drafts.

Security report FAQ

Do I have to pay someone who reports a bug?

No, unless you published a program that promises payment. You can choose to reward a genuinely useful report, but never pay under threat.

Is a missing DMARC record a vulnerability?

Not in your app. It makes spoofed email from your domain easier and can hurt deliverability, so set it up; this walkthrough on checking SPF, DKIM and DMARC before a launch email covers the steps. It is not a bounty-level finding.

Should I add security.txt if I am a solo founder?

Yes, if you will read the inbox it points to. It takes minutes. The RFC says a stale file can be worse than none, so set a renewal reminder before the Expires date.

What if the reporter threatens to go public?

Keep the evidence, send one no-payment line, fix the claim if it is real, and report a specific threat to the police. A reporter who just wants a fix timeline before publishing is doing normal disclosure, not threatening you; agree a date you can meet.

And when the product is in good shape, IndieHunt is a good place to launch it to other indie makers.