Response sanitization no longer gated by a renderer-supplied IPC flag

The renderer got a vote on whether its own responses were sanitized.

Component: WebKit NetworkProcess | c5fabb4

WebKit's multi-process architecture treats the WebContent process as untrusted from the NetworkProcess's point of view: a renderer compromise, say via a JS engine bug, is supposed to be contained by the NetworkProcess boundary. That containment only holds if IPC parameters arriving from WebContent never by themselves control security-relevant behavior. NetworkResourceLoadParameters is the struct WebContent sends to describe a load it wants performed, and among its fields was shouldRestrictHTTPResponseAccess — a boolean, forwarded unchecked, that decided whether responses were sanitized before being handed back.

This commit removes the field. Response sanitization — Set-Cookie stripping and cross-origin header filtering — becomes unconditional in NetworkResourceLoader::sanitizeResponseIfPossible rather than being gated on the value the client supplied. The flag was a legacy artifact of WK1/WK2 coexistence, originally there to let WK1 clients opt out of sanitization; after WK1 was removed it was always effectively true from any legitimate client, but the check stayed IPC-controlled rather than hardcoded.

Significance

A compromised WebContent process could clear this flag and disable response header sanitization outright, exposing Set-Cookie and other cross-origin-sensitive headers to the renderer. That is a latent bypass reachable by any process able to forge or tamper with NetworkResourceLoadParameters — which is exactly the position a second-stage renderer exploit occupies. Removing the field converts an IPC-controlled policy decision into a compile-time one, which is the only form that survives a hostile sender.

Audit directions

The pattern to hunt is policy booleans that cross the IPC boundary upward. Narrowly: sweep NetworkResourceLoadParameters and its sibling load-parameter structs for remaining fields whose value selects between a checking and a non-checking code path — the match tell is a field consumed only as if (params.shouldX) around a sanitization, validation, or filtering call. Wider: the same shape exists wherever a lower-privilege process describes work for a higher-privilege one, so the GPUProcess and UI-process parameter structs deserve the same read; there the tell is a bool or enum field named for a permission or a restriction rather than for data. Widest: legacy compatibility flags in general are the highest-yield instance of this class, because their "always true in practice" status removes the pressure to enforce them — grep for fields whose only remaining false-value producer was a removed client (WK1, deprecated SPI, test-only harnesses) and confirm each has been hardcoded rather than merely left alone.

---