Web Security Client-Side Scanner 1773654191

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...

Security Scan

The skill's instructions, requirements, and scope are consistent with a client-side/front-end pentest workflow; nothing requested is disproportionate or unrelated to that purpose.

Purpose & Capability

The skill is explicitly a client-side/front-end security assessment and its checklist, methodology, and recommended tools align with that purpose (JS bundle analysis, source maps, CSP, storage, service workers, etc.). It does not claim unrelated capabilities (e.g., full cloud administration) and declares no environment or credential requirements up front.

Instruction Scope

Instructions are prescriptive and mostly limited to passive/low-risk client-side analysis. However, the guidance references active reconnaissance tools (subfinder, httpx, nuclei, waybackurls, etc.) that can broaden scope and perform more intrusive checks; the SKILL.md does state 'confirm scope' and 'non-destructive only', but an operator should explicitly approve any subdomain discovery or active scanning before use.

Install Mechanism

Instruction-only skill with no install spec and no code files — minimal risk from install mechanisms. The skill assumes external tools exist in the environment (TOOLS_DIR or PATH) but does not attempt to fetch or run installers itself.

Credentials

The skill declares no required environment variables or credentials. It does ask the operator to confirm TARGET and optional LOGIN credentials if authenticated testing is in scope, which is reasonable and proportional for a pentest. There is no unexplained request for unrelated secrets.

Persistence & Privilege

always is false and the skill does not request persistent or elevated agent privileges. It does not modify other skills or system-wide settings in the instructions provided.

Assessment

This skill appears coherent for front-end pentesting, but before installing or running it: 1) obtain explicit, written authorization from the asset owner and confirm the exact scope (which subdomains, paths, or accounts are allowed); 2) decide whether active tools (subdomain enumeration, httpx, nuclei templates) are permitted — these can be more intrusive than pure client-side inspection; 3) avoid sharing high-privilege credentials — if authenticated testing is needed, prefer scoped or test accounts and short-lived credentials; 4) confirm the runtime environment will contain the listed tools (or provide an approved TOOLS_DIR) because the skill assumes external CLI tools will be executed; and 5) plan for safe handling of any secrets or sensitive data discovered in client assets (do not exfiltrate them to external services). If you want, I can produce a shorter checklist of the exact commands and tools the skill will run so you can approve them one-by-one.

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