root@sparrow:~/writeups$ cat bug-bounty-report-template.md
// bug-bounty
The Report Template I Actually Use
23 Jul 2026
· 5 min read
Two versions of the same template: a quick one for straightforward findings, and a full one for anything that needs a stronger case built around it. I pick one depending on how much convincing the finding needs.
Quick template
Good enough for most reports — clean, fast to fill in, and it forces you to state the impact in plain words instead of just describing the bug.
# Vulnerability title
Example: Open Redirect via whitelist bypass using @ in the URL
## Summary
Short description of the issue.
## Affected asset
- Domain: https://example.com
- Endpoint: /redirect
## Steps to reproduce
1. Go to: https://example.com/redirect?url=https://trusted.com
2. Modify the parameter: https://example.com/redirect?url=https://trusted.com@attacker.com
3. Observe the redirect.
## Actual result
The user is redirected to attacker.com.
## Expected result
The application should block redirects to external domains.
## Impact
Always explain real-world impact — e.g. this can be used for phishing, since the
initial link belongs to a legitimate domain.
## Payload used
https://trusted.com@attacker.comFull template
For anything non-obvious: business logic, chained bugs, or a program that's known to be picky about severity. The root-cause and severity-estimation sections do a lot of the persuasion work here.
# [VULNERABILITY TYPE] – [CLEAR, SPECIFIC DESCRIPTION]
Example: Stored XSS in the "title" field allows code execution in an authenticated session
## 1. Summary
There is a [TYPE] vulnerability in [ENDPOINT / FUNCTION] that allows an attacker to
[MAIN IMPACT], caused by [ROOT CAUSE], which leads to [CONSEQUENCE].
## 2. Affected asset
- Domain: https://example.com
- Endpoint: /path/endpoint
- Feature: (e.g. project creation, login, chat...)
- Vulnerable parameter: (if applicable)
## 3. Root cause
- [ ] Missing input validation
- [ ] Incorrect validation (e.g. contains / startsWith instead of exact match)
- [ ] Missing sanitization
- [ ] Unsafe function usage (innerHTML, eval, etc.)
- [ ] Data exposed on the frontend
- [ ] Insecure backend logic
Technical explanation: describe exactly what's wrong, as if explaining it to a developer.
## 4. Technical details
Describe how the vulnerability works: request flow, how the input is processed, where
validation fails.
## 5. Attack scenario
1. [action 1]
2. [action 2]
3. [action 3]
Final result: [what the attacker achieves]
## 6. Steps to reproduce
1. Log in with a valid account (if applicable)
2. Go to: https://example.com/xxxx
3. Enter the following payload: [PAYLOAD]
4. Save / submit / execute
5. Observe the result
Steps must be CLEAR and REPEATABLE.
## 7. Proof of concept
Request:
GET /endpoint?param=payload HTTP/1.1
Host: example.com
Payload: [PUT PAYLOAD HERE]
Response:
HTTP/1.1 302 Found
Location: https://attacker.com
## 8. Impact
- [ ] Code execution in the user's session
- [ ] Redirect to malicious domains
- [ ] Access to sensitive data
- [ ] Identity impersonation
- [ ] Abuse of internal functionality
Explain clearly, as if the triager knew nothing about the bug.
## 9. Severity estimation
- Likelihood: [Low / Medium / High]
- Impact: [Low / Medium / High]
- Estimated severity: [Low / Medium / High / Critical]
## 10. Evidence
- Browser screenshot
- Request screenshot
- Response screenshot
- Logs (if applicable)
Everything must clearly demonstrate the bug.
## 11. Suggested fix
- Validate inputs correctly
- Sanitize data before rendering it
- Use safe functions (textContent instead of innerHTML)
- Never trust client-side data
- Implement security policies (CSP, backend validation)
## 12. Additional notes
- Reproducible without privileges (if applicable)
- Doesn't require authentication (if applicable)
- Affects multiple endpoints (if applicable)
- Can be chained with other vulnerabilities
## 13. Validation checklist (before submitting)
- [ ] The bug actually works
- [ ] The steps are clear
- [ ] The impact is well explained
- [ ] Nothing is missing
- [ ] It's not a false positive
- [ ] It's in scope
- [ ] It's not expected behaviorThe one thing both versions force you to do: explain impact in terms a triager who's never seen the app can understand, not just "it executes alert(1)".
Dos versiones de la misma plantilla: una rápida para hallazgos directos, y una completa para todo lo que necesite un caso mejor argumentado. Elijo una u otra según cuánto haya que convencer con el hallazgo.
Plantilla rápida
Suficiente para la mayoría de reportes — limpia, rápida de rellenar, y obliga a explicar el impacto con palabras claras en vez de solo describir el bug.
# Vulnerability title
Example: Open Redirect via whitelist bypass using @ in the URL
## Summary
Short description of the issue.
## Affected asset
- Domain: https://example.com
- Endpoint: /redirect
## Steps to reproduce
1. Go to: https://example.com/redirect?url=https://trusted.com
2. Modify the parameter: https://example.com/redirect?url=https://trusted.com@attacker.com
3. Observe the redirect.
## Actual result
The user is redirected to attacker.com.
## Expected result
The application should block redirects to external domains.
## Impact
Always explain real-world impact — e.g. this can be used for phishing, since the
initial link belongs to a legitimate domain.
## Payload used
https://trusted.com@attacker.comPlantilla completa
Para todo lo que no sea obvio: lógica de negocio, bugs encadenados, o un programa que se sabe quisquilloso con la severidad. Las secciones de causa raíz y estimación de severidad hacen buena parte del trabajo de convencer.
# [VULNERABILITY TYPE] – [CLEAR, SPECIFIC DESCRIPTION]
Example: Stored XSS in the "title" field allows code execution in an authenticated session
## 1. Summary
There is a [TYPE] vulnerability in [ENDPOINT / FUNCTION] that allows an attacker to
[MAIN IMPACT], caused by [ROOT CAUSE], which leads to [CONSEQUENCE].
## 2. Affected asset
- Domain: https://example.com
- Endpoint: /path/endpoint
- Feature: (e.g. project creation, login, chat...)
- Vulnerable parameter: (if applicable)
## 3. Root cause
- [ ] Missing input validation
- [ ] Incorrect validation (e.g. contains / startsWith instead of exact match)
- [ ] Missing sanitization
- [ ] Unsafe function usage (innerHTML, eval, etc.)
- [ ] Data exposed on the frontend
- [ ] Insecure backend logic
Technical explanation: describe exactly what's wrong, as if explaining it to a developer.
## 4. Technical details
Describe how the vulnerability works: request flow, how the input is processed, where
validation fails.
## 5. Attack scenario
1. [action 1]
2. [action 2]
3. [action 3]
Final result: [what the attacker achieves]
## 6. Steps to reproduce
1. Log in with a valid account (if applicable)
2. Go to: https://example.com/xxxx
3. Enter the following payload: [PAYLOAD]
4. Save / submit / execute
5. Observe the result
Steps must be CLEAR and REPEATABLE.
## 7. Proof of concept
Request:
GET /endpoint?param=payload HTTP/1.1
Host: example.com
Payload: [PUT PAYLOAD HERE]
Response:
HTTP/1.1 302 Found
Location: https://attacker.com
## 8. Impact
- [ ] Code execution in the user's session
- [ ] Redirect to malicious domains
- [ ] Access to sensitive data
- [ ] Identity impersonation
- [ ] Abuse of internal functionality
Explain clearly, as if the triager knew nothing about the bug.
## 9. Severity estimation
- Likelihood: [Low / Medium / High]
- Impact: [Low / Medium / High]
- Estimated severity: [Low / Medium / High / Critical]
## 10. Evidence
- Browser screenshot
- Request screenshot
- Response screenshot
- Logs (if applicable)
Everything must clearly demonstrate the bug.
## 11. Suggested fix
- Validate inputs correctly
- Sanitize data before rendering it
- Use safe functions (textContent instead of innerHTML)
- Never trust client-side data
- Implement security policies (CSP, backend validation)
## 12. Additional notes
- Reproducible without privileges (if applicable)
- Doesn't require authentication (if applicable)
- Affects multiple endpoints (if applicable)
- Can be chained with other vulnerabilities
## 13. Validation checklist (before submitting)
- [ ] The bug actually works
- [ ] The steps are clear
- [ ] The impact is well explained
- [ ] Nothing is missing
- [ ] It's not a false positive
- [ ] It's in scope
- [ ] It's not expected behaviorLo único que ambas versiones obligan a hacer: explicar el impacto en términos que entienda un triager que nunca ha visto la app, no solo "ejecuta alert(1)".