Cross-site scripting stays near the top of every web vulnerability list, and not because it is hard to prevent. It survives because it is easy to miss. A single unescaped variable in a template nobody reviews, buried in an application with a thousand inputs, is all it takes. This guide covers how to test XSS in practice, the same discipline sometimes written as how to test cross site scripting. You will map input vectors, then work through reflected, stored, and DOM-based testing. It covers selecting payloads by context, bypassing filters, and validating that a finding is real rather than a dialog box that fired once.
What Makes XSS Testable: A Quick Grounding Before You Start
XSS lets an attacker inject script that runs in another user’s browser, executing in that user’s session and origin. The same-origin policy that should isolate a malicious page does nothing here, because the script runs as part of the trusted site itself. That is the whole game, and it is why the three variants demand different testing methods.
Reflected XSS lives in a single request. Input goes up in a parameter and comes straight back in the response, unescaped, so testing means injecting and reading the immediate reply. Stored XSS persists. The payload is saved server-side and rendered later to whoever loads the page. The input and the execution can be minutes and three screens apart. DOM-based XSS never involves the server reflecting anything. Client-side JavaScript reads attacker-controllable data and writes it somewhere dangerous. The bug lives entirely in the browser, and you find it by reading code, not responses.
Phase 1: Map Every Input Vector Before Testing Anything
Testers who lose time on how to test XSS usually lost it here, by injecting before they mapped. Every place data enters the application is a candidate, and the obvious fields are the ones already hardened. Build the full list first. Knowing how to find XSS is mostly knowing where to look.
Visible Input Fields
Form fields, search bars, comment boxes, and login inputs are the visible starting points. That visibility is exactly why they are often the least fruitful. A developer who thought about XSS thought about the search box first. Test them, but do not expect the search bar on the homepage to be where the bug is hiding.
URL Parameters and Query Strings
Reflected XSS enters through URL parameters more than anywhere else. Browse the application like a normal user and watch the address bar and the requests behind it. Every parameter that shows up in a response is a candidate, including the ones that steer redirects, pagination, sorting, and error messages. A parameter echoed into an error page is a classic hit, because error handlers get written fast and escaped last.
HTTP Headers and Hidden Fields
Some inputs never appear in the interface. User-Agent, Referer, and X-Forwarded-For all get logged, and sometimes those logs render in an admin panel without encoding. Hidden form fields carry the same risk. You cannot reach these from the browser alone, so run an intercepting proxy and modify them in flight. These are the vectors developers forget, which is what makes them worth the setup.
JavaScript DOM Sources
DOM-based XSS comes in through JavaScript, not a form post. The sources to watch are document.URL, document.location, document.cookie, window.name, and data arriving via postMessage. Finding these means reading the client-side code to see what it consumes. Nothing you submit to the server tells you whether the front end is about to hand your input to a dangerous sink.
How to Test XSS That Reflects: Injecting and Observing
Reflected XSS is the most common variant and the natural place to start when you are learning how to test XSS end to end. The method is disciplined: find where input lands, understand the context, then pick a payload that fits it.
Start with a Unique Marker, Not a Payload
Do not lead with <script>. Lead with a harmless unique string like xsstestmarker123 in every input vector, then search the response for it. The marker tells you two things a payload would not: whether the input is reflected at all, and exactly where in the response it lands. You are separating reflection from execution, which lets you skip the inputs that go nowhere and focus on the ones that do. This one habit saves more time than any payload list.
Identify the Injection Context
Where your marker appears decides what payload can work, because the browser parses each context by different rules. Four contexts cover almost everything.
Inside HTML content, between tags, your input can open a new element directly, so <svg onload=...> is in play. Inside an HTML attribute value, you first have to break out of the quotes before anything else matters. Inside a JavaScript string, you are already in a script context and need to close the string and statement to run your own. Inside a CSS value, execution is far more constrained and usually depends on the exact sink. Find the marker, read the five characters on either side of it, and you know which of the four you are in.
Select and Test Payloads by Context
A proof of concept has one job: prove code executes. It does not need to steal anything. alert(1) firing is sufficient evidence, and print() is a reliable fallback in Chrome, where cross-origin iframe restrictions interfere with alert() in some configurations. When the dialog fires, execution is confirmed, and confirmation is the deliverable at this stage. Craft the payload to match the context you identified: break out of the attribute, or close the string, then execute.
Test for Filter Bypass When Payloads Are Blocked
A blocked payload is not a safe application. It means a filter is present, and filters are frequently incomplete. The main bypass categories, without turning this into a payload dump: vary the case in tag names when the filter only matches lowercase; URL-encode angle brackets or the script keyword to slip past a string match; inject into an existing event handler instead of a <script> tag; and split an attack string to defeat a filter that only strips the pattern once, since a non-recursive filter that removes <script> from <scr<script>ipt> reassembles your tag for you. For the exhaustive reference, use OWASP‘s XSS Filter Evasion Cheat Sheet. The mindset that matters: a filter blocking one payload is telling you it exists, not that it is complete.
How to Test XSS That Persists: Stored Payloads
Stored XSS is more dangerous than reflected for one structural reason. It needs no lure. Reflected XSS requires tricking a victim into clicking a crafted link. A stored payload executes on its own for every user who loads the infected page. Persist it once and it works on everyone, including administrators.
Identify Where Input Is Stored and Rendered
Find every place user input is saved and later shown to someone else. Comment sections, profile fields, product reviews, message threads, support tickets, and any user-generated content are the usual homes. Do not skip the administrative interfaces that display submitted data. A payload that fires in an admin dashboard runs in the highest-privilege session in the building.
Submit Payloads and Check Every Rendering Context
Submitting the payload is half the test. The other half is checking everywhere the data might surface. A username entered once at registration can surface in several places: a profile page, an admin user list, an email notification, and a log viewer. Each of those is a separate rendering context with its own encoding, or its own absence of encoding, and each is independently vulnerable. A username escaped correctly on the profile page can still fire unescaped in the admin panel.
Watch for Delayed or Out-of-Band Rendering
Not everything renders on submit. Data posted through an API might only appear later: a report generated hours after, a nightly email digest, or an admin review queue somebody opens on Monday. A payload that did not execute immediately did not necessarily fail, it may not have been rendered yet. Track what you submitted and where it might eventually surface, then check those places on their own schedule rather than concluding the input was safe.
Phase 4: Testing for DOM-Based XSS
DOM XSS is the hardest variant to find, because the server never processes or reflects the payload. The vulnerability lives entirely in client-side JavaScript, which means your proxy shows a clean response while the bug executes in the browser. You find this one by reading code.
Review JavaScript Source for Dangerous Sinks
Start in the JavaScript, looking for sinks: points where user-controllable data gets written into the DOM or executed. The recurring offenders are innerHTML, document.write(), eval(), setTimeout() called with a string argument, and jQuery methods like .html() and .append(). Each of these will execute markup or code handed to it. Locating them is a source-reading task, not a form-submitting one, and it is why DOM XSS slips past testers who only interact through the interface.
Trace Sources to Sinks
A sink is only exploitable if attacker-controlled data reaches it. Trace backward from each dangerous sink to its sources: URL fragments, query parameters, postMessage data, cookie values, and localStorage. The vulnerability is confirmed when you can control the data flowing from a source into a sink in a way that executes script, and from that point it belongs in vulnerability tracking. The fragment after # is a favorite, because it never leaves the browser, so server-side filtering and logging never even see it.
Use Browser Developer Tools Methodically
Developer tools are where DOM XSS testing actually happens. Use the console to watch how the page processes input. Search the live DOM for your injected marker to see where it materializes. Set breakpoints on suspect sink functions to catch the exact call that executes your data. Some XSS scanner tools include DOM-specific tracing that automates the source-to-sink mapping and cuts this work down substantially. That matters because manual DOM analysis is the slowest of the three.
Validating and Documenting XSS Findings
A payload that fires is the beginning of the work, not a finished xss check. The difference between a professional finding and raw scanner output is everything that happens after the dialog appears.
- Confirm the payload fires consistently, and is not an artifact of one browser version or a specific configuration.
- Establish the access required to trigger it: anonymous users, any authenticated user, or one privileged role. That scope drives the severity.
- Assess real impact. Can this payload steal session cookies, act as the victim, or capture credentials on submit? “It could alert” and “it could hijack an admin session” are different findings.
- Record the exact URL, parameter, payload, and full HTTP request needed to reproduce it, so a developer replicates the bug without guessing.
- Capture a screenshot or recording of the payload executing, not the input field where you typed it. Proof is the execution, not the injection.
Preventing XSS: What Developers Need to Fix When You Find It
Testers hand findings to developers, and a finding lands better with the fix attached. Keep this practical.
- Output encoding is the primary defense. User data must be HTML-encoded for HTML content, JavaScript-encoded for script contexts, and URL-encoded for
hrefattributes and URL parameters. The right encoding depends on where the data lands, which is the same context analysis from Phase 2. - Validate input against an allowlist of expected formats rather than a denylist of dangerous characters. A denylist is always one bypass behind.
- Set the
HttpOnlyflag on session cookies. It does not stop XSS, but it stops a payload from reading those cookies through JavaScript, which removes the most common escalation. - Configure a Content Security Policy. A tuned CSP limits what a successful payload can do by restricting which scripts the browser will run. That turns many working XSS bugs into dead ends.
- Avoid
innerHTML,document.write(), andeval()for user-controlled data. UsetextContentor safer DOM APIs, which removes the DOM sinks from Phase 4 at the source.
One follow-on step belongs here. XSS bugs also arrive through vulnerable front-end libraries. Pairing remediation with CVE Watch on your JavaScript dependencies closes the version-driven half of the problem that code review alone misses.
Running XSS Testing Continuously with Panopsys
Manual XSS testing is thorough and it does not scale. It takes specialist skill and hours per application. The result is a snapshot that goes stale the next time someone touches the template you just cleared. That is the structural limit of testing by hand, not a failure of the tester.
Pentest is the Panopsys module built to cover that gap, and it is not available yet. It is designed to apply the OWASP WSTG methodology to XSS automatically, reasoning about input context rather than replaying a fixed payload list. The same run would cover injection, authentication, and authorization across public-facing applications. The intent is output a human tester would recognize: the reproduction request, the execution proof, and the screenshots, not a bare list of flagged parameters.
