---
name: network-request-auditing
description: After navigating and interacting in Cursor's built-in browser, use browser_network_requests to audit every fetch/XHR for failures, slowness, duplicate calls, and suspicious payloads. Use for API-heavy pages and after backend or client networking changes.
user-invocable: true
---

# Network Request Auditing

Deep-dive **network** health using the `cursor-ide-browser` MCP. This skill focuses on `browser_network_requests` — not just “any 500s” but patterns that indicate bugs, waste, or security issues.

## How it works

1. Drive the app in the browser (navigate, click, submit forms) so real requests fire.
2. Call **`browser_network_requests`** after meaningful interactions (and after navigation settles).
3. Classify and report findings using the criteria below.

Follow `cursor-ide-browser` workflow rules: use `browser_snapshot` before structural interactions; after actions that change the page, take a fresh snapshot before the next interaction.

## Audit checklist

### Failures

- **4xx / 5xx** — list method, URL (path + query), status, and whether the UI handled the error.
- **CORS or network errors** — often misconfigured origins or mixed content.

### Performance

- **Slow requests** — flag requests with high latency (e.g. > 500 ms server time if timings are visible; otherwise note unusually large waterfalls).
- **Duplicate calls** — same URL + method fired multiple times in one user action (often a React effect or missing deduplication).
- **Oversized payloads** — responses that look huge for what the UI needs (suggest pagination, field selection, or compression).

### Security and privacy

- **Sensitive data in URLs** — tokens or PII in query strings.
- **Missing auth** — API calls that should send credentials or bearer tokens but do not (compare with adjacent authenticated calls).

### Correctness

- **Unexpected hosts** — calls to third parties not documented for the feature (trackers, accidental leaks).
- **Preflight storms** — excessive OPTIONS requests may indicate wrong CORS caching or too many distinct origins.

## Steps

1. **Start from a clean navigation** — `browser_navigate` to the target URL (or use an existing tab via `browser_tabs`).

2. **Exercise the feature** — interactions that trigger API usage (filters, infinite scroll, form save, modal open).

3. **Fetch network log** — `browser_network_requests` after each logical step if the page does multiple round-trips.

4. **Report** — structured output:
   - Summary counts (failed, slow, duplicate groups).
   - Table or bullet list of issues with **URL pattern** (not necessarily full secrets), **status**, **category** (failure / perf / security / correctness).
   - Recommended next code changes or investigations.

## Notes

- Iframe traffic may not appear in the same log — note if the feature runs inside an iframe.
- Compare against **expected** API design; a 404 might be correct for “optional resource not found” if handled in UI.
- Pair with `browser_console_messages` for errors that do not surface as failed HTTP (e.g. parse errors after 200).