How to Find Stored XSS in Bug Bounty (Still Paying in 2026)
Stored XSS means your payload is saved by the app and later shown to someone else.
That “someone else” might be another user — or an admin reviewing tickets. That difference drives severity.
Quick takeaway: Find saved fields → confirm execution in another session → aim at privileged viewers when possible → chain to real impact beyond alert boxes.
High-value places to plant payloads
- Display names and bios
- Comments and reviews
- Support tickets / chat widgets
- File metadata and SVG uploads
- Notification templates
- Markdown fields with partial HTML allowlists
Comfortable workflow
1) Create two browsers/users
User A stores. User B views.
2) Start with the smallest probe
A harmless unique marker beats a noisy polyglot on first pass.
3) Confirm context
Is the sink in HTML text, attribute, JS string, or URL context? That decides encoding bypasses.
4) Check who will see it
Admin-only stored XSS often beats reflected XSS in the same app.
Modern friction to mention
- CSP may block inline scripts — note bypasses or remaining impact
- HttpOnly cookies change cookie-theft stories — pivot to authenticated actions
- Sanitizers may allow clobbering or mutation XSS edge cases
Impact upgrade path
See our XSS → account takeover guide for chaining ideas once you have a reliable sink.
Fixes
Encode on output. Sanitize carefully. Prefer text APIs. Add CSP as defense-in-depth, not the only control.
Original Bugflare article. Builds on PortSwigger stored XSS academy concepts.