Cross-Site Scripting (XSS)

Why it matters

For the product, XSS turns a harmless text field into an entry point: a session cookie without HttpOnly can be read, forms can be submitted in the victim’s name, a fake login box can be drawn over the real page, and stored XSS on an admin screen hands the attacker the most privileged users. For the tester it is one of the few security defects that ordinary functional testing can find, because every feature that displays user input is a candidate.

It is also a defect you can find without attack tools and without harm: a unique marker typed into a field and a look at the page source answer the question "is this value treated as text or as markup?". Knowing the three variants tells you where to type the marker and where to look for it.

Reflected, stored and DOM-based XSS

Every XSS has the same shape: an untrusted value enters at a source and reaches a sink that interprets it as code. The variants differ in where the value waits and who turns it into markup, and the OWASP Web Security Testing Guide tests them separately because the steps and the people exposed differ.

Reflected XSS: the value travels in the request, usually a query parameter or form field, and the response echoes it at once, as in "0 results for …" on a search page. Only the sender sees it, so an attacker must get the victim to send the request, usually by opening a crafted link. Stored XSS: the value is saved (a review, a ticket, a profile field, a file name) and rendered later to other users, staff included. No link is needed and every viewer is exposed, which is why it is usually the most severe. DOM-based XSS: the server response is clean, but the page’s own JavaScript reads a source such as location.search, location.hash, document.referrer or a postMessage event and writes it into a sink such as innerHTML, document.write or eval. The part of a URL after # is never sent to the server, so this variant can leave no trace in server logs, and no server-side encoding can fix it.

Reflected  - travels in the request, echoed at once
  GET /search?q=qa7<b>x</b>qa7
  <h2>0 results for qa7<b>x</b>qa7</h2>

Stored     - saved now, rendered to someone else later
  POST /reviews        title=qa7<b>x</b>qa7
  GET  /agent/reviews  (agent B, next day)
  <td>qa7<b>x</b>qa7</td>

DOM-based  - server response clean, the page script writes it
  https://shop.example/help#qa7<b>x</b>qa7   (the part after # never reaches the server)
  status.innerHTML = 'Showing: ' + decodeURIComponent(location.hash.slice(1));

Safe probes: is the value text or markup?

You do not need to run a script to prove XSS. The defect is "user input is written into the page without encoding", and a visible, harmless probe proves it. Build the probe from a unique marker such as qa7 plus the characters that matter in HTML: <, >, ", ' and &. The marker lets you search the rendered page and its HTML source (View Page Source, Ctrl+U) for every place the value landed, including places you did not expect: the <title>, an attribute, an email, a CSV export, an error message.

Read the result in the source, not only on screen. qa7<b>x</b>qa7 means the value was HTML-encoded and is safe in that position; qa7<b>x</b>qa7 between tags means markup was accepted; in an attribute, check whether your quote closed it. The Elements panel shows the DOM, not the source: there the safe value is one text node, while accepted markup appears as a separate b element. Use an executing probe, one that only displays the marker, when the team needs proof that script runs, and only in a test environment with your own accounts and written permission. Remove stored probes afterwards: they stay in the database and surprise colleagues weeks later.

