A good vulnerability report lets the recipient understand and reproduce the issue without a call. Include clear steps, evidence such as requests and responses, a proof of concept if you have one, the impact, and references. Use plain language and say politely if you plan to publish after a set period.
The checklist
The OWASP Vulnerability Disclosure Cheat Sheet advises including enough detail to allow the report to be understood and reproduced. Turn that into a short template:
- Summary in two sentences: what is wrong and where.
- Affected product, version, URL or endpoint.
- Steps to reproduce, numbered, with exact inputs.
- Evidence: HTTP requests and responses, HTML snippets or screenshots.
- Proof of concept code, if available.
- Impact: what an attacker gains, in your own words.
- References that help, such as related advisories.
- Your contact details and preferred way to communicate.
Keep it readable
OWASP says to write in plain language, since the reader may not have a security background. The first person to open your email may be a support agent. A clear summary gets it to the right team.
Redact personal data from screenshots and logs. OWASP also advises keeping enough evidence to counter any claim that the issue does not exist.
Recommendations are optional
You do not have to propose a fix. If you are unsure, OWASP suggests pointing developers to general guidance such as its cheat sheets. A wrong fix suggestion can distract more than help.
Say your publication plan up front
If you intend to publish after a set period, OWASP says to state that in the initial email, in a non-threatening tone. Surprises cause conflict. For typical timelines used in the industry, see disclosure deadlines compared.
What to expect after sending
OWASP describes back-and-forth: requests for more information, perhaps a retest. Retesting is not mandatory, but feedback on fixes is useful. If you hear nothing, follow up while staying professional. OWASP also says to be patient, because fixes inside enterprises often take significantly more time than researchers expect.
What not to do
- Do not ask for payment before revealing details unless the organization runs a bug bounty program.
- Do not access more data than needed to prove the issue.
- Do not threaten. OWASP's guidance for organizations says not to threaten legal action against researchers, and the same civility applies in both directions.
Finding the right inbox
Look for a security contact file or a disclosure policy on the site. See how to write and publish security.txt. If there is nothing, see reporting to a vendor with no contact.
If the bug is in a dependency of your own product, Safeguard's dependency scanning can confirm which of your projects include the affected version before you write the report.
Quick check
Do I need a working exploit to report?
No. Clear steps and evidence of the problem are enough. A proof of concept helps when you have one.
Should I include a deadline?
If you plan to publish after a period, state it calmly in the first message. OWASP recommends doing so.
Sources
Last reviewed: 19 October 2026.
