TL;DR: Cross-site scripting (XSS) is when an attacker gets their JavaScript to run on your website — usually through an input field, URL or comment that your site displays without cleaning it. That script then runs in your visitors' browsers, where it can steal sessions, capture keystrokes or deface the page. The fix is to escape user input and add a Content-Security-Policy. Scan your domain free to start checking your security posture.
How XSS works
Say your site shows a search term back to the user, or displays comments. If it inserts that text into the page without
sanitising it, an attacker can submit <script>…</script> instead of normal text. When the page
renders, the browser runs the attacker's script as if it were yours — with full access to your visitor's session on your
domain.
The three common types
- Reflected XSS — the malicious script is in a link/URL and bounces straight back in the response.
- Stored XSS — the script is saved (a comment, profile, review) and runs for everyone who views it. The most dangerous kind.
- DOM-based XSS — client-side JavaScript writes unsafe data into the page.
Why it's serious
Because the script runs on your real domain, it inherits your visitors' trust and their logged-in session. It can hijack accounts, steal data, redirect to phishing, or quietly inject content — all without touching your server's files.
How to prevent it
- Escape/encode output — never insert user input into a page without encoding it for its context.
- Validate input on the server, not just the browser.
- Add a Content-Security-Policy to restrict what scripts can run — a strong safety net if something slips through.
- Keep your CMS and plugins updated — many XSS holes come from outdated components.
How Kalenfy helps
XSS lives in your code, so it's not something a passive DNS scan detects — but your free scan flags the posture around it (missing CSP, outdated CMS, exposed surfaces). And because we're developers, if you'd like the underlying code audited and fixed, just reply to your report.
FAQ
Can a CSP alone stop XSS?
It's a strong mitigation, not a complete fix. Combine it with proper output encoding and input validation.
Does XSS affect static sites?
Less so, but any place that reflects user input (search, forms, third-party widgets) can be vulnerable.
Is XSS the same as SQL injection?
No — XSS targets the browser/visitor; SQL injection targets your database. Both come from trusting unsanitised input.
Worried your site might be vulnerable? Scan your domain, then reply to your report — we're developers and we'll audit and harden the code for you.