Cross-Site Scripting (XSS)
TL;DR
Cross-Site Scripting (XSS) is when an app reflects attacker-controlled input back into a page without properly encoding it, so the browser runs it as code. The fix is to treat all output as data: encode it for the context it lands in, and set a Content Security Policy.
Only test apps you own or are authorised to test.
What it is
A web page mixes the app’s own markup with data. If user input ends up in the page without being encoded, the browser can’t tell your data from the app’s code, and it will run script that shouldn’t be there. That’s XSS.
How it works
There are three flavours you’ll meet:
- Reflected — input in the request is echoed straight back in the response (a search term shown on the results page).
- Stored — input is saved and shown to other users later (a comment, a profile name). The most damaging kind.
- DOM-based — client-side JavaScript writes untrusted input into the page itself, no server round-trip needed.
How to test for it
At heart, testing for XSS is checking whether input can break out of its context and be treated as markup:
- Put a harmless unique marker in a field and find where it lands in the response. Is it inside HTML, an attribute, a script block, a URL?
- See whether special characters (
<,>,") come back encoded or raw. Raw is the warning sign. - Burp Suite is the usual home for this; browser dev tools help with DOM-based cases.
How to fix it
- Context-aware output encoding — encode data for exactly where it’s placed (HTML, attribute, JS, URL). Frameworks that auto-escape do most of this for you.
- Add a Content Security Policy as a second line of defence.
- Avoid sinks like
innerHTML; prefer safe DOM APIs.
Reference: OWASP: Cross-Site Scripting and the XSS prevention cheat sheet.