Skip to content

Cross-Site Scripting

Getting the browser to run attacker-supplied script in the context of a site the user trusts.

high severity Web

What is it

Cross-site scripting is when an application includes untrusted input in a page without properly encoding it, so a browser executes it as script.

How it works

Input arrives from a user, is stored or reflected back into a page, and the browser cannot distinguish it from the site's own code. It therefore runs with the site's privileges, meaning it can read cookies the site can read and act as the user.

The defence is contextual output encoding: the same value needs different treatment in HTML, in an attribute, in JavaScript and in a URL.

Why it matters

XSS turns any page into a platform for attacking its own users, and it is a common route to session theft and account takeover.

What can happen

Session theft, account takeover, keylogging within the page, defacement, and phishing hosted on a legitimate domain.

How to detect it

Unexpected script tags or event handlers in stored content, spikes in errors from content security policy reports, and unusual outbound requests originating from your own pages.

How to defend

Encode output for the context it appears in. Use a strict Content Security Policy. Set HttpOnly on session cookies so script cannot read them. Sanitise rich text with a maintained library rather than a regular expression.

Authorised lab

How ethical hackers test this

Assessed against authorised targets by demonstrating that input reaches an executable context, without deploying anything harmful to real users.

Testing without written authorisation is a criminal offence in most countries, including India under the Information Technology Act.