XSS: Cross-Site Scripting in Simple Terms
XSS (cross-site scripting) is when an outsider manages to execute their code on the pages of your site in the visitor's browser. The vulnerability is not in the server, but in how the site displays data coming from outside: from the address, form, comment, or profile.
Analogy for a Site Owner
Imagine a bulletin board at the entrance of a store. If someone brings a note saying, "give the keys to the cash register to the bearer," and you hang it up without reading — the employee will follow someone else's instructions as if they were yours. XSS works the same way: the site inserts foreign text into the page as its own, and the browser executes everything that is there, fully trusting your domain.
Types of XSS
| Type | Where It Lives | Affects |
|---|---|---|
| Reflected | The value from the address or form is returned directly in the HTML response | The one who clicked on the prepared link |
| Stored | Foreign text is stored in the database — comment, review, profile name | Everyone who opens this page |
| DOM-based | The site's scripts themselves insert data from the address into the markup | Visitors, while there are no traces in the server response |
What It Threatens
- Session Hijacking. A foreign script reads cookies and logs into the account or admin panel on behalf of the user.
- Spam and Hidden Links. The site starts promoting foreign topics and loses search trust.
- Label in Browser and Search Results. If malicious code was injected through the vulnerability, the domain ends up in databases of unsafe sites, the visitor sees a warning "this site may harm you," and the pages drop out of the index.
How It Looks in the Security Shield Report
The scanner inserts a harmless marker into the page parameters and checks if it returns in the HTML without escaping. If it does return — a finding "Indication of Reflected XSS" appears: medium severity, CWE-79 class, OWASP A03:2021 category. The note "requires verification" means that the service sees the surface but does not exploit it.
Active probes only occur in paid modes and on verified domains — a quick free check does not perform them. What else is checked is described in the article about Security Shield.
Open the address and parameter from the "Where Found" line and ask the developer to check if this value is escaped when outputting. Reflecting raw values in HTML is a signal that there is no filter here.
How to Close It
- Escape Output. Data from the user undergoes contextual encoding before being inserted into HTML: <, >, quotes, and ampersands are turned into safe sequences. In template engines, this is one setting.
- Check What Comes In. If the parameter is a number, accept only numbers. For texts with markup, use a verified HTML cleaning library.
- Enable CSP — even with a mistake in the template, it will prevent a foreign script from executing. How to start is described in the article about security headers.
- Close Cookies with HttpOnly and Secure flags, so the session cannot be read from JavaScript.
- Update CMS, Theme, and Plugins. Most XSS on typical sites comes from foreign extensions.
How to Prevent It from Happening Again
The rule is simple: every new field that the visitor sees goes through the same safe output as the others. Keep CSP enabled, repeat scans after releases and plugin installations. An SEO audit is also useful: a sudden increase in the number of external links often turns out to be the first sign of an injection.