New: CyberSafe CEO Dinis Fernandes keynoted on AI cybersecurity challenges at FutureCon Vancouver 2026.Read the article →

How XSS works

XSS occurs when an application includes untrusted input in a page without proper validation or encoding. In reflected XSS, the script arrives in a crafted link. In stored XSS, it is saved, for example in a comment, and served to every viewer.

A third type, DOM-based XSS, arises from insecure client-side JavaScript. When the victim's browser executes the injected code, it appears to come from the trusted site, so browser protections do not block it. Modern single-page applications and third-party scripts expand the places where untrusted data can reach the browser, so each library and integration is a potential source of exposure.

Why it matters for Canadian organizations

XSS can let attackers hijack sessions, take over accounts, harvest personal information or deliver malware from a trusted domain. It appears consistently in lists of common web application risks such as the OWASP Top 10.

Customer portals and web forms handling personal information are exposed to PIPEDA and Law 25 consequences if abused. Flaws also erode customer trust, particularly for banking, healthcare and e-commerce sites. Impact depends on what the site does, but an XSS flaw on an administration page or a payment form is especially serious because the injected script runs with high-value privileges.

How to defend against it

Encode output according to its context (HTML, attribute, JavaScript or URL) and validate input on the server. Use frameworks that escape output by default, and avoid inserting raw user data into the DOM.

Add a strict Content Security Policy, set cookies with HttpOnly and Secure flags, and test with code review, scanning and penetration testing. A WAF can offer temporary protection but should not replace fixing the code. Include XSS cases in code review checklists and automated testing, and fix findings at the framework level where possible so a single change protects every page.

Frequently asked questions

What is the difference between XSS and SQL injection?

XSS injects scripts that run in other users' browsers, targeting site visitors. SQL injection injects database commands that run on the server, targeting stored data. Both stem from untrusted input being handled unsafely. Both are common web application flaws.

What are the types of XSS?

The three main types are reflected XSS, where the payload comes from the request; stored XSS, where it is saved on the server and shown to others; and DOM-based XSS, where client-side code processes untrusted data unsafely.

Can a WAF prevent XSS?

A WAF can block many common XSS payloads and offer virtual patching, but attackers can sometimes bypass filters. The reliable fix is output encoding, input validation and a Content Security Policy in the application itself. Defense belongs in the application itself.

Related service: Application security

Need help with XSS?

CyberSafe's SOC, offensive security and consulting teams work with Canadian organizations on exactly these problems. Tell us what you are dealing with.

Talk to a specialist