• Enter the probe wherever a user can type or upload: forms, URL parameters, file names, imported files, API fields a page shows later, and request headers the application reflects, such as User-Agent or Referer.
• Look at every output, not only the one next to the input: lists, detail pages, admin queues, notifications, previews, printed or PDF versions, and JSON a page embeds in a <script> block.
• For DOM-based XSS put the probe in the fragment (#…) and in parameters the page’s JavaScript reads, and watch the DOM in DevTools rather than the server response.
• Never probe a system you do not own or have written permission to test: unauthorised probing may be unlawful even without a script, and a stored probe in production is seen by real users.

Probe                                 What a hit means
qa7<b>x</b>qa7                        "x" in bold: HTML text context is not encoded
qa7"'>x                               your quote closes the attribute in the source
qa7<script>alert('qa7')</script>      a script parsed from the response executes
qa7<img src=x onerror=alert('qa7')>   runs via innerHTML too, where <script> does not

Executing probes: test environment, own accounts, written permission, then remove.

Try it: Special Character Dataset Generator Try it: URL Encoder

Defences: output encoding by context, sanitisation and CSP

The primary defence is output encoding matched to the context, which the lesson on input validation and output encoding introduced. For XSS testing, what matters is where it usually fails. First, the wrong context: HTML entities do not protect a value inside a <script> block, an event-handler attribute such as onclick or a style, and the OWASP Cross Site Scripting Prevention Cheat Sheet calls such places dangerous contexts, where encoding alone may not prevent XSS, and advises passing user values as data instead of writing them into code; a user-supplied link in href also needs its scheme checked against an allow-list such as https:, so that javascript: is refused, because encoding leaves the scheme untouched. Second, bypassed defaults: template engines and frameworks encode HTML text automatically, so the defects hide in their escape hatches, such as dangerouslySetInnerHTML, v-html or a direct innerHTML assignment. Third, the browser side: in DOM-based XSS no server encoding takes part, and the fix is a safe sink such as textContent instead of innerHTML.

Input validation helps where the format is strict (a date, a quantity) but cannot replace encoding: the name O’Brien, a message containing <3 and a product called A&B are legitimate. When HTML is itself a feature, as in a rich-text comment, encoding would destroy it, and the defence is an allow-list sanitiser that keeps <b> and <a href> but strips scripts and event handlers.

A Content Security Policy (CSP) is the second layer. The Content-Security-Policy response header tells the browser which scripts may run: script-src 'self' allows only scripts from the site’s own origin, a 'nonce-…' or hash allows specific inline scripts, and 'unsafe-inline' lets every inline script and event handler run, which switches that protection off (current browsers ignore it when a nonce or hash is also listed). With a strict policy an injected <script> or onerror handler is blocked and logged in the console, which limits the damage of an encoding defect without repairing it. Read the policy with the Security Header Analyzer or the HTTP Headers Parser and check script-src, or default-src when it is absent. Content-Security-Policy-Report-Only reports violations and blocks nothing; teams use it to try a policy before enforcing it.

Where the value lands       Defect seen in the source         Defence
HTML text    <td>...</td>   <td>qa7<b>x</b>qa7</td>           HTML entity encoding
Attribute    value="..."    value="qa7"'>x"                   entities, quoted attribute
Link         href="..."     href="javascript:..."             allow-list the scheme
DOM sink     innerHTML      <b> rendered from location.hash   el.textContent = value
Rich text    comment        an onerror= attribute survives    allow-list sanitiser

Strict:  Content-Security-Policy: script-src 'self' 'nonce-R4nd0m'; object-src 'none'
Weak:    Content-Security-Policy: script-src 'self' 'unsafe-inline' *

Try it: HTML Entity Encoder Try it: Security Header Analyzer Try it: HTTP Headers Parser

Worked example: a review that reaches the support desk

A shop lets customers review products and shows new reviews to support agents in a queue. You test in staging with two accounts, customer A and agent B, under the team’s written permission for security checks. As A you submit a review titled qa7<b>x</b>qa7 with the body qa7"'>x. The product page shows the title literally and its source has qa7<b>x</b>qa7: encoded. As B, the queue shows x in bold and its source has <td>qa7<b>x</b>qa7</td>: stored XSS reaching staff. The body is shown as typed on both pages. The search page answers /search?q=qa7%3Cb%3Ex%3C%2Fb%3Eqa7 with "0 results for qa7x", x in bold: reflected XSS. Every response carries Content-Security-Policy: script-src 'self' 'unsafe-inline', so the policy would not stop a real script in either place.

• Finding 1, Critical: review titles are rendered as HTML in the agent queue. Evidence: the input, the source line, both roles, a screenshot.
• Finding 2, Major: the search term is echoed as HTML on the results page. Evidence: the exact URL and the source line.
• Finding 3, Minor (hardening): the CSP allows 'unsafe-inline' scripts and would not limit findings 1 and 2.
• Confirmation testing after the fix: repeat the probes and expect the encoded form in the source, and check that a legitimate title such as Fast & cheap still displays as typed rather than as Fast & cheap.

Frequently asked questions

References

• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP FoundationPreventing XSS: output encoding for each context, sanitizing user-authored HTML, safe DOM sinks and framework protections, with CSP only as defence in depth.
• Cross Site Scripting (XSS)OWASP FoundationWhat cross-site scripting is, its reflected / stored / DOM variants and how encoding prevents it.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• Content-Security-Policy — MDNMDN Web Docs (Mozilla)The CSP header directives that restrict where scripts, styles and other resources may load from.