XSS (Cross-Site Scripting) Source

• HTTP parameters or form fields containing <script>, javascript:, onerror=, onload= or event handler patterns
• Base64-encoded payloads in query parameters that decode to JavaScript execution strings
• Requests injecting <img src=x onerror=...> or SVG-based event handler payloads
• Attempts to access document.cookie or window.location via injected script context
• Automated scanner signatures (OWASP ZAP, Burp Active Scanner) probing XSS vectors

Detect XSS patterns in web server logs

# Grep for common XSS probe patterns
grep -Ei "(<script|javascript:|onerror=|onload=|%3Cscript|%6A%61%76%61%73%63%72%69%70%74)" \
  /var/log/nginx/access.log | awk '{print $1, $7}' | head -20

Content Security Policy (CSP) violation reports

# Nginx — set CSP with report-uri to collect violations
add_header Content-Security-Policy \
  "default-src 'self'; script-src 'self'; report-uri /csp-report;" always;

# Django view to log CSP violations
import json, logging
from django.views.decorators.csrf import csrf_exempt
from django.http import HttpResponse

@csrf_exempt
def csp_report(request):
    if request.method == "POST":
        report = json.loads(request.body)
        logging.warning("CSP violation: %s", report)
    return HttpResponse(status=204)

ModSecurity WAF (OWASP CRS XSS rules)

# OWASP CRS Rule IDs 941xxx cover XSS
# 941100: XSS Attack Detected via libinjection
# 941110: XSS Filter - Category 1 (Script Tag Vector)
# 941130: XSS Filter - Category 3 (Event Handler Vector)
SecRuleEngine On

Suricata HTTP rule

alert http any any -> $HTTP_SERVERS any \
  (msg:"XSS attempt detected"; \
   pcre:"/<script[\s>]/Ui"; http_client_body; sid:4000002;)

1. Implement Content Security Policy (CSP) — A strict CSP header (script-src 'self') prevents injected scripts from executing even if XSS is present. Start with report-only mode, then enforce.
2. Encode all output — HTML-encode user-supplied data before rendering it in templates. Use framework auto-escaping (Django templates, Jinja2, React JSX) — never disable it.
3. Use HttpOnly and Secure cookie flags — Set-Cookie: session=...; HttpOnly; Secure; SameSite=Strict prevents JavaScript from accessing session cookies even in a successful XSS attack.
4. Validate and sanitise inputs — Reject unexpected HTML tags server-side; use a whitelist-based HTML sanitiser (bleach, DOMPurify) for content that must allow markup.
5. Deploy a WAF with XSS rulesets — OWASP ModSecurity CRS 941xxx rules block the most common XSS payloads at the perimeter.
6. Enable Trusted Types API — Modern browsers support Trusted Types (require-trusted-types-for 'script') to enforce that all DOM sink assignments go through a sanitiser.
7. Set X-XSS-Protection: 0 — Disable the legacy browser XSS auditor (it causes false positives and bypass issues); rely on CSP instead.
8. Conduct regular DAST and code review — Run Burp Suite Active Scan or OWASP ZAP against staging; review all template rendering of user-supplied data.

2005 — MySpace Samy worm (first XSS worm): On October 4, 2005, Samy Kamkar deployed a stored XSS payload on his MySpace profile that added him as a friend and copied itself to every visitor's profile. Within 20 hours, over one million MySpace accounts were infected, making it the fastest-spreading computer worm in history. MySpace was taken offline to contain the attack.

2010 — Apache.org stored XSS breach: Attackers used a stored XSS vulnerability in Apache's JIRA issue tracker to steal administrator session cookies, gaining access to commit infrastructure. The breach allowed potential modification of Apache software source code, though no tampering was confirmed. This incident highlighted the risk of XSS in internal developer tooling.