js-analyze

Files (3)

• SKILL.md
• openai.yaml · agents/
• shakerscan.md · references/

SKILL.md (first lines)

# JS Analyze

Use this skill to turn ShakerScan evidence and raw JavaScript assets into a reusable frontend attack-surface map.

## Operating Stance

Work evidence-first. Search thoroughly, but do not assume a route, secret-like string, dependency,
or code pattern is exploitable. If the checklist is complete without proof, report the strongest
leads and coverage gaps explicitly.

## Mandatory Checklist

Maintain this checklist in markdown while you work. Do not move on to synthesis or a final answer until every item is `[x]` or `[n/a]` with a short reason.

- [ ] Load existing ShakerScan scan context or explicitly note it is unavailable
- [ ] Load any provided JS assets, bundle URLs, or local files, or mark them unavailable
- [ ] Extract or verify routes, API endpoints, API bases, GraphQL operations, or WebSocket endpoints
- [ ] Review framework, library, and version evidence
- [ ] Review secret or sensitive metadata evidence
- [ ] Build a validated `custom_endpoints` block for ShakerScan or explain why none can be built
- [ ] Build a small `custom_list` block if the JS analysis yields content-discovery seeds
- [ ] Record confidence limits, missing auth, missing source maps, or other blockers

## Gather Inputs

Collect inputs in this order:

1. A completed `scan_id`, if the user provides one.
2. A target URL or domain, then look for the most recent completed scan for that target.
3. Any JS bundle URLs, local JS files, or source-map URLs the user provides.
4. Existing findings or session notes if they help explain a route or auth flow.

If there is no useful scan context, ask whether to queue the canonical Scan with a `balanced` or
`thorough` budget. Keep active testing off unless the user separately confirms ownership or explicit
authorization and asks for active probes.

## Read When Needed

- Read `references/shakerscan.md` for the exact result fields, API calls, and output contract.
- Read `skills/shakerscan/SKILL.md` for general scan safety and handoff rules.
- Read `AGENTS.md` when you need exact details for `custom_endpoints`, `focus_rules_json`, or authenticated scans.

## Workflow

1. Prefer ShakerScan-native evidence first:
   - `result.discovery.browser_api_endpoints`
   - `result.discovery.tech.items`
   - `result.discovery.browser_crawl`
   - `result.smart_coverage`
   - `result.js_dependencies`
   - `result.js_secrets`
2. If JS files or bundle URLs are available, extract:
   - routes and hash routes
   - API paths and API base URLs
   - GraphQL operations
   - WebSocket endpoints
   - auth, admin, debug, config, upload, import/export, and internal path hints
   - framework and library version hints
   - secret candidates and exposed metadata
3. Build evidence-backed candidates for:
   - `custom_endpoints`
   - API-only validation targets
   - focused content-discovery seeds
4. Note what is missing:
   - auth context
   - source maps
   - unobfuscated code
   - request/response pairs for parameter inference

## Output

Always return:

1. A concise markdown report with:
   - routes and APIs
   - parameter and auth hints
   - libraries and framework versions
   - secrets or sensitive metadata
   - confidence and gaps
2. A machine-usable `custom_endpoints` block for deterministic Scan route seeding.
3. A ready `curl` example for `/scans` using those `custom_endpoints`.
4. If the output contains path-like strings suitable for directory or file fuzzing, include a short `custom_list` block for the content-discovery skill.

## Rules

- Do not claim exploitability from strings alone.
- Do not invent parameters that are not implied by a path, spec, request body schema, or captured network traffic.
- Treat comments, source-map hints, and minified symbol matches as lower-confidence evidence.
- If the analysis depends on a weak signal, say so explicitly.
- Do not move on until the checklist is complete.

From andriyze/shakerscan, AGPL-3.0.

More from andriyze/shakerscan