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:

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:

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