What BUIzz Teaches About Browser Security
BUIzz supports a precise answer to the question at the center of this series: browser policies can fail at the user-interaction boundary when a browser-owned transition creates a context, request, or relationship that no longer carries the restriction established for the page. The important lesson is not simply that the study found bugs. It is that a security claim about a browser must name the path through which the claim is tested. This final synthesis connects policy declaration, browser state, user interaction, observation, and attacker consequence into one model, then uses that model to set the right roles for testing, standards, and site operation.
The guarantee belongs to the journey, not the header
A web security policy begins with a site decision. An application returns a response that says, in effect, “when this content is used, these actions should be restricted.” A browser parses the response and turns that declaration into enforcement behavior. It decides whether a script can execute, whether a resource can load, whether a cookie belongs on a request, whether a feature can be used, whether another page can retain an opener relationship, whether a connection should use HTTPS, or whether a page can be framed.
The header is visible at the beginning of the journey, which makes it tempting to treat it as the security boundary. BUIzz shows why that is incomplete. The browser owns the steps after the response: it creates documents, restores tabs, opens links in new contexts, changes layouts, sends requests, and connects one browsing context to another. Each step may preserve, copy, reinterpret, or accidentally drop the state established by the policy. The security guarantee is therefore a relationship between a declaration and every relevant operation that follows it.
A useful causal chain has five parts. First, the site declares a restriction. Second, the browser establishes an initial enforcement state. Third, a user or page initiates a transition, with BUIzz concentrating on transitions that come through the browser UI and change navigation or rendering context. Fourth, the browser creates a destination or request and applies the policy-related checks. Fifth, the resulting behavior gives an attacker more or less capability than the declaration intended. A defect at the fourth step can make the fifth step unsafe even when the first two steps were correct.
The chain also separates four questions that are often collapsed into one. Configuration asks whether the site declared a sensible policy. Implementation asks whether the browser applied that policy correctly. Specification asks what the relevant platform rules require for the new context or request. Exploitability asks whether an attacker can cause the required condition, including any user action. BUIzz is primarily about the second question, interpreted using the third and connected to the fourth. It does not prove that a site is configured well, that every browser path is covered, or that every observed weakening is an immediately exploitable attack.
CSP's local-scheme inheritance rule makes the chain concrete. The current W3C CSP Level 3 text says that documents loaded from local schemes such as srcdoc, blob:, and data: should inherit a copy of the source document's policy in the situations covered by the specification. The rationale is to prevent a page from opening content it controls in a fresh context and using that context to escape restrictions such as the ban on unauthorized inline script. The policy is a snapshot at the new document's creation, so the browser has to establish the relevant state at the right time.
BUIzz's CSP cases show what happens when that continuity fails. A page can correctly block a nonce-less script on its initial visit, while a drag-and-drop or open-in-view transition leads to a destination where the parent restriction is not inherited or a prohibited navigation is allowed. The security failure is not in the text of the original header. It is in the browser's creation and initialization of the next context. That is why the user interaction is part of the causal explanation rather than a detail added after the vulnerability has already been found.
The same chain does not require every policy to use the word “inheritance.” A SameSite attribute must remain meaningful when the browser classifies a cross-site request initiated through a new tab, a split view, or a drag. COOP must remain meaningful when a new pane or window is created and the browser decides whether an opener relationship exists. HSTS must remain meaningful when a navigation uses a path that might otherwise begin with HTTP. Permissions Policy must continue to constrain a feature request made by code in a related destination. The protected state takes a different form in each case, but each form must survive the transition that brings it into use.
“Survive” does not mean “produce identical behavior in every context.” A top-level navigation and an iframe navigation can legitimately differ. A request can have a different origin, method, or referrer context. A policy may intentionally allow one resource and block another.