Cross-Site Scripting (XSS): How It Works and How to Prevent It

Cross-site scripting (XSS) happens when a web application takes data an attacker controls and puts it into a page without making it safe, so the browser runs it as code. The target is your users, not your server: the script runs on your domain, in their session, with their permissions. Since 2021 the OWASP Top 10 has grouped XSS under Injection, as the current 2025 list still does. For related terms, see the cyber security glossary.

What is an example of cross-site scripting?

Take an online shop whose search page repeats the search term back to the user. A normal search requests /search?q=shoes and the page includes <p>Results for shoes</p> in its HTML.

An attacker sends a customer a link with a script in place of the search term, such as /search?q=<script>alert(document.domain)</script>, URL-encoded so it survives in a link. What happens next depends on whether the page encodes its output:

• Unencoded (vulnerable): the server returns <p>Results for <script>alert(document.domain)</script></p>, and the browser runs the script on the shop’s domain, inside the customer’s session.
• Encoded (safe): the server returns <p>Results for &lt;script&gt;alert(document.domain)&lt;/script&gt;</p>, and the browser simply shows the text as part of the search term.

The alert is a harmless proof that testers use. A real attacker would swap it for a script that sends keystrokes or session data to their own server, or rewrites the checkout form. This is reflected XSS. If the shop also saved search terms and showed them to other visitors, for example in a “popular searches” box, the same flaw would become stored XSS.

What are the types of XSS?

The three main types differ in where the payload lives.

Blind XSS is a stored variant that fires where the attacker cannot see it, such as an internal admin console, so the victim is usually a privileged member of staff.

What can an attacker do with an XSS attack?

Whatever the user could do on that page:

• Act as the user, or steal session tokens that scripts can read
• Change the account email or password to take the account over
• Show a fake login prompt on your genuine domain
• Read personal data or admin records displayed on the page

Why does XSS matter on payment pages?

XSS is one route for a card-skimming script to reach an e-commerce checkout. Injected JavaScript can capture card numbers as they are typed, or swap an embedded payment form for a fake one. The card data is stolen even though your servers never store it, and is then used for card-not-present fraud elsewhere.

PCI DSS v4.0.1 tackles this from several directions:

Which apply depends on how you take payments. Since January 2025, SAQ A omits 6.4.3 and 11.6.1 but requires merchants to confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems, which an XSS flaw on the page hosting the payment form would undermine. Our guides to SAQ A vs SAQ A-EP eligibility and PCI DSS 6.4.3 and 11.6.1 for e-commerce go further.

How do you prevent cross-site scripting?

Encode output for the context it lands in, and avoid code paths that bypass that encoding. Input validation helps but is not enough, because data that is safe in one context can be dangerous in another.

1. Use your framework’s auto-escaping and review every escape hatch, such as dangerouslySetInnerHTML in React, v-html in Vue or the bypassSecurityTrust functions in Angular.
2. Encode for the context. HTML body, HTML attributes, JavaScript, CSS and URLs each need different encoding.
3. Prefer safe DOM APIs such as textContent over innerHTML, and never pass untrusted data to eval() or similar functions.
4. Sanitise rich text with a maintained library such as DOMPurify where users must be allowed to write HTML.
5. Add defence in depth: a strict Content Security Policy and HttpOnly session cookies limit the damage if a flaw slips through.

The OWASP Cross Site Scripting Prevention Cheat Sheet sets out the encoding rules for each context.

How do penetration testers find XSS?

Testers map every input, from URL parameters and form fields to headers, file names and API fields, trace where each comes back out and send payloads built for that context. Stored inputs are followed to every screen that displays them, including back-office tools, and blind payloads call back to the tester if they fire somewhere unseen. DOM-based XSS is found by reading the client-side JavaScript for dangerous sources and sinks.

Automated dynamic application security testing (DAST) finds many reflected cases quickly. Manual web application penetration testing and source code review catch the stored and DOM-based issues that scanners tend to miss.

Why Sovereign Secure?

Our web application and API tests look for XSS by hand as well as with tools, and each finding is confirmed, rated and given a specific fix. As a PCI SSC Qualified Security Assessor company that is also ISO 27001 certified, we show how payment page findings relate to PCI DSS.

Next step: request a penetration testing quote for your website, checkout or API.