💬 Community Feedback Board
Public employee feedback and discussion forum
Live Forum
Sandboxed Demo
Post a New Message
💡 Presenter Helper: Load XSS test payload
XSS Testing Lab Analysis
Vulnerable ModeIn Vulnerable mode comments are rendered as raw unencoded HTML; in Secure mode output encoding converts dangerous characters into harmless entities. Notice the Live Website Preview on the left updates in real time.
Sandboxed Preview
Browser Live Rendering
Submit Test Comment
Stored Comments
Saved in the server's database and shown here as plain text. A comment keeps running for every visitor until it is removed.
Attack detection analyzer
Submit a comment to analyze it.
Submitted payload inspector
payload
—
After output encoding (what a secure page sends)
encoded
—
How the attack works (Attack Flow)
1. Malicious Input<script>alert(…)</script>
→
2. Stored As-IsNo sanitization on storage
→
3. Raw HTMLInjected into DOM without encoding
→
4. ExecutionBrowser runs attacker's JavaScript
1. Malicious Input<script>alert(…)</script>
→
2. Output EncodedConverted to <script>…
→
3. Inert TextTreated strictly as text content
→
4. DefusedBrowser renders literal string, 0 execution
Educational Deep-Dive
What is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) allows attackers to inject malicious scripts into web pages viewed by other users.
When a web application includes unvalidated and unencoded user input in its output, the victim's browser has no way of knowing the script is untrusted and executes it with the full privileges of the user's session.
Stored vs. Reflected XSS
- Stored (Persistent) XSS (shown here): The injected script is permanently stored on the server's database (e.g. comment feed, forum post, user profile). Every user who views the page subsequently executes the malicious payload.
- Reflected (Non-Persistent) XSS: The payload is carried inside a request (e.g. search query parameter in a phishing URL) and reflected back immediately in the server's HTTP response.
How Context-Aware Output Encoding protects applications
Output encoding converts active HTML characters into their corresponding safe HTML entities:
When the browser encounters
< → < |
> → > |
& → & |
" → "
When the browser encounters
<script>, it renders the word "script" surrounded by angled brackets as readable text on the screen rather than creating an executable DOM script node.
Where does a stored payload live, and how is it removed?
Stored XSS lives in the server's database, not in the victim's browser. Clearing a browser's
cookies or local storage does nothing: the next page view fetches the comment again and it runs again. It stops
only when the comment is deleted from the database, which is what the Remove buttons in this lab do. If a real
site is affected, the payload must be removed and the missing output encoding fixed, or the same attack
simply works again.
Defense-in-Depth: Content Security Policy (CSP)
Even if a developer makes an output-encoding mistake, a strict Content-Security-Policy (CSP) header:
instructs the browser to refuse execution of any inline
Content-Security-Policy: default-src 'self'; script-src 'self';
instructs the browser to refuse execution of any inline
<script> tags or unauthorized external script domains, neutralizing XSS payloads before they can run.