Defending Against Cross Site Scripting

Defending Against Cross Site Scripting#

Cross-Site Scripting (XSS) is one of the most common — and dangerous — web security flaws. At its core, XSS happens when untrusted content makes its way into a webpage without being properly handled, letting an attacker run malicious JavaScript in another user’s browser.

The good news? A handful of defensive habits stop most XSS dead in its tracks. Below is a practical XSS Defense Checklist that explains not only what to do, but why it matters.

1. Escape Output (Context-Aware)#

Escaping means converting potentially dangerous characters (<, >, ", ', &) into harmless equivalents before showing them in a web page. For example:

$name = "<script>alert(1)</script>";
echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8');

This would display literally <script>alert(1)</script> in the browser instead of executing it.

But here’s the subtlety: context matters.

  • HTML body content: Use htmlspecialchars() in PHP or .textContent in JS.

  • HTML attributes: Make sure quotes are escaped.

  • JavaScript inline: Encode data as JSON, not raw text.

  • CSS/URLs: Encode values or, better, disallow dynamic injection entirely.

👉 The key lesson: Escape when outputting, not when inputting. Input sanitization alone can’t predict every possible context where data will appear.

2. Validate & Sanitize Input#

Validation asks: Is this data what I expect?

  • Last name → letters, spaces, hyphens only.

  • Email → valid email format.

Sanitization cleans unwanted bits, but it should never replace escaping. Think of it as a helpful filter, not the main defense.

3. Use Content Security Policy (CSP)#

A strong CSP header acts as a seatbelt:

Content-Security-Policy: default-src 'self'; script-src 'self'

Even if an attacker sneaks code in, CSP limits what can run. It’s not a substitute for escaping, but it reduces the blast radius of mistakes.

4. Don’t Trust JavaScript with HTML Injection#

Tempting but dangerous:

  • ❌ innerHTML

  • ❌ document.write()

  • ❌ $('.element').html()

Safer alternatives:

  • ✅ textContent

  • ✅ createElement

  • ✅ Framework auto-escaping (React, Vue, Angular).

5. Use Frameworks Safely#

Modern frameworks protect you — until you override them.

  • React’s dangerouslySetInnerHTML

  • Vue’s v-html

Both are escape hatches. Use them rarely, and only with fully trusted content.

6. Protect Your Forms#

While not directly XSS, CSRF tokens stop attackers from tricking users into submitting malicious forms. Since XSS and CSRF often appear together, defense in depth is key.

7. Encode on the Way Out#

Escaping at input time sounds convenient — but it’s fragile. What if the data is later used in a different context (HTML vs. JS)?

Encoding at output ensures the escape matches the context every time. It’s the difference between a one-size-fits-none approach and a tailored, future-proof defense.

8. Audit & Test#

No defense is perfect without testing. Use:

  • Automated tools: OWASP ZAP, Burp Suite.

  • Manual payloads:

    <script>alert(1)</script>
<img src=x onerror=alert(2)>
"><svg onload=alert(3)>

If any of these run, you’ve got work to do.

The Golden Rule#

Treat all user input as hostile. Escape it when you output it. Do that, and you’ll block 90% of XSS attempts before they ever start.

Escaping is your first line of defense. Validation, CSP, and safer coding practices are the reinforcements. Together, they form a layered security strategy that keeps both your applications and your users safe.

10/2025#

Contents