Backdrop

A Chrome/Brave/Edge (Manifest V3) extension that logs every outbound request a page makes to third parties (fetch, XMLHttpRequest, WebSocket), and navigator.sendBeacon.

Click the toolbar icon for a terminal view of the log: verb, time, host + path, status/duration, query params, request and response headers, request body, and response body.

Why do this?

Backdrop is a fast, low-friction lens for traffic analysis during web assessments — recon and data-flow mapping without standing up a full intercepting proxy.

• Map the third-party attack surface. Every domain a page beacons to is another vendor in scope: analytics, tag managers, ad networks, chat/support SDKs, A/B tools. The 3rd-party toggle enumerates them live, so you see the real dependency graph — including the CDNs and subprocessors that inherit whatever the page hands them.
• Find data leaving the origin. The payloads are foregrounded, not just the URLs — so session tokens, emails, user IDs, full dataLayer dumps, and PII shipped to third parties surface immediately. Useful for spotting token leakage into Referer or analytics params, and for GDPR/consent-bypass findings ("fires before opt-in").
• Catch what a passing Network-tab scan misses. Requests hooked at the JS primitive level include dynamically-built, on-interaction, and delayed calls — the trackers that fire on scroll/click or seconds after load, easy to lose in a busy Network panel that also clears on navigation.
• Inspect WebSocket and beacon channels. Live chat, trading, telemetry, and sendBeacon exfil are opaque in most tooling. Backdrop logs every frame in/out and decodes binary payloads (protobuf, msgpack) to text or hex for protocol analysis.
• Fingerprint SDKs and endpoints quickly. Verbs, paths, and bodies make it easy to identify the vendor, its API version, and undocumented endpoints worth a closer look.

It complements a proxy rather than replacing one: reach for Burp/mitmproxy when you need to modify traffic or capture at the network layer; reach for Backdrop when you just want to see what the page's own JS is sending, decoded, in a couple of clicks.

Authorized use only. Point this at your own properties or targets you have written permission to test. Observing a page's outbound traffic in your own browser is passive, but acting on captured tokens, payloads, or endpoints against systems you don't own may be illegal. Stay within your engagement scope and rules of engagement.

How it works

• inject.js runs in the page's own JS world at document_start (before page scripts) and wraps fetch, XMLHttpRequest, WebSocket, and sendBeacon. Because it lives in the page context, it captures requests that scripts create dynamically at runtime, including their bodies and WebSocket payloads, which chrome.webRequest can't fully expose in MV3.

• bridge.js (isolated world) receives those events, classifies each as first- vs third-party (registrable-domain comparison), and forwards them to the service worker.

• background.js buffers per tab (cap 2000), runs detection (detect.js), shows a live third-party count on the badge (red when anything is flagged), clears on top-level navigation, and streams to the popup.

• detect.js (loaded into the service worker) scans each record for secrets/PII/leaks.

• popup.* is the terminal view. Live stream, 3rd-party / hide ws / ⚑ flagged toggles, text filter (matches URL + bodies + flags), click-to-expand detail, clear, copy-as-JSON, HAR export, and pop-out into a resizable standalone window.

Findings & analysis (web-app testing)

Every captured request is scanned — locally, in the service worker; nothing leaves your browser — and interesting rows are tagged inline and counted on the badge.

• Secret detection. JWTs, AWS/Google/Stripe/Slack/GitHub keys, Authorization: Bearer tokens, and PEM private keys appearing in an outbound URL, body, or header.
• PII detection. Emails, US SSNs, and Luhn-valid card numbers leaving the origin.
• Token-leakage cross-check. Token-like values seen in first-party traffic (auth headers, cookies, JWTs, tokenish params) are remembered per tab; if one later shows up in a third-party request it's flagged Token leaked to 3rd-party with the origin it came from — the classic "session token shipped to analytics" finding.
• Cleartext flag. Non-TLS http:// / ws:// outbound calls.

Expand any row for extras aimed at testing workflow:

• Response security-header audit — CSP (+ unsafe-inline/eval note), HSTS, nosniff, frame protection, Referrer-Policy, Permissions-Policy, pass/warn per header.
• JWT auto-decode — any JWT in the request is decoded (header + payload, with exp/iat and an EXPIRED marker).
• Value decoders — one-click base64 and URL-decode on the body/params.
• Copy as cURL — replay the request in Repeater / a terminal.

Export: the har button writes the visible HTTP log as a standard HAR file (loads into Burp, DevTools, Postman); WebSocket frames are excluded since HAR models HTTP. json copies the visible rows (flags included) for a report.

Binary payloads

WebSocket frames and request bodies that arrive as ArrayBuffer/typed-array/Blob are decoded: valid, mostly-printable UTF-8 is shown as text; otherwise a capped hex + ASCII dump (first 1 KB) so binary protocols (protobuf, msgpack...) are still inspectable.

Binary response bodies (images, fonts, audio/video, wasm, pdf, zip, protobuf) are detected by Content-Type and not captured — they'd only clog the terminal so you get a one-line [image/png · 34.5 KB — body not captured] summary instead.

Load it

1. Open chrome://extensions (or brave://extensions).
2. Enable Developer mode.
3. Load unpacked.
4. Browse to any site, then click the Backdrop icon. The badge shows the running third-party count; the popup shows the full log.

Notes / limits

• Third-party detection uses an approximate eTLD+1 (common two-level suffixes handled, not the full Public Suffix List). Extend TWO_LEVEL in bridge.js if needed.

• Request bodies are clipped to 8 KB, response bodies to 64 KB, binary hex dumps to 1 KB. fetch responses are read from a clone, so the page's own copy is never disturbed; text/event-stream (SSE) is not drained. Tune MAX_BODY/MAX_RESP/MAX_HEX and the BINARY_CTYPE regex in inject.js.

• Cross-origin no-cors (opaque) responses have no readable body by spec, so those show empty — the request itself is still logged.

• The security-header audit is most complete for first-party / same-origin responses. Cross-origin responses only expose CORS-safelisted headers to page JS, so some headers may read as "missing" when they're actually set — verify against a proxy for reporting.

• Detection is regex/heuristic and runs only on what the page sends (not response bodies). Expect false positives/negatives; treat flags as leads, not proof. Patterns live in detect.js.

• Requests made from cross-origin iframes with restrictive CSP may not be hooked if the frame blocks the content script; most standard pages are covered.

• Logs live in the service worker's memory and reset when the tab navigates or closes.