| 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:
- Vulnerable / outdated client-side dependencies (JS libraries, third-party scripts)
- Sensitive information exposed in client-side assets (keys, tokens, internal endpoints, configs, source maps)
- Client-side vulnerabilities — see full checklist below
Vulnerability Checklist
Cover all of the following (mark each as Confirmed / Likely / Informational / False Positive):
Injection & Scripting
Redirects & Framing
Cross-Origin & Trust
Caching & Service Workers
Data Exposure
Client-Side Logic & Manipulation
Browser & Misc
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
