XSS Attack

Every website consists of text, images, and small programs that run in the visitor’s browser. These programs make sure menus expand or forms get checked. An XSS attack exploits the fact that many sites display text from users, such as comments or profile names. Instead of a normal comment, the attacker writes such a small program into it. If the site passes this text along unchecked, every other visitor’s browser executes the program. The abbreviation XSS stands for Cross-Site Scripting, meaning roughly “execution of scripts across sites”.

Why a foreign script is so dangerous

The browser doesn’t distinguish who wrote the code. It only sees that this code came from the site the user is currently visiting. That’s why the injected code receives the same rights as the site itself. It’s allowed to read and change everything displayed on the page.

Especially valuable to attackers is the so-called session cookie. This is a small file that proves to the server that you’re already logged in. Whoever grabs this cookie can pretend to be you without knowing your password. A successful XSS attack on a social network can thus take over thousands of accounts at once.

XSS has ranked among the most common web security vulnerabilities for years. The reason is simple: almost every modern site displays content from users somewhere. Every one of these spots is a potential entry point. For companies, such a vulnerability can mean fines under data protection law and a significant loss of trust.

The three ways the code gets onto the page

With stored XSS, the attacker permanently places their code on the server, for example as a forum post. Every visitor who opens this post gets attacked. This is the most dangerous variant because it reaches a great many victims without any further action. The attacker doesn’t need to do anything else afterward.

With reflected XSS, the code is embedded in a link. The attacker sends this link via email or chat. If the victim clicks it, the server sends the code back as part of the response page, and the browser executes it. A third variant is called DOM-based XSS. Here, the server is not involved at all, and it’s only the page’s own script that builds the dangerous data into the display.

Protection always follows the same basic idea: user input is text, never commands. Developers therefore convert special characters before displaying anything. An angle bracket, for instance, becomes a harmless character code that the browser only displays instead of executing. Additionally, a Content Security Policy restricts which scripts a page is even allowed to run. One common misconception, by the way, is that HTTPS protects against XSS: encryption only secures the transport path, not the content.

XSS in headlines and in your own browser

Reports about XSS vulnerabilities appear regularly in tech news, often together with an identification number that begins with “CVE”. In the past, large platforms, online shops, and even widely used toolkits such as WordPress extensions have been affected. A well-known historical example is the Samy worm, which spread across the MySpace network in 2005 and altered over a million profiles within a single day.

Even as a regular user, you can encounter this topic. Suspiciously long links with strange character sequences are a warning sign, especially if they come from strangers. Keeping browsers and extensions up to date also helps. However, the greatest share of responsibility lies with the operators of the websites.

In software development, XSS is a standard topic in every security review. Companies pay bounties to people who report such vulnerabilities, often several hundred to several thousand euros per find. XSS should be distinguished from SQL injection: there, the database on the server is attacked, whereas with XSS, it’s the visitor’s browser that is attacked.