Test Web Apps for XSS and HTML Injection Vulnerabilities
Authorized XSS/HTML injection testing: stored/reflected/DOM detection, exploitation, filter bypass, and CSP evasion.
Why it matters
Identify and exploit Cross-Site Scripting (XSS) and HTML Injection vulnerabilities in web applications. This skill systematically detects flaws across stored, reflected, and DOM-based attack vectors to validate security controls.
Outcomes
What it gets done
Detect XSS and HTML injection flaws in user input fields.
Demonstrate exploitation techniques for session hijacking and credential theft.
Validate input sanitization and output encoding mechanisms.
Provide remediation recommendations, including CSP configurations.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-xss-html-injection | bash Overview
Cross-Site Scripting and HTML Injection Testing
Authorized XSS and HTML injection testing: detection and exploitation across stored/reflected/DOM vectors, filter bypass techniques, and CSP evasion, with severity-classified reporting and remediation guidance. Use for authorized security assessments of client-side injection vulnerabilities only, with written authorization and defined scope; not for unauthorized testing.
What it does
This skill, explicitly scoped to authorized security assessments, defensive validation, or controlled educational environments, covers comprehensive client-side injection testing across stored, reflected, and DOM-based XSS plus HTML injection. Detection starts by identifying input reflection points (search boxes, profile fields, URL fragments, error messages, HTTP headers) and running basic test strings (<script>alert('XSS')</script>, ``, SVG/body event handlers) while watching for raw or partial HTML encoding and DOM modifications. It distinguishes the three XSS types by their persistence signature - stored (persists after refresh, visible to other users), reflected (appears only in the current response, requires a crafted URL), and DOM-based (processed entirely client-side, payload never appears in the server response).
For each type it documents exploitation patterns: stored XSS payloads for cookie theft, keylogging, session hijacking via fetch(), and phishing form injection into comment sections/profiles/reviews/messages; reflected XSS delivered via crafted URLs (raw, URL-encoded, or attribute-breaking) through phishing emails, social media, URL shorteners, or QR codes; DOM-based XSS by identifying dangerous sinks (innerHTML, document.write(), eval(), location.href) and controllable sources (location.hash, postMessage, localStorage), including a cross-frame postMessage exploitation example; and pure HTML injection with no JavaScript for content defacement, form hijacking, CSS-based data exfiltration via attribute selectors, and iframe overlay phishing. A dedicated filter-bypass section covers tag/attribute case variation and alternative tags (<svg/onload=>, <details/ontoggle=>), HTML entity/hex/Unicode encoding, JavaScript obfuscation (string concatenation, template literals, atob()-encoded payloads, parenthesis-free execution), and whitespace/comment insertion tricks - plus a worked example bypassing a CSP that whitelists a trusted CDN by finding a JSONP callback endpoint on that same domain.
When to use - and when NOT to
Use this skill for authorized testing of client-side injection vulnerabilities - detecting and demonstrating stored/reflected/DOM XSS and HTML injection, validating input sanitization and output encoding, and producing a severity-classified vulnerability report with remediation recommendations including CSP configuration.
Its legal and ethical constraints are explicit: written authorization is required before testing, cookie/session capture is limited to demonstration purposes only, payloads must never risk worm-like spread to unintended users or exfiltrate real user data beyond scope, and any critical findings must be reported immediately. It is not for unauthorized testing or using discovered vulnerabilities for actual unauthorized access.
Inputs and outputs
Input is an authorized web application target with user input fields to assess. Output is an XSS/HTML injection vulnerability report with severity classifications, proof-of-concept payloads demonstrating real impact, controlled-environment session hijacking demonstrations, and remediation recommendations - illustrated with four worked examples covering stored XSS in a comment section, reflected XSS via a search parameter, DOM-based XSS via a hash fragment, and CSP bypass via a whitelisted JSONP endpoint.
Integrations
Uses Burp Suite or browser developer tools for request analysis and the browser JavaScript console for payload verification, targeting standard web application input surfaces (forms, URL parameters, headers, DOM sinks/sources) and testing against defenses like Content Security Policy, HttpOnly cookies, and SameSite cookie attributes.
Who it's for
Authorized penetration testers and security researchers validating client-side injection defenses in web applications who need concrete detection, exploitation, and filter-bypass techniques across all three XSS types plus HTML injection.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.