10.1 How Websites and Apps Collect and Send Data
Three Lanes, One Browser
A modern page is a transmitter with several independent lanes. The oldest is the form POST: the browser serializes named fields into an urlencoded body, or into a multipart envelope when a file is attached, and ships the whole thing to the action URL. The second lane is scripted requests -- fetch and XHR -- which talk to an API instead of reloading the page. The third lane is passive: an img request for a one-by-one pixel whose only real payload is the querystring. Every lane carries cookies for its own destination domain, which is why the destination, not the request type, decides who gains identifying data.
Anatomy of an API Call
A typical JSON call is readable in the Network tab as header plus body. The request line names the method and path; headers declare Content-Type: application/json, the Origin and Referer that say which page triggered it, and an Authorization: Bearer header holding the access token when cookie auth is not used. The body is a flat or nested object of key and value pairs -- identifiers, free text, device metadata, feature flags. Anything a developer copies into that object leaves the device verbatim, so payload keys are the honest inventory of what an app collects; the OWASP Web Security Testing Guide and the OWASP API Security Top 10 both start their auditing advice by enumerating exactly these fields.
Pixels, Beacons, and Tag Managers
Analytics rarely uses one request per event. A tag manager loads vendor scripts, each buffer events in memory and flushing them in batches, often via sendBeacon on unload so the data survives the tab closing. Cross-page identifiers -- an ad ID plus your first-party session cookie -- are stitched server-side into a profile. Consent banners change which vendors load, not how the surviving ones behave, and a single embedded iframe can open its own reporting lane that never touches the site owner's infrastructure.
Auditing What Actually Leaves
Open DevTools, filter the Network log by domain rather than by type, and compare first-party hosts against everything else. For each third-party host read the payload keys, note whether a session or identity cookie rode along, and record retention or resale terms you can find. That short table -- host, method, payload keys, credential exposure -- is the artifact most "the site just works" opinions are missing.
Architecture Diagram
Key Takeaways
- Form POSTs, JSON API calls, tracking pixels, and batched analytics are separate lanes that all ride on the same browser and cookie jar.
- Payload keys plus headers are the literal inventory of what an app collects; read them in the Network tab before trusting a privacy claim.
- A tracking pixel's payload is its querystring, so identifiers and session cookies can leak without any visible form.
- Consent banners gate which vendor scripts load, not how loudly the remaining ones report; tag managers can open lanes the site owner never sees.
- Audit by destination host and note whether credentials or cookies travel with each request.