client-side-pentest

name

client-side-pentest

description

Perform a thorough client-side / browser-facing security assessment of a target web application. Use this skill whenever the user asks to pentest, audit, or review the security of a website or web app from the browser/frontend perspective, mentions client-side vulnerabilities (XSS, CORS, open redirect, clickjacking, prototype pollution, JWT leakage, source maps, etc.), wants to find sensitive data exposed in JavaScript bundles or client code, or asks for a security report on front-end attack surface. Trigger even if the user just says "test the security of this site", "find vulnerabilities in this web app", or "run a pentest on the frontend".

Client-Side / Front-End Security Assessment

A skill for conducting thorough, non-destructive client-side security reviews of web applications, producing a structured Markdown report covering all major browser-facing attack surface categories.

---

Setup: Fill in Before Starting

Before executing, confirm these values with the user if not already provided:

Variable	Description
TARGET	Primary target URL
LOGIN	Login URL or credentials (if authenticated testing is in scope)
CRED_AREAS	Credential areas needing extra attention
TOOLS_DIR	Path to any custom tools folder
SCOPE	Client-side and front-end only (unless user explicitly extends)

---

Authorization & Safety Constraints

• This assessment is authorized by the asset owner
• Non-destructive only — no DoS, brute force, spam, mass account creation, credential attacks
• Keep request volume moderate; avoid noisy scans unless the user explicitly approves
• Prefer passive analysis first, then low-risk validation
• Only attempt proof-of-concept when necessary to confirm a finding
• Never exceed the defined scope without explicit user approval

---

Mission

Identify the following across the client-side attack surface:

1. Vulnerable / outdated client-side dependencies (JS libraries, third-party scripts)
2. Sensitive information exposed in client-side assets (keys, tokens, internal endpoints, configs, source maps)
3. Client-side vulnerabilities — see full checklist below

---

Vulnerability Checklist

Cover all of the following (mark each as Confirmed / Likely / Informational / False Positive):

Injection & Scripting

• Reflected XSS
• Stored XSS
• DOM-based XSS
• Mutation XSS (mXSS)
• Client-Side Template Injection (CSTI)
• HTML Injection
• CSS Injection
• Dangling markup injection
• Unsafe use of innerHTML, outerHTML, document.write
• Unsafe eval / dynamic code execution

Redirects & Framing

• Open redirect
• DOM-based open redirect
• Reverse tabnabbing / window.opener abuse
• Clickjacking / UI redressing
• Unsafe iframe embedding
• Weak iframe sandboxing
• Form action hijacking

Cross-Origin & Trust

• CORS misconfiguration
• postMessage flaws (origin validation)
• Cross-site WebSocket hijacking
• Missing Subresource Integrity (SRI) on third-party scripts
• Unsafe third-party script trust

Caching & Service Workers

• Web cache deception
• Web cache poisoning
• Service worker abuse / misconfiguration
• Offline cache poisoning

Data Exposure

• JWT / token leakage in localStorage / sessionStorage / cookies
• Sensitive data in JS bundles or source
• Source map exposure (.map files reachable)
• Hardcoded secrets / API keys in frontend code
• Stack traces or debug data visible to client
• Hidden admin functionality / feature flags exposed

Client-Side Logic & Manipulation

• Client-side authorization bypass
• Business logic manipulation in browser
• Parameter tampering
• Hidden field manipulation
• Client-side prototype pollution
• Insecure client-side deserialization
• Client-side path traversal
• DOM clobbering

Browser & Misc

• CSRF risk from frontend request patterns
• Mixed content
• MIME sniffing / content-type confusion
• Referer leakage
• Browser history leakage
• Autofill abuse / credential leakage
• Clipboard abuse
• File upload client-side validation bypass
• XS-Leaks
• LocalStorage / SessionStorage abuse
• Vulnerable third-party JavaScript libraries (CVE-matched)

---

Methodology (Execute in Order)

Phase 1 — Reconnaissance & Asset Enumeration

• Crawl target: enumerate pages, scripts, endpoints, static assets
• Identify JS bundles, source maps (.map), manifests, service workers, web workers
• Enumerate first-party and third-party JS resources (CDN scripts, analytics, tag managers)
• Check storage usage: localStorage, sessionStorage, IndexedDB, cookies
• Identify public config artifacts: robots.txt, sitemap.xml, .well-known/*, manifest.json
• Review HTTP response headers: CSP, CORS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS

Tools to use: curl, wget, browser DevTools, gau, waybackurls, hakrawler, katana, subfinder, httpx, nuclei, custom scripts in TOOLS_DIR, Chrome (manual review)

Phase 2 — Static Analysis

• Download and review all reachable JS bundles and source maps
• Search for: hardcoded keys, tokens, credentials, internal URLs, debug flags, feature flags
• Parse source maps to reconstruct original source where available
• Identify JS library names and versions; cross-reference against known CVEs (RetireJS, Snyk DB)
• Review HTML for: inline scripts, hidden fields, form actions, iframes, rel="noopener" presence
• Review CSP policy for bypasses (wildcards, unsafe-inline, unsafe-eval, missing directives)

Tools: retire.js, npm audit, semgrep, grep/ripgrep, browser DevTools Sources tab, js-beautify, source-map CLI

Phase 3 — Targeted Low-Risk Runtime Validation

• Open the target in Chrome; observe network requests, console errors, storage
• Test CORS by issuing cross-origin requests with crafted Origin headers
• Check postMessage handlers: send crafted messages with untrusted origins
• Test open redirect candidates with controlled payloads
• Test XSS candidates with non-alerting, non-destructive probes (e.g., unique string reflection)
• Inspect cookies: flags (HttpOnly, Secure, SameSite), scope, expiry
• Check service workers: scope, fetch event handlers, cache strategies
• Test iframe embedding from external origin

Phase 4 — Risk Confirmation (Only Where Needed)

• Construct minimal PoC to confirm exploitability where finding is likely but unconfirmed
• Do not automate or repeat; single manual validation only
• Document exact reproduction steps

---

JavaScript Library Review Format

For each identified library:

Field	Value
Library name
Detected version
File path / URL
Evidence
Known CVEs / issues
Assessment	Vulnerable / Outdated / OK
Security relevance

---

Running Log (Keep Updated Throughout)

Maintain a running log as you work:

[STEP] Description of action
[TOOL] Tool and command used
[OUTPUT] Key evidence or finding
[CONFIDENCE] High / Medium / Low

---

Output

Save the final report as:

client_side_pentest_report.md

in the current working directory.

---

Report Structure

# Client-Side Penetration Test Report

## Executive Summary
## Scope & Assumptions
## Methodology
## Asset Inventory (client-side relevant)
## JavaScript Library Inventory
## Sensitive Data Exposure Findings
## Vulnerability Findings
## Informational Observations
## False Positives Ruled Out
## Recommended Remediation
## Appendix (commands, URLs, raw evidence, notes)

Per-Finding Format

### [FINDING TITLE]

- **Severity**: Critical / High / Medium / Low / Informational
- **CWE**: CWE-XXXX — [name]
- **Affected asset(s)**:
- **Description**:
- **Evidence**:
- **Reproduction steps**:
- **Security impact**:
- **Likelihood / Confidence**: Confirmed / Likely / Informational / False Positive
- **Remediation**:
- **References**:

---

Execution Style

• Be systematic, concise, and technical
• Prefer high signal over noisy output
• Do not stop at the first issue — continue until all phases are complete
• Distinguish clearly between Confirmed, Likely, Informational, and False Positive findings
• Do not overstate severity; be skeptical and evidence-driven
• If a noisier step is needed (e.g., active scanning, fuzzing), pause and ask the user for approval with a clear explanation of what will be done and why