Stored XSS — Comment Section¶
| Field | Value |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Vulnerability | Stored Cross-Site Scripting (XSS) |
| Difficulty | Apprentice |
| Injection Point | Comment field in blog post comment section |
| Goal | Inject a script that executes for every visitor to the page |
Phase 1 — Reconnaissance¶
We find a blog post with a comment section. Testing each field for injection. The email and website fields have client-side format validation — they reject invalid formats before the form can be submitted. Client-side validation is not a security control: it only runs in the browser and can be bypassed via Burp or by removing validation attributes in DevTools. Server-side validation is what matters.
Phase 2 — Exploitation¶
Testing the comment field with a script payload:
<script>alert("hola");</script>
Filling in valid values for the remaining fields and posting the comment:
The thank you page appeared. Navigating back to the blog post:
Two alerts fired — the comment field is confirmed vulnerable. The script is now stored in the database and executes for every user who visits the page.
The name field rendered our payload as visible text rather than executing it — the name field is HTML-escaped. The comment field is not. Not all fields on the same form are equally vulnerable: always test every field independently, as partial sanitization is common.
Two alerts fired because the payload was stored once but the page rendered it in two places — once in the comment body and once wherever else the comment content appeared on the page.