iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

XSS Testing

By · Reviewed & last updated · Part of Ethical Hacking Tutorial

Testing for XSS during an authorised engagement starts with the rules of engagement (RoE): what hosts are in scope, what payload classes you may use, and what your stop conditions are. Inside that envelope you confirm the vulnerability with the minimum effective payload, document, and stop. No data exfiltration, no chained pivots, no second-stage tooling.

A minimal authorised XSS test workflow

EXAMPLE
# Rules of Engagement (excerpt — agreed in writing before testing)
# - In scope: https://demo.example.test (staging mirror, no production data)
# - Window: 2026-06-11 09:00-17:00 AEST
# - Payload classes allowed: reflected & DOM XSS PoC only
# - PROHIBITED: stealing session cookies, keylogging, credential capture,
#   pivoting to other hosts, any payload that touches a real user.
# - PoC must use alert(1) or a controlled webhook you own (e.g. canary domain).
# - Stop conditions: any 5xx burst, any incident-channel page, RoE end time.
# - Reporting: one consolidated report within 5 business days.

# Step 1 -- map injection points (manual review of the app's input surface)
#   Forms, query params, headers reflected into the page, postMessage receivers.

# Step 2 -- probe with a benign canary string to see where input lands
curl -s 'https://demo.example.test/search?q=ZZcanaryZZ' | grep -n ZZcanaryZZ
#   If 'ZZcanaryZZ' appears inside a script block, attribute, or HTML body,
#   note the context -- the right payload depends on the context.

# Step 3 -- confirm with the minimum payload for the context
# HTML body context: <svg/onload=alert(1)>
# Attribute context: " autofocus onfocus=alert(1) x="
# JS string context: ';alert(1);//
#   Use alert(1) -- not document.cookie, not fetch() to an attacker host.

# Step 4 -- record the finding
# - URL with parameter, request method, headers
# - Exact payload and screenshot of the alert dialog
# - Reproduction steps a non-tester can follow
# - Suggested fix: context-aware output encoding + CSP

# Step 5 -- stop. Do not chain. Do not test other findings from this foothold.

# Example PoC submission entry (Markdown)
cat <<'EOF'
## Finding: Reflected XSS in /search?q
**Severity:** High (auth not required; affects all visitors)
**URL:** https://demo.example.test/search?q=<svg/onload=alert(1)>
**Steps:** Open URL in a fresh browser session. Alert dialog 1 displays.
**Fix:** htmlspecialchars($q, ENT_QUOTES|ENT_HTML5, 'UTF-8') in
       resources/views/search.blade.php; add strict CSP with nonce.
EOF

Why it matters

A clean PoC -- alert(1) and stop -- is what gets a finding triaged quickly. Demonstrating cookie theft or session hijack on a staging system blurs the line with the malicious activity the RoE was meant to forbid and risks the whole engagement.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Use a benign canary on AUTHORISED targets:
#   <svg/onload=console.log('xss')> in inputs that re-render unsanitised.
# Don't actually steal cookies — the proof is rendering of attacker-controlled HTML.
# Defence: framework auto-escape + CSP + Trusted Types.
Try it Yourself »

Discussion

Loading…