What Is Cross-Site Scripting (XSS) and How Do You Prevent It?

A user signs in to your web application. The page looks normal. Behind it, a script you never wrote runs inside their browser and ships their session cookie to an attacker. The user sees nothing wrong. This is cross-site scripting, one of the oldest web flaws still ranked among the most common weaknesses in modern applications. If your site takes input from users and shows it back, you own this risk today.

Cross-site scripting, shortened to XSS, lets an attacker inject malicious code into a web page other people view. The browser trusts the page and runs the code as if your site sent it. The attacker steals session tokens, captures keystrokes, rewrites the page, or sends your users to a fake login. The flaw sits in your application, but your users pay the price. The Canadian Centre for Cyber Security lists cross-site scripting as a core way attackers inject code into websites and reach sensitive data, in its guidance on website defacement.

How cross-site scripting works

XSS happens when your application accepts input from a user and returns it to a browser without cleaning it first. Picture a comment box, a search field, or a profile name. A normal user types text. An attacker types a script. If your page prints the input straight back into the HTML, the browser reads the script as code and runs it. Every visitor who loads the poisoned page runs the attacker’s code inside their own session.

The three types you need to know

Security teams sort XSS into three forms. Stored XSS plants the malicious script in your database, so the server serves it to every visitor who opens the affected page. This form does the most damage because it hits everyone. Reflected XSS rides inside a malicious link or request, and the script fires when the victim clicks. Attackers spread these links through email and messages. DOM-based XSS lives entirely in the browser, where client-side code writes untrusted input into the page with no round trip to the server. Each form ends the same way, with attacker code running where your users trust your site.

Why attackers reach for XSS

The payoff is access to the user, not the server. With a working script, an attacker hijacks a logged-in session and acts as the victim. On an admin account, the reach grows fast. The attacker reads data, changes records, or seeds more malicious code. Canadian organizations already carry a heavy price when web attacks succeed. The 2026 IBM Cost of a Data Breach Report put the average Canadian breach at a record 7.11 million dollars, with a lifecycle of 205 days from intrusion to containment. A single injection flaw in a customer-facing application opens the door to this kind of loss.

How you prevent cross-site scripting

You stop XSS by treating every piece of user input as untrusted. The main defence is output encoding. Before your application prints user input into a page, encode it so the browser reads it as plain text, never as code. Encode for the exact context, whether HTML body, an attribute, JavaScript, or a URL. The Canadian Centre for Cyber Security names output encoding as a direct control against cross-site scripting in its secure development guidance. Input validation adds a second layer. Reject input shaped wrong for its field, and allow only known-good characters wherever you are able to.

Modern defences go further. A Content Security Policy tells the browser which scripts to trust, so an injected script from an unknown source fails to run. Set your session cookies as HttpOnly, so client-side script has no way to read them and session theft gets harder. Use vetted frameworks and libraries with built-in escaping, rather than building your own output handling from scratch. The OWASP Cross-Site Scripting Prevention guidance lays out the encoding rules in full and stays the reference developers return to.

Build the team who closes these gaps

Tools catch some flaws. Trained people design them out from the start. The Certified Secure Web Application Engineer path teaches developers to write code free of injection flaws, with output encoding and validation built into every feature. The Certified Web Security Engineer track widens this skill across the whole application stack. For the offensive side, the Certified Professional Ethical Hacker program shows your testers how attackers find and exploit XSS, so they spot it before a criminal does. The Certified Penetration Testing Engineer path takes this testing deeper, with hands-on labs against real web targets. Mile2 ties each course to a working role, so your team applies the skill the week they finish.

Cross-site scripting survives because web applications keep trusting input they should check. The fix is old and well understood. Encode your output, validate your input, lock down your cookies, and lean on a Content Security Policy. Then put trained developers and testers on the problem so the flaw never ships. Attackers scan Canadian web applications every day, looking for the one field you forgot to clean. Close the gap first, and their script has nowhere to run.