Overview
BUIzz tests whether browser UI transitions preserve security policies after navigation or context changes. The series defines the policy invariant, inventories and simulates browser-owned actions, compares policy-specific outcomes before and after them, and interprets findings with standards-aware triage. It shows concrete failures across policies while treating study counts as bounded evidence, not live-web prevalence or proof of complete coverage.
Learning outcomes
- A correct site policy can still be weakened when a browser-owned transition creates a new context or request.
- BUIzz exercises browser UI paths with OS-level input and compares policy-specific outcomes before and after the transition.
- The study reported failures across CSP, SameSite, Permissions Policy, COOP, and HSTS, with different attacker consequences.
- Pre/post testing complements differential testing; neither oracle covers every browser path or baseline defect.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does BUIzz test?
BUIzz tests whether a browser preserves a site's security policy when a user takes a browser UI path that changes navigation or rendering context.
Why can a browser UI action create a security bug?
A browser UI action can create a security bug when it initializes a destination, request, or browsing relationship without preserving the restriction that should govern it.
How is BUIzz different from cross-browser testing?
BUIzz compares one browser before and after a browser UI transition, while differential testing compares implementations running the same test. The approaches expose different blind spots and can be combined.
What are the limits of BUIzz's findings?
BUIzz's findings are bounded by its selected policies, pages, interactions, platforms, and controlled local environment. They do not establish live-web prevalence or rule out baseline, OS-specific, non-navigation, or longer-sequence failures.