Is Cross-Site Scripting Still a Risk for Indian Websites?

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.

Key takeaways

• XSS remains among the most frequently reported findings in web application penetration tests, because it is a coding habit rather than a platform flaw.
• A script running in your origin can read localStorage, so it can steal a session token and bypass a well-configured second factor entirely.
• Output encoding is the fix that always works; an input filter alone is routinely bypassed by a nested or unusual payload.
• A Content Security Policy with nonces is defence in depth, and it is the only control that limits the damage when an injection slips through.
• Stored XSS in a comment, review or support-ticket field can become a persistent credential-harvesting page served from your own domain.

What are the XSS variants, and which one actually hurts?

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.

Why is output encoding the fix that always works?

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.

What is the business impact in India specifically?

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.

How should an application team test for XSS?

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.

XSS variants, impact and the control that fixes each VariantExampleImpactFix ReflectedSearch term rendered in resultsPhishing on your domainContextual output encoding StoredReview or comment fieldSession theft from your own originEncoding on write and on render DOM-basedClient-side script reading a URL parameterAccount takeoverAvoid sink functions, validate on the client Any variantToken readable by scriptMFA bypass via stolen sessionHttpOnly cookies, no tokens in localStorage

Frequently asked questions

Is Cross-Site Scripting Still a Risk for Indian Websites?

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.

Is reflected XSS dangerous if it only shows a popup?

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.

Why does XSS bypass multi-factor authentication?

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.

Does a Content Security Policy replace output encoding?

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.

How do you fix XSS in an existing application?

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.

Does AAVETech test for XSS?

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.