Imagine you open a comment section on a website. You expect to see someone’s opinion about the article. Instead, a small piece of JavaScript hidden inside a comment gets saved by the site and later runs inside another visitor’s browser. That’s a basic example of cross-site scripting, usually called XSS.
The important part is where the code comes from. The attacker isn’t asking you to download an obvious program. They’re taking advantage of a website that accepts user input and fails to handle it safely before showing that input to other people.
A Simple XSS Example
Say Raj visits a discussion forum and posts a normal-looking comment. An attacker posts something containing JavaScript instead. For example, the input could contain a script that changes the page or tries to access information available to that website session.
If the forum stores that comment without properly filtering or escaping it, the browser may treat the script as actual code when another person opens the discussion. The victim sees a normal webpage. Behind the scenes, the browser is executing something the attacker inserted.
That’s called stored XSS because the malicious input stays on the website. It can affect every visitor who loads the infected page until the content is removed.
What the Victim Sees
The result doesn’t always look dramatic. A script could alter text on the page. It could create a fake login prompt. In a serious case, it could attempt to steal session information or perform actions using the victim’s existing access.
Another Common Example
There’s also reflected XSS. Here, the malicious input isn’t permanently stored on the website. Instead, someone sends a specially crafted link that includes the unwanted script as part of the request, and the vulnerable page reflects that input straight back into the response.
Why XSS Happens
Usually, the root problem is poor handling of data coming from users or from a request. A website might display a name or comment directly inside its HTML without properly encoding characters that have a special meaning to the browser.
And that’s where XSS gets interesting. The browser isn’t necessarily broken. It is doing what the webpage tells it to do. The mistake happened earlier, when the website allowed untrusted input to become executable content.
So What Does the Example Teach Us?
A comment containing unexpected JavaScript might sound harmless when you’re thinking about one webpage. It isn’t harmless if the site stores that content and serves it to hundreds of visitors.
The clearest mental model is simple: an attacker gets data into a trusted webpage, and the browser mistakes that data for code. Stored XSS does this through saved content. Reflected XSS does it through a request that gets echoed back.
Once you understand that distinction, XSS stops feeling like some mysterious hacker trick. It’s really a trust problem between a website and the browser. And honestly, that’s what makes it so easy to overlook.