What is cross-site scripting (XSS)?
Cross-site scripting, or XSS, is a web attack in which the criminal injects a malicious script inside a legitimate, trusted website so that it runs in the browser of whoever visits the page. Because the code comes from a site the victim trusts, the browser runs it without suspicion, and so the attacker steals sessions, passwords, and data from the site's own users. In short: the company's site becomes the weapon used against its customers.
How cross-site scripting works
A site shows back on screen much of what users type: a comment, a profile name, a search term. XSS happens when that text is repeated without handling and includes a script. The next visitor's browser receives the code as if it were a legitimate part of the page, and runs it.
Find the echo point
The attacker looks for a field whose content the site shows to other users without cleaning: a comment box, a profile field, a search result that repeats what was typed.
Inject the script
Instead of ordinary text, they insert a snippet of browser code (a script). If the site stores or repeats that content without handling it, the code stays planted.
The victim loads the page
When someone else opens the page, the site delivers the script along with the legitimate content. To the victim's browser, the code came from a trusted source, so it runs without a barrier.
The script acts
Now running in the victim's browser, the code steals the session cookies (to impersonate them), captures what they type, redirects to a fake page, or performs actions in their place.
Source: OWASP (XSS is part of category A03:2021, Injection).
The three types of XSS
- Reflected XSS The script travels in a malicious link. The victim clicks, the site returns the code in the response and it runs in their browser. It hits one target at a time and is not stored; it usually arrives by email or message.
- Stored XSS The script is saved on the site's server (in a comment, a profile, a sign-up field) and served to everyone who opens that page. It is the most damaging, because it hits many visitors without requiring a new click.
- DOM-based XSS The attack happens entirely in the victim's browser: code from the site itself processes input unsafely and triggers the script without it ever passing through the server. It is harder to spot from the outside.
What is at stake for the business
XSS matters because it flips the trust relationship: it is the company's own site, the one the customer trusts, that delivers the blow. A well-placed script hijacks the logged-in user's session (taking over their account), steals form data, or redirects to a fake page, all under the brand's name and appearance. The harm is not only technical: it is the customer trust and reputation that hold the business up, not to mention the exposure of personal data and the average US$ 4.44 million cost per breach worldwide (IBM, 2025). That is why XSS belongs to Injection, the third largest risk category in the OWASP Top 10, and is treated with the same rigor as a flaw that opens the customer's door.
How to protect against cross-site scripting
Defense against XSS starts from a simple rule: the site can never repeat, as if it were code, text that came from outside. That is ensured with layers of discipline in development:
- Encode the outputThis is the core fix. Before displaying any content from a user, the site converts it to plain text, so a script appears as letters on screen and is not executed. It treats data as data, never as a command.
- Validate and handle the inputCheck and clean what users submit, rejecting content with markup and commands where only text is expected. It is the layer that complements output encoding.
- Adopt a Content Security Policy (CSP)The CSP tells the browser which scripts are allowed to run on that site. Even if an XSS gets through, it reduces what the script can do, acting as an additional lock.
- Add a web application firewall (WAF)The WAF filters the application's traffic and blocks known XSS patterns before they reach the user. It is an extra layer, not a substitute for fixing the code.
- Test continuouslyAutomated scanning and penetration testing find the vulnerable echo points before the attacker does. XSS leaves the site when it is looked for on purpose, field by field.
In practice
In XSS, what attacks your customer is your own site. That is why the defense is not to distrust the visitor, but to never let the site repeat, as if it were its own, text that came from outside. The most innocent comment field, shown without handling, is enough to turn trust in the brand into an attack vector.
How Zamak protects against XSS
Zamak Technologies protects the trust relationship that XSS exploits, working alongside your development team, not in its place: it tests applications for the vulnerable echo points, points to the fix at the source (output encoding, input validation, Content Security Policy) and reinforces the environment with a web application firewall layer. Instead of discovering the flaw when a customer gets hit, your company finds and closes it first. It is part of managed Cybersecurity in the Zamak Method, and a good starting point is the cybersecurity diagnostic.