Cross-Site Scripting and Client-Side Attacks (XSS, CSRF, DOM Clobbering, Prototype Pollution)
XSS contexts and client-side primitives
XSS must be proven in the exact context: HTML body, attribute value, JavaScript string, URL, or CSS. Reflected, stored, and DOM-based variants differ in source and sink. CSP may block inline script; look for JSONP, script gadgets, or unsafe-eval. CSRF depends on ambient credentials: check token binding to session, SameSite, method, and content type; JSON endpoints may accept text/plain form posts. DOM clobbering abuses named elements to overwrite globals such as window.config; prototype pollution reaches Object.prototype via __proto__ or constructor.prototype in recursive merge/clone sinks, then a gadget turns it into XSS or RCE.
Worked example
A profile page reflects role into var role = "user";. Submitting ";alert(document.domain)// breaks the string, but CSP blocks inline alerts. Instead, use a permitted external script or an existing gadget; for a DOM sink, ?role=<img src=x onerror=...> may work if inserted via innerHTML. For CSRF, the email-change form includes a token but accepts GET; a <img src="https://target/change-email?email=attacker@x"> triggers the change because the session cookie is sent. The reasoning is to match payload to context and to the defense actually present.
Traps
Using alert(1) as the only proof; not testing each context; assuming HttpOnly prevents CSRF; treating CSP as unbypassable; sending prototype-pollution payloads that never reach a merge sink; forgetting that DOM clobbering requires the script to read a named property.