Cross-Site Scripting and Client-Side Attack Chaining
Context decides the payload
XSS is a context problem. Identify the exact output location - HTML body, attribute, quoted attribute, JavaScript string, JSON, CSS, URL - then pick a payload for that context. Reflected, stored, and DOM-based variants differ only in where the data enters and whether the server ever sees it; DOM XSS lives in innerHTML, document.write, eval, and unsafe location handling.
Escaping must be applied at the point of output, and encoded for the right context. Watch for encoding mismatches: a page declaring a legacy charset can turn a benign byte sequence into tags, and double-decoding can resurrect an escaped payload. Sanitizer bypasses usually come from mutation XSS in browser parsing, allowed-but-dangerous attributes, or URLs in javascript: scheme.
CSP is a mitigation, not a fix. Look for unsafe-inline, unsafe-eval, JSONP endpoints, or an allowed CDN hosting an angular or jQuery gadget that re-enables script execution.
Chaining is where the marks are earned: steal a CSRF token and perform a state-changing request; force an admin to trigger SSRF or add an attacker account; use XSS to read an API token from localStorage; combine with an open redirect for a convincing exploit page. HttpOnly blocks cookie theft but not actions performed as the victim.
Traps: assuming blacklist filters catch modern event handlers; forgetting that self-XSS is not a finding unless it can be induced; ignoring stored XSS in admin-only views; and treating sanitization done on input, rather than output, as safe.
Rule of thumb: write the surrounding HTML and JavaScript by hand around the injection point before choosing the payload, then test in the browser that actually runs the app.