Cross-site scripting (XSS) in plain English
Websites often display content that comes from users: comments, product reviews, search terms, or profile names. If the application doesn’t check this content carefully, an attacker can inject a small program instead of harmless text. It is usually written in JavaScript – the programming language browsers use to make web pages interactive.
The next visitor’s browser can’t tell whether the script comes from the website or from the attacker. It simply runs it – with all the privileges the website has for that visitor.
An analogy: imagine a bulletin board where anyone can pin up a note. A stranger posts an instruction that looks like an official notice from the building management. People might become suspicious – the browser doesn’t. It follows every instruction on the page.
How XSS works
There are three variants:
- Stored XSS: The malicious code is permanently stored in the application, for example in a comment, and affects everyone who opens the page.
- Reflected XSS: The malicious code is hidden in a specially crafted link, often sent in a phishing email. The application returns it unchecked as soon as the victim opens the link.
- DOM-based XSS: The flaw lies in the page’s own JavaScript, which inserts data – from the address bar, for example – into the page in an insecure way. DOM (Document Object Model) refers to the internal structure of a web page in the browser.
Once the script is active, it acts on behalf of the victim: it can read session data – the information that someone is currently logged in. It can also capture input such as passwords, change content, or trigger actions, such as placing an order or changing a password. In the OWASP Top 10, the best-known list of typical web application vulnerabilities, XSS falls under the Injection category.
A practical example
An online shop for bicycle accessories lets customers write product reviews. In one review, an attacker adds a short script alongside a few words of praise. The shop stores the review without checking it.
Before reviews are published, an employee approves them in the admin area. When she opens the review, her browser executes the script. It sends her session cookie – a kind of digital admission ticket that the shop issues after login – to the attacker. With it, the attacker logs into the shop under her administrator account without knowing her password.
The root cause: the shop displays reviews without neutralizing them first. In addition, the cookie lacked the HttpOnly attribute, which would have prevented scripts from accessing it.
Why does this matter for businesses?
XSS doesn’t target the server but the people who use your application – customers, employees, administrators. That is precisely what makes this vulnerability so tricky: the attacks run under your name and on your trusted domain. A fake login form on the genuine website is almost impossible for victims to spot.
The consequences range from hijacked customer accounts and stolen login and payment data to the takeover of administrator accounts. If personal data is affected, a reporting obligation under the GDPR may also arise. And then there’s the reputational damage when your website becomes a trap for your own customers.
How to protect your organization
- Encode output: Before displaying content, convert it in a way that suits the context, so that the browser treats it as text rather than code (output encoding).
- Validate input: Accept only what a field can legitimately expect – such as digits in a postal code.
- Use secure frameworks: Modern web frameworks – the programming toolkits used to build web applications – encode output by default. Avoid functions that insert content into the page as unfiltered code.
- Content Security Policy (CSP): This security policy defines the sources from which the browser may load scripts, thereby limiting the damage.
- Protect cookies: Give session cookies the HttpOnly attribute (no access for scripts) and the Secure attribute (transmission over encrypted connections only).
- Additional layer of protection: A WAF intercepts many attack attempts but is no substitute for secure coding.
- Test regularly: Have applications tested before go-live and after major changes – with automated scans (DAST) complemented by manual testing.
How Rootsektor can help
In a Web Applications & Online Shops penetration test, we specifically check for all three XSS variants – including in places that automated scanners easily miss, such as multi-step forms or the admin area. Each finding is documented with evidence, a CVSS rating, and a concrete remediation recommendation. We report critical vulnerabilities immediately – during the test, by phone or email to the agreed contact person. You can get your fixed-price quote after scoping via our Pentest Quote page.