Browse the site
Services
Who We Serve
Problems We Solve
Across India
Guides & Resources
Questions
Blog
Profiles
Company
Call Get a quote

How Do You Secure Your Website Against XSS?

Cross-site scripting happens when data you did not write reaches the browser as executable script. The fix is not a blacklist of keywords, because attackers use event handlers, encoded payloads and markup in unexpected places. The fix is context-aware output encoding at the point of rendering, so a value becomes text rather than code, plus a strict Content Security Policy that limits what a script may do even if an injection survives. Sanitise any HTML you genuinely intend to render, on the server, with a maintained library, and keep your framework's auto-escaping on.

Key takeaways

  • Context-aware encoding is the primary control, because the same value is dangerous in a different way inside an HTML body, an attribute, a JavaScript string or a URL.
  • A strict Content Security Policy with nonces or hashes is the second layer, and it turns a successful injection into a blocked script rather than a session theft.
  • Server-side sanitisation with a maintained library is the right answer for rich text, and the allow-list is the right way to write it, because blacklists always miss a payload.
  • Keep framework auto-escaping enabled and stop using raw HTML output for user content, since the framework default is right far more often than a hand-rolled escape function.
  • Stored XSS on a page that serves other users, such as a review, a profile or a support ticket, is a personal data breach under the DPDP Act and carries a CERT-In reporting duty.

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What is the correct way to prevent cross-site scripting?

Encode at the point of output, for the context you are writing into. If a value goes into an HTML text node, encode the characters that start tags. If it goes into a quoted attribute, encode the quote and the angle brackets. If it goes into a JavaScript string or script block, use JSON encoding or a JavaScript escaper, because HTML encoding alone is wrong there. If it goes into a URL, validate the scheme against an allow-list so a javascript: URL cannot be smuggled in. Ask whether the value needs rich text at all, and where it does, run it through a server-side sanitiser with an allow-list of tags. Then apply a Content Security Policy that forbids inline script.

What should a Content Security Policy look like in practice?

Start strict and relax only what you can name. A policy of default-src 'self' with script-src 'self' plus a nonce or hash per response, and no object-src 'none', blocks a large class of injection. Use nonces rather than 'unsafe-inline', because a nonce cannot be guessed and does not need to be added to every script tag. If a third-party script, a payment widget or an analytics tag genuinely needs to run, list that specific origin explicitly and review it, rather than falling back to 'unsafe-inline' or 'unsafe-eval'. Roll the policy out in report-only mode first so violations are logged without breaking pages, then enforce. A policy is a second layer, not a replacement for encoding.

How do I stop XSS in the places developers forget?

Six places account for most findings. Rich text editors and comment fields, where content is stored and later rendered as HTML, need a server-side sanitiser. File upload names, which end up in a link and must be sanitised. URL parameters reflected in the page, in the canonical URL or in a redirect. JSON responses, when embedded into a script block or read with innerHTML, which need a different encoding from plain HTML. Error pages and email templates, which are rarely sanitised and often include user input. And third-party widgets, whose scripts run in your origin and inherit your policy. A web application security testing engagement should attempt a real injection in each of these.

XSS prevention controls by output context, with the failure that each one prevents
ContextCorrect controlFailure it prevents
HTML text bodyHTML entity encoding at outputTag injection that executes script
Quoted attributeAttribute encoding including the quoteAttribute break-out and event handler injection
JavaScript string or script blockJavaScript or JSON encodingScript break-out into executable code
URL or redirect parameterScheme allow-list and validationjavascript: URL execution
Rich text from a userServer-side sanitiser with an allow-listStored script in comments and reviews
Any inline scriptContent Security Policy with noncesExecution of a payload that slipped through

What are the frequently asked questions?

How do I secure my web application against XSS?
Cross-site scripting happens when data you did not write reaches the browser as executable script. The fix is not a blacklist of keywords, because attackers use event handlers, encoded payloads and markup in unexpected places. The fix is context-aware output encoding at the point of rendering, so a value becomes text rather than code, plus a strict Content Security Policy that limits what a script may do even if an injection survives. Sanitise any HTML you genuinely intend to render, on the server, with a maintained library, and keep your framework's auto-escaping on.
Does a Content Security Policy alone stop XSS?
No. It limits what a script can do and blocks a large share of payloads, but a policy cannot rewrite an unsafe value that reaches the page. Encoding fixes the injection, and the policy is the second layer that limits the impact if something slips through.
Is a WAF enough to protect against XSS?
No. A WAF filters known patterns and can be evaded with encoding tricks and unusual contexts, and it never sees values that arrive from a different path. Fix the encoding at the sink, and use the WAF as a supplementary filter.
Should I sanitise HTML on the client or the server?
On the server. Client-side sanitisation can be skipped, because the attacker controls the request, not the browser. Sanitise when you store or when you render, and treat the client copy as a display concern only.
What should I do if I find XSS on my live site?
Treat it as an incident. Restrict the affected input, deploy the encoding fix, then review access logs and the affected pages for exploitation and for data exposure, because a stored payload may already have run in other users' browsers. If personal data was involved, assess the DPDP Act notification duty and the CERT-In reporting timeline.

Get a straight answer on this

Send us one URL and a test account, and we will return a scoped XSS and injection testing plan with fixed pricing.

Send us the details See pricing

Related

Last reviewed: 24 October 2026. Information on this page is general guidance, not legal advice. Prices are indicative bands for a typical scope and are confirmed in a written quote before any work begins.