Web Stack Analyzer

Web Stack Analyzer

Analyze a website's likely technology stack using passive, low-impact fingerprinting. Always report concrete evidence and confidence for each finding.

When to use this skill

Use this skill when the user asks to:

• Identify technologies used by a website or URL.
• Detect frontend frameworks, SSR/meta-frameworks, CMS/e-commerce platforms, backend hints, web servers, CDNs, hosting providers, analytics, payments, auth, chat/support, monitoring, or security headers.
• Compare web technology detection approaches.
• Learn about passive web fingerprinting workflows.

Do not use this skill for vulnerability scanning, exploitation, credential attacks, intrusive crawling, or bypassing access controls.

Quick start

For most analyses, run the bundled site analyzer from this skill directory:

python scripts/analyze_site.py <URL> --markdown

For machine-readable output:

python scripts/analyze_site.py <URL> --json

Focused analyzers:

python scripts/analyze_headers.py <URL>
python scripts/analyze_html.py page.html --base-url <URL> --json

If browser rendering is required, use browser automation to inspect runtime globals and hydrated DOM markers, then combine that evidence with the script output.

LLM Agent Execution Protocol

When you are acting as an AI agent applying this skill:

1. Tool Usage: Use the run_in_terminal tool to run the Python scripts autonomously. Do not ask the user to run the commands manually.
2. Handle Output: Process the JSON or Markdown output directly. If output is large, redirect it to a file.
3. Dependencies: If python scripts/analyze_site.py fails due to missing packages, suggest or run pip install to setup the environment.

Core workflow

1. Normalize scope — normalize bare domains to HTTPS, record final URL, and stay within the supplied site unless the user asks otherwise.
2. Analyze headers — inspect status, redirects, server/edge headers, powered-by headers, cookies, protocol hints, and security headers.
3. Analyze HTML/resources — inspect scripts, links, meta tags, DOM markers, class tokens, CSS variables, iframes, and forms.
4. Check runtime only if needed — for client-rendered apps, inspect browser globals such as window.__NEXT_DATA__, window.__NUXT__, window.React, window.Vue, window.Shopify, window.dataLayer, and DOM properties like __reactFiber$.
5. Merge evidence — deduplicate technologies, combine evidence, and upgrade confidence only when there are independent corroborating signals.
6. Report caveats — mention spoofable headers, blocked requests, unavailable runtime checks, conflicts, and low-confidence findings.

For detailed operational steps, see reference/analysis-workflow.md.

Evidence and confidence requirements

Each reported technology should include:

• Technology
• Category
• Confidence: High, Medium, or Low
• Evidence: concrete header, cookie name, DOM marker, resource URL, global, path, class token, or security header
• Caveats when evidence is ambiguous or spoofable

Confidence rules:

• High — multiple strong independent signals, or one highly specific signal with corroboration.
• Medium — one strong signal or multiple weak signals.
• Low — a single weak/generic signal.

Never report a technology with no evidence.

False-positive controls

• A third-party script means the site uses that service; it does not necessarily identify the primary framework.
• Generic tokens such as next, app, vendor, main, bundle, and static are insufficient by themselves.
• Headers can be spoofed or generated by reverse proxies/CDNs.
• Next.js, Gatsby, and Remix imply React; Nuxt implies Vue; SvelteKit implies Svelte. Report the meta-framework as primary when present.
• Analytics, chat, payment, and monitoring scripts may be injected through tag managers.
• Cookie values should not be reported; cookie names are enough for stack detection.

Output format

Prefer this report shape:

## Tech Stack Analysis: <URL>

### Frontend
| Technology | Confidence | Evidence |
|-----------|------------|----------|

### Backend / Server
| Technology | Confidence | Evidence |
|-----------|------------|----------|

### CMS / E-Commerce
| Technology | Confidence | Evidence |
|-----------|------------|----------|

### CDN / Hosting
| Technology | Confidence | Evidence |
|-----------|------------|----------|

### SaaS / Third-party
| Technology | Confidence | Evidence |
|-----------|------------|----------|

### Security
| Feature | Status | Evidence |
|---------|--------|----------|

### Uncertainty / Caveats
- Note conflicts, blocked requests, spoofable headers, unavailable runtime checks, or low-confidence findings.

### Summary
Brief narrative of the likely stack.

References

• reference/analysis-workflow.md — detailed phase-by-phase workflow, evidence schema, runtime checks, and report outline.
• reference/detection-signatures.md — common detection signatures for frontend frameworks, meta-frameworks, CMS/e-commerce, CDN/hosting, analytics, SaaS, payments, security indicators, and build tools.
• scripts/ — executable analyzers and shared utilities.

Safety and privacy

• Keep requests minimal and bounded.
• Do not attempt login, form submission, access-control bypass, exploitation, or brute-force discovery.
• Avoid storing full HTML, headers, or cookies unless needed for reproducibility.
• Redact sensitive values; report cookie names, not cookie values.
• If browser automation is used, close the browser session after analysis.