Cross-site scripting in 2026: stored versus reflected XSS, CSP and output encoding, token theft, and how AAVETech tests it in a penetration test.
Cross-site scripting is still one of the most common findings in web application penetration tests, because it depends on the most ordinary thing in web development: putting user input into a page without encoding it. The impact has grown rather than shrunk, because a script running in your origin can read the DOM, read and rewrite anything in localStorage, and steal a session token. For Indian sites the stakes are a customer account takeover on a banking or e-commerce portal, a session theft that bypasses a well-configured MFA, and stored XSS that turns your own content into a credential-harvesting mechanism.
Three. Reflected XSS, where input arrives in a request and is written into the response, usually through a search term, an error message or a redirect parameter. Stored or persistent XSS, where the payload is saved and served to other users, usually through a comment, a review, a product name, a profile field or a support ticket. And DOM-based XSS, where the sink is in client-side JavaScript that reads a value from the URL, a postMessage event or a local storage entry. Reflected XSS is largely a phishing vector. Stored XSS is the serious one, because your own domain becomes the delivery mechanism and the session is a genuine first-party session. DOM-based XSS is the one testers find most often in modern single-page applications, because the framework's templating protects the template but not the JavaScript that handles data.
Because it removes the possibility rather than the instance. If every value is encoded for the context it lands in, then a payload is displayed as text rather than parsed as markup, whether it arrives in a query string, a JSON field, a stored record or a log file. Input validation and sanitisation are useful but fragile, because the same character has different meanings in HTML, in an attribute, in a URL, in JavaScript and in CSS, and because a blocklist of keywords is defeated by nesting and by encoding tricks. Contextual output encoding plus a proper templating engine that escapes by default, plus a Content Security Policy that does not allow inline script, is the combination that holds. A strict CSP with a nonce or hash per response is defence in depth, and it is what turns a missed encoding bug from a breach into an alert.
Session theft is the expensive part, and it is expensive because it bypasses your second factor. A token sitting in localStorage is readable by any script on the origin, so a stored XSS in a review field can exfiltrate a customer session on a banking or e-commerce portal and act as the customer with a valid first-party session. For businesses, the second impact is credential theft on your own domain, which is far more convincing than a lookalike page, particularly when a deepfake or a genuine-looking email is used to deliver the link. And the third is regulatory exposure, because a script that reads form fields and exfiltrates personal data engages the Digital Personal Data Protection Act, 2023, where DPDP Rule 7 notification obligations commence from May 2027. That is a reportable personal data breach, not just a bug.
Test every input that is reflected or stored, and test the contexts rather than the payloads alone. Submit a payload in a query parameter, a form field, a JSON body, a file name, a header and a cookie value, then observe whether it is encoded in the response, whether it is stored and re-rendered, and whether the same value executed in the client-side script. Then check the controls: is there a CSP, does it allow inline script, does it use nonces or hashes, are cookies HttpOnly, and is localStorage being used for session state at all. At AAVETech this is a named test area inside a fixed-price web application penetration test at roughly Rs 12,000 to Rs 30,000 per tester-day plus 18% GST, delivered in 5 to 10 working days with a retest after your fixes and a signed rules-of-engagement document.
| Variant | Example | Impact | Fix |
|---|---|---|---|
| Reflected | Search term rendered in results | Phishing on your domain | Contextual output encoding |
| Stored | Review or comment field | Session theft from your own origin | Encoding on write and on render |
| DOM-based | Client-side script reading a URL parameter | Account takeover | Avoid sink functions, validate on the client |
| Any variant | Token readable by script | MFA bypass via stolen session | HttpOnly cookies, no tokens in localStorage |
Cross-site scripting is still one of the most common findings in web application penetration tests, because it depends on the most ordinary thing in web development: putting user input into a page without encoding it. The impact has grown rather than shrunk, because a script running in your origin can read the DOM, read and rewrite anything in localStorage, and steal a session token. For Indian sites the stakes are a customer account takeover on a banking or e-commerce portal, a session theft that bypasses a well-configured MFA, and stored XSS that turns your own content into a credential-harvesting mechanism.
A popup is the least of the problems. Reflected XSS with no persistent element and no session access is often downgraded, but reflected payloads can still be used to rewrite the page, capture a click on a real link, or deliver a credential-harvesting form on your own domain, which is why the fix is the same regardless of severity.
Because MFA protects the login, not the session. If the session token is in localStorage, a script on the same origin can read it and replay it, so the attacker inherits an already-authenticated session. Moving the token into an HttpOnly cookie removes that path.
No, it is the second layer. A strict CSP with nonces or hashes limits what an injected script can do, and it turns a missed encoding bug into a visible CSP violation report rather than a silent breach. Encode on output first, then add CSP as defence in depth.
Encode on output in the correct context, replace string-built HTML with the framework's escaping templating, remove unsafe DOM sinks such as innerHTML for user data, move session tokens out of localStorage into HttpOnly Secure SameSite cookies, and add a strict CSP. Prioritise by reachability: stored XSS in a field other users see, first.
Yes, it is a standard test area in a fixed-price web application penetration test at roughly Rs 12,000 to Rs 30,000 per tester-day plus 18% GST, in 5 to 10 working days with a signed rules-of-engagement document and a retest after your fixes.
Read the full guide on AAVETech: Is Cross-Site Scripting Still a Risk for Indian Websites?.
Send us your application URLs and a test account for each role, and we will return a fixed-price web application penetration test scope with a signed rules of engagement.
Talk to an analyst about this.