What Is XSS (Cross-Site Scripting)?

Relax. We'll talk through this in plain words — no textbook voice.

What you'll walk away with

Understand what XSS (Cross-Site Scripting) is, no intimidation required
Apply this concept right away in real-world scenarios
Learn to avoid security risks for yourself and others

Let's think about it this way for a second

Stored XSS — the attacker's script gets saved in the database and runs for every visitor who views the page (e.g., a comment section). Reflected XSS — the moment a victim clicks a malicious link, the script embedded in the URL parameter runs immediately. Once the script runs, it can steal the victim's cookies/session tokens and let the attacker access their account while impersonating them.

Let's connect this to a real-world scenario

If you type <script>alert('hacked')</script> into a comment box and it renders on the page as raw HTML, that tells you an XSS vulnerability exists (testing with a harmless alert box). Defenses include output encoding (escaping user input into HTML entities before displaying it on the page — turning <script> into <script>) and setting a Content Security Policy (CSP) header, which restricts what scripts are allowed to run.

Be able to tell Stored XSS apart from Reflected XSS
Understand what output encoding is
Know the role of Content Security Policy (CSP)

Let's look at it together

html

<!-- Vulnerable: user input rendered as raw HTML -->
<div>Comment: <script>alert('hacked')</script></div>

<!-- Safe: output-encoded -->
<div>Comment: &lt;script&gt;alert('hacked')&lt;/script&gt;</div>
<!-- Browser displays the text literally instead of running it -->

You should see

Be able to explain how an XSS payload runs and how output encoding defends against it.

Try it in 5 minutes

On a website with a comment/feedback form (one you're authorized to test, or an intentionally vulnerable practice site), describe at a conceptual level how you'd test a harmless <script>alert(1)</script> payload (never actually try this on a production site).

A quick word of caution

'Testing' an XSS payload on a website you don't have permission to test can be a legal offense — only practice on your own test environment or on a site that explicitly allows it through a bug bounty program.

Easy traps

Confusing XSS with SQL Injection — SQLi targets the database, while XSS targets the browser/user
Relying on client-side JavaScript validation alone as an XSS defense

Now try it yourself

You'll know it worked when: Be able to explain how an XSS payload runs and how output encoding defends against it.