Cross-Site Scripting (XSS) Basics

What is it?

Cross-Site Scripting (XSS) happens when an application includes untrusted input in a web page without properly encoding it, allowing an attacker’s script to execute in another user’s browser. There are three main types: Stored XSS (the malicious input is saved on the server and served to every visitor, e.g. in a comment field), Reflected XSS (the input is immediately echoed back in the response, e.g. a search results page), and DOM-based XSS (the vulnerability exists in client-side JavaScript itself, without the server necessarily being involved).

Why should I learn it?

XSS is a permanent fixture on the OWASP Top 10 and is one of the most commonly asked web vulnerability questions, partly because the three types are frequently confused with each other.

How it works

An application takes user input (a comment, a search term, a URL parameter) → that input is included in the rendered page without proper output encoding → a browser interprets any embedded script tags or event handlers as real code → the script executes with the same trust level as the legitimate page, in the context of whichever user views it. The fix is output encoding (ensuring special characters are rendered as literal text, not executable code) applied wherever untrusted data is displayed — not just filtering input on the way in.

Real-world example

Stored XSS in a product review field means every visitor who views that review runs the attacker’s script — unlike reflected XSS, which typically requires tricking one specific victim into clicking a crafted link.

Troubleshooting mindset

If a fix for XSS only filters input, question it — filtering can miss encoding edge cases, while proper output encoding at render time protects the user regardless of how the data got there.

Common mistake

Do not memorise the definition without connecting it to real engagement practice. Ask: what does this concept mean for what I’m allowed to actually do, and how would I prove I stayed within scope?

Quick recap

• Understand the job of the phase or technique.
• Know where it sits in the overall testing methodology.
• Always tie it back to authorization and scope.
• Connect the topic to the next phase of the engagement.

Interview connection

Explain the concept in simple words first, then connect it to real engagement practice. That is stronger than repeating a tool name.

References & Further Reading

• AddySec original content — written for the Ethical Hacking track to build practical, interview-ready understanding.