Glossary · simply explained

XSS (cross-site scripting)

XSS injects foreign JavaScript into your website — running in your users’ browsers, with their rights.

Cross-site scripting (XSS) injects foreign script code into a web page which then executes in other users’ browsers — with their session and rights. This becomes possible when an application builds user input into its pages unfiltered.

Consequences range from session theft and manipulated content to fake login masks within the real page context — practically undetectable for users because the address bar is correct.

The three XSS types

Reflected XSS delivers the payload via a crafted link that the application mirrors into the response HTML. Stored XSS is more dangerous: the code is saved — in comments or profile fields, say — and hits everyone who opens the page. DOM-based XSS arises entirely in the browser when client-side code processes input unsafely.

The core protection is consistent escaping: output is encoded per context (HTML, attribute, JavaScript, URL) — modern frameworks do this largely automatically as long as their protections are not bypassed. A content security policy additionally limits what injected code could do at all; the WAF filters known patterns at the edge.

Layers of defence against XSS

Context-appropriate output encoding — enforced by the framework, not hand-rolled.
Content security policy as damage limitation for the worst case.
HttpOnly cookies: sessions stay unreadable for scripts.
WAF rules against known XSS patterns, especially in front of legacy applications.

Frequently asked questions about XSS (cross-site scripting)

What can an attacker do with XSS?

Anything the page may do in the victim’s browser: take over sessions, capture input, manipulate content, trigger actions in the user’s name or display deceptively real login masks — with a correct address bar. XSS is therefore far more than a cosmetic flaw.

How do stored and reflected XSS differ?

Reflected XSS sits in a crafted link and only hits those who click it. Stored XSS lives in the application itself — in a saved comment, say — and automatically hits every visitor of the page. Stored XSS therefore has the greater reach.

Do modern frameworks protect against XSS?

Largely: React, Vue and co. escape output by default. It gets dangerous at the escape hatches — functions that deliberately render raw HTML, unsafe URL handling, legacy code alongside. The discipline lies in treating these exceptions like explosives.

What does a content security policy contribute against XSS?

It is the safety net: even if code is injected, the CSP limits what it may do — no foreign script sources, no data transmission to arbitrary destinations. A strict CSP often turns an XSS flaw into a failure instead of an incident.

Does a WAF help against XSS?

As a layer, yes: known attack patterns are blocked at the network edge, fresh flaws can be virtually patched — valuable especially in front of applications whose code cannot be changed quickly. The root treatment remains correct encoding in the application.