# Browser Inspection

> Inspect web applications: API endpoints, network traffic, frontend code, backend routes, and debugging techniques using browser tools and terminal.

- Skill: `crimsonblazezero/browser-inspection` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add crimsonblazezero/browser-inspection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/crimsonblazezero/browser-inspection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: crimsonblazezero (https://skillmd.com/u/crimsonblazezero)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/crimsonblazezero/browser-inspection

---


# Browser Inspection

Techniques for inspecting web applications: discovering API endpoints, reading frontend source, debugging network traffic, and analyzing backend behavior.

## What This Skill Covers

- Discovering API endpoints from frontend JavaScript
- Reading and parsing frontend source code to understand request formats
- Using terminal-based `curl` to test API endpoints directly
- Understanding browser tool limitations for network inspection
- Analyzing server responses and error messages

## Workflow

### Step 1: Discover the Application Structure

First, understand what the application is and what it does:

```bash
# Get the HTML to find script sources
curl -s http://TARGET_URL/ | grep -o 'src="[^"]*\.js"' | head -20
curl -s http://TARGET_URL/ | grep -o 'href="[^"]*"' | head -20
```

Look for:
- JavaScript files in `<script src="...">` tags
- CSS files for style clues
- Meta tags for description
- Page title and structure

### Step 2: Find API Endpoints

API endpoints are typically called from JavaScript. Search the frontend source:

```bash
# Search for fetch/axios calls in JS files
curl -s http://TARGET_URL/js/main.js | grep -oE '(fetch|axios)\([^)]*\)' | head -20

# Search for API route patterns
curl -s http://TARGET_URL/js/main.js | grep -oE '["\x27]/api/[^"\x27]+["\x27]' | sort -u

# Search for specific HTTP methods
curl -s http://TARGET_URL/js/main.js | grep -E '(POST|GET|PUT|DELETE|PATCH)' | head -20
```

Common patterns:
- `fetch('/api/endpoint', { method: 'POST', ... })`
- `axios.post('/api/endpoint', data)`
- `$.ajax({ url: '/api/endpoint', ... })`

### Step 3: Understand Request Format

Once you find API calls, extract the full request body structure:

```bash
# Get the full function that makes the API call
curl -s http://TARGET_URL/js/main.js | grep -B 5 -A 30 'fetch.*\/api\/generate'
```

Look for:
- Request body structure (JSON fields)
- Headers being set
- Error handling patterns
- Response parsing

### Step 4: Test with curl

Use `curl` to test discovered endpoints directly:

```bash
# Basic test
curl -X POST http://TARGET_URL/api/endpoint \
  -H "Content-Type: application/json" \
  -d '{"field": "value"}' \
  -v

# With verbose output to see headers
curl -v http://TARGET_URL/api/endpoint

# Capture response headers for tech stack clues
curl -sI http://TARGET_URL/api/endpoint
```

### Step 5: Analyze Responses

Common response patterns:

**Success (200 OK):**
```json
{"imageBase64": "...", "mimeType": "image/png"}
```

**Validation error (400 Bad Request):**
```json
{"error": "Missing required field: prompt"}
```

**Server error (500 Internal Server Error):**
```json
{"error": "{\"error\":{\"code\":400,\"message\":\"API key not valid...\"}}"}
```

**Backend service error:** Often the 500 wraps an upstream error (e.g., Google AI API key invalid). Parse the nested JSON.

## Browser Tool Limitations

### What `browser_console()` CAN do:
- Show JavaScript console output (`console.log`, `console.error`, etc.)
- Detect uncaught exceptions and JS errors
- Execute JavaScript expressions in the page context
- Inject fetch/XHR interceptors (but output may not be captured reliably)

### What `browser_console()` CANNOT do:
- **Show Network tab data** — no passive HTTP request logging
- **Record all API calls** — you must inject interception code
- **Show response bodies** for requests you didn't intercept

### Reliable approach for API inspection:
1. **Terminal-first:** Use `curl` to directly test suspected endpoints
2. **Frontend analysis:** Read JS source to understand request formats
3. **Browser as supplement:** Use `browser_console()` for JS errors and DOM state, not for network traffic

## Common Pitfalls

- **Empty page snapshots after interaction** — the browser tool sometimes returns `(empty page)` after clicks or type. Re-navigate or use `browser_snapshot(full=true)`.
- **Disabled buttons block API calls** — many apps have validation guards. Check for `disabled` attributes or alert dialogs before assuming the API is broken.
- **Nested error responses** — a 500 from the app server often wraps an upstream service error. Always parse the inner JSON to find the real issue.
- **API key errors masquerading as 500** — an internal server error with a message about "API key not valid" means the backend's third-party API key is expired/invalid, not that your request is wrong.
- **CORS issues** — if testing from `curl`, CORS headers won't block the request (curl isn't a browser). But the app's frontend may still fail due to CORS. Check `Access-Control-Allow-Origin` headers.

## Tech Stack Detection

Identify the backend framework from response headers:

| Header | Framework |
|--------|-----------|
| `X-Powered-By: Express` | Node.js / Express |
| `X-Powered-By: Next.js` | Next.js |
| `Server: nginx` | Nginx reverse proxy |
| `X-AspNet-Version` | ASP.NET |
| `X-Generator` | Various CMS/frameworks |

## Reference Files

See `references/api-inspection-checklist.md` for a condensed quick-reference checklist.