What is cross-site scripting (XSS)?

XSS: definition and cause

A website becomes vulnerable when it builds user input into its pages unchecked—such as comments, search terms or profile details. If the input contains script code, the next visitor’s browser executes it as if it belonged to the page. The code then has the same rights as the legitimate page code.

XSS has been among the most common vulnerabilities in web applications for years and is counted in the OWASP Top 10 under the Injection category. Unlike SQL injection, the server is not the immediate target but the visitors and administrators of the website.

The three types of XSS

In stored XSS, the malicious code is saved permanently, for example in a comment, and hits everyone who opens the page. In reflected XSS, it sits in a manipulated link that is sent, for example, by phishing email. In DOM-based XSS, the flaw arises only through JavaScript in the browser that writes data into the page unsafely.

• Takeover of sessions and user accounts
• Reading inputs such as passwords or payment data
• Displaying fake forms on the genuine page
• Redirecting to malicious sites
• Attacks on administrators via the back end

Real-world example: the review in the online store

An online store allows product reviews and displays the text unfiltered. An attacker posts a small script instead of a review. When a shop administrator later opens the review in the back end, the script could capture their session key and give the attacker access to the administration.

The shop protects itself by encoding output according to context so that scripts appear only as text, securing session cookies with the HttpOnly and SameSite attributes, and using a content security policy (CSP) that only allows approved script sources. The back end also sanitizes reviews before display.

Protection, limits and imple­menta­tion

The most important measure is context-aware output encoding: data is escaped before display so that the browser treats it as text rather than code. Modern frameworks such as React do this by default, unless developers deliberately bypass it. The CSP limits the damage if something slips through anyway; permitted HTML, for example from text editors, is cleaned with vetted libraries.

Nano Concepts checks web applications and shops for XSS, fixes flaws in code and plugins and sets up security-relevant HTTP headers such as the content security policy. For new projects, we make sure from the start that user input never ends up in pages unchecked.

• Outputting input unchecked into pages, especially in comments and search fields
• Using innerHTML or similar functions with user data
• Relying only on input filters instead of output encoding
• Embedding third-party scripts and plugins without review
• No content security policy and unsecured cookies