Cross-site scripting (XSS) is an attack where someone sneaks malicious code, usually JavaScript, into a web page so it runs in the browser of everyone who views it. Because the code executes with the same trust as your real site, it can read what users type, hijack their login session, or redirect them somewhere harmful. The visitor never sees it happen.
A typical example: a comment box that does not clean its input. An attacker posts a comment containing a hidden script instead of text. Every later visitor who loads that comment unknowingly runs the script in their own browser. It is a bit like leaving a forged note in a trusted noticeboard, where everyone who reads the board acts on it. XSS sits high on the OWASP Top 10 for exactly this reason.
That stored version is the most damaging, but there is also a reflected kind, where the bad code rides in on a crafted link and fires the moment a victim clicks it. Both share one root cause: data the site received from outside ends up treated as code. The defence is to treat all user input as untrusted: escape or sanitise anything before it is shown on a page, so a script becomes harmless text. A Content Security Policy adds a strong second layer by telling the browser to refuse any script the site did not explicitly approve.
A common trap is escaping for one spot but not another. Text that is safe inside a paragraph can still break out when dropped into an HTML attribute or a URL, so the escaping has to match where the value lands.
At TopDevs we escape output by default and ship a tuned Content Security Policy on the apps we build, so injected scripts have no room to run.
