Google XSS Game – Levels 1 to 6

This document provides a detailed, educational walkthrough of Levels 1–6 of the official Google XSS Game
https://xss-game.appspot.com/

Each level is explained with:

• Vulnerability type
• Root cause
• Exploitation logic
• Example payloads
• Secure coding takeaway

Level 1 – Hello, world of XSS

XSS Type: Reflected XSS

What happens?

User input from a form field is directly reflected into the HTML response without sanitization.

Root Cause

• No output encoding
• Input is inserted directly into the DOM

Exploit Logic

The browser parses the reflected input as HTML, allowing injected <script> tags to execute.

Example Payload

<script>
  alert("XSS");
</script>

Why it works

The application trusts user input and renders it as-is.

Secure Coding Takeaway

• Always escape output
• Use frameworks that auto-escape HTML

Level 2 – Persistence is key

XSS Type: Stored XSS

What happens?

User input is stored server-side and rendered for all users.

Root Cause

• No input sanitization before storage
• Dangerous HTML attributes allowed

Exploit Logic

Instead of <script>, an image error handler is used to bypass simple filters.

Example Payload

<img src="x" onerror="alert('XSS')" />

Why it works

Event handler attributes (onerror) execute JavaScript when triggered.

Secure Coding Takeaway

• Sanitize input before storing
• Use allowlists, not blocklists

Level 3 – That sinking feeling…

XSS Type: DOM-based XSS

What happens?

JavaScript reads the URL fragment (window.location.hash) and injects it into the DOM.

Root Cause

• Untrusted data used in DOM manipulation
• No sanitization of hash values

Exploit Logic

The attacker injects an attribute-breaking payload into an image tag.

Example Payload (URL)

#1' onerror='alert("XSS")'>

Why it works

The injected string breaks out of the intended attribute context.

Secure Coding Takeaway

• Treat URL fragments as untrusted
• Avoid innerHTML

Level 4 – Context matters

XSS Type: JavaScript Injection

What happens?

User input is injected into an inline JavaScript block.

Root Cause

• No escaping for JavaScript context
• Assumption that input is numeric or safe

Exploit Logic

The payload closes the existing string or statement and injects JavaScript.

Example Payload

');alert('XSS

Why it works

JavaScript interprets the payload as executable code.

Secure Coding Takeaway

• Use JSON encoding
• Avoid inline JavaScript

Level 5 – Breaking protocol

XSS Type: JavaScript URI Injection

What happens?

A URL parameter defines the destination of a link or redirect.

Root Cause

• No protocol validation
• javascript: scheme allowed

Exploit Logic

The browser executes JavaScript instead of navigating.

Example Payload

javascript:alert('XSS')

Why it works

Browsers treat javascript: URLs as executable code.

Secure Coding Takeaway

• Enforce allowed protocols (https: only)
• Never trust redirect parameters

Level 6 – Follow the X

XSS Type: Script Injection via data: URL

What happens?

A script source is dynamically loaded from the URL fragment.

Root Cause

• No validation of script source
• Dangerous URI schemes allowed

Exploit Logic

A data: URL is used to inject JavaScript directly.

Example Payload

data:text/plain,alert('XSS')

Why it works

data: URLs can contain executable JavaScript.

Secure Coding Takeaway

• Enforce strict CSP
• Never dynamically load scripts from user input

Global Defensive Measures

• Context-aware output encoding
• Content Security Policy (CSP)
• Avoid eval, innerHTML, inline JS
• Validate & sanitize all user input
• Separate data from code