| name | bugbounty-ideas |
| description | Use when the user wants bug bounty research ideas, authorized hacking/testing hypotheses, vulnerability hunting inspiration, or online writeup synthesis from a README or public bug bounty reports. |
Bug Bounty Ideas
Overview
Use the bundled README.md as an index of public bug bounty writeups, then research online sources to turn patterns into safe, authorized testing ideas. The goal is to produce practical hypotheses for a permitted target, not exploit instructions for unauthorized systems.
When to Use
Use this skill when the user asks for:
- Bug bounty ideas, hunting ideas, or vulnerability research inspiration.
- Online research based on the local
README.md writeup index.
- Ideas for XSS, CSRF, clickjacking, LFI, subdomain takeover, DoS, authentication bypass, SQLi, IDOR, 2FA, CORS, SSRF, race condition, RCE, buffer overflow, or Android testing.
- Turning public writeups into safe test hypotheses for an authorized program.
Safety Boundary
Before giving target-specific testing advice, confirm the work is within an authorized bug bounty scope. If scope is unclear, ask for the program scope, allowed assets, test accounts, rate limits, and excluded testing. If the user only wants learning or generic inspiration, keep the output generic and non-operational.
Keep recommendations non-destructive:
- Prefer passive research, test accounts, staging targets, and low-impact validation.
- Avoid weaponized payloads, exploit chains, credential theft, data extraction, persistence, and bypassing rate limits.
- Include stop conditions for ideas that could affect availability, privacy, or integrity.
- Label risky ideas and suggest reading the program rules before testing.
Workflow
- Read the bundled
README.md first. Extract relevant sections and links based on the user's requested vulnerability class, target technology, or program rules.
- If the user did not name a vulnerability class, pick categories from the README that fit their target surface. Examples: IDOR for object IDs and APIs, XSS for rich text and uploads, SSRF for URL fetchers and webhooks, race conditions for payments or rewards.
- Search online when a search tool is available. If only URL fetching is available, fetch selected README links and user-provided URLs. Prefer authoritative sources such as HackerOne reports, PortSwigger Web Security Academy, OWASP Testing Guide, vendor docs, and mature researcher writeups.
- Convert each source into a testing hypothesis. Focus on the vulnerable pattern, where it appears in modern apps, how to validate safely, what evidence to capture, and what impact it could prove.
- Cross-check ideas against the program scope and rules. Remove anything prohibited or too destructive.
- Present a concise list of prioritized ideas with sources and next safe steps.
Search Query Recipes
Use the README category plus target details to form queries:
| Goal | Query pattern |
|---|
| Find similar public reports | site:hackerone.com/reports <vulnerability> <technology> |
| Find learning references | <vulnerability> PortSwigger Web Security Academy |
| Find testing methodology | <vulnerability> OWASP testing guide |
| Find target-specific risks | <technology> <vulnerability> bug bounty writeup |
| Find framework pitfalls | <framework> security <vulnerability> misconfiguration |
If search is unavailable, select 3-8 relevant links from README.md and fetch them directly.
Output Format
Use this structure by default:
## Scope Check
- Authorization assumption:
- Target/scope used:
- Exclusions or unknowns:
## Research Sources
- README sections used:
- Online sources checked:
## Prioritized Ideas
### 1. <idea name>
- Category: <XSS/IDOR/SSRF/etc.>
- Inspired by: <README link or online source>
- Target surface: <feature or endpoint class>
- Hypothesis: <what might be wrong>
- Safe validation: <non-destructive check>
- Evidence to capture: <screenshots, request IDs, response differences, logs>
- Potential impact: <account takeover, data exposure, privilege change, etc.>
- Risk and stop condition: <when to stop or ask program owner>
## Next Searches
- <specific query or source to check next>
Idea Quality Checklist
Each idea should be:
- Traceable to a README entry or credible online source.
- Adapted to the user's target surface instead of copied from a writeup.
- Safe to validate under typical bug bounty rules.
- Specific enough to act on, but not a weaponized exploit recipe.
- Prioritized by likely impact, feasibility, and risk.
Common Mistakes
| Mistake | Fix |
|---|
| Dumping generic vulnerability definitions | Turn each vulnerability into a target-specific hypothesis. |
| Copying payloads from writeups | Explain the pattern and safe validation approach instead. |
| Ignoring program rules | Start with scope, exclusions, test accounts, and rate limits. |
| Treating README as complete | Use README as a seed list, then verify with online sources. |
| Suggesting destructive tests | Add stop conditions or replace with passive checks. |
Example
User asks: give me bug bounty ideas for an app with organizations, invoices, webhooks, and file uploads
Good response shape:
- IDOR on organization-scoped invoices: compare authorized test-account access across two orgs and capture response differences.
- SSRF-safe webhook callback validation: check whether URL fetch or callback preview features touch user-controlled URLs, using program-approved callback infrastructure only.
- Stored XSS in invoice notes or uploaded filenames: validate with harmless marker strings and rendering-context checks before trying any active script behavior.
- Race condition in invoice payment or coupon redemption: propose a low-rate, test-account-only concurrency check and stop before causing financial or availability impact.
