The Same Test Across Web, Data, Protocol, and Runtime Boundaries

Cloudflare's security-audit skill keeps one evidence standard while changing the details of the boundary under review. This chapter compares how the same questions—who acts, which control should bind the action, what resource is affected, and what result is observable—change across web, browser, protocol, data, availability, cloud, supply-chain, native, and local-IPC systems, so readers can choose domain depth without treating a catalogue as coverage.

The danger of cross-domain security guidance is false equivalence. A browser origin is not a broker identity. A signed artifact is not a tenant predicate. A workload role is not an application permission. Yet each can fail for a related reason: the system accepts an input under one identity or representation and makes a decision as though a stronger identity, scope, or guarantee had been established.

One boundary contract, different semantics

The universal questions remain stable. Name the lower-trust principal. Identify the accepted input, action, or state. Locate the control that should bind, reject, isolate, limit, or revoke it. Name the protected resource or shared condition. Stop at the smallest meaningful result. The domain changes the evidence needed to answer those questions.

HTTP, browser, RPC, and local IPC

At an HTTP or authentication boundary, the first challenge may be that two components interpret the same request differently. A front end and back end can disagree about length, header normalization, or transfer encoding. A cache can vary its response on a value that it omits from the key. A forwarded host or identity header can influence a reset link, tenant route, callback, or authorization decision. The invariant is not simply “the request is valid.” It is that the same principal, request, resource, and security-relevant interpretation survive every hop.

Credential and identity checks add their own binding fields. A token's signature does not by itself prove that it is meant for this audience, issuer, session, origin, resource, or assurance level. A recovery token or step-up challenge must remain bound to the account, operation, expiry, and one-time state that created it. A missing cookie flag is not automatically a vulnerability; the evidence must show a realistic less-trusted origin or network position can read or replace a credential, or that a cross-site request can change protected state.

In a browser, the source and policy are different. A message handler must validate the exact origin and, where relevant, the expected source window. A DOM sink needs a controllable browser source and an executing or disclosing destination. Storage and service-worker caches can outlive logout or account switching, so the lifecycle owner matters: who writes the entry, who reads it later, and what clears or revalidates it? The browser's same-origin policy, escaping, content policy, and cross-origin isolation are real controls when their configuration and behavior are visible. A missing header without a reachable sensitive action remains a hardening concern.

For RPC and messaging, channel identity and application identity must be separated. A connection authenticated by a peer certificate or broker credential may still carry a caller-controlled tenant or subject field. A schema proves shape, not provenance, ordering, replay resistance, or authority over the named resource. Streams, batches, retries, acknowledgments, and dead-letter paths can change the lifecycle after an initial authorization decision. The evidence must follow the producer, transport, consumer, and side effect, including who can answer a callback or correlation ID.

Local IPC changes the lower-trust starting point rather than removing the boundary. Another application, sandboxed child, local user, downloaded document, or remote webview frame may be the attacker. A socket path, process name, bundle identifier, or claimed sender field is not peer authentication.