A coverage audit of BFCache lifecycle guards in Chromium DocumentService
When a page enters the Back/Forward Cache it becomes inactive, but a compromised renderer can ignore the freeze. Each DocumentService implementation must guard its own entry points, because the base class provides no automatic lifecycle guard. This is a source-only pass that inventories those implementations and reduces them to a short candidate list, ending in one question per method. It finds no vulnerabilities on purpose: it decides what a human must read next.
The question
A DocumentService is destroyed on render-frame-host deletion, cross-document navigation or disconnect — but not when its document enters the Back/Forward Cache. While cached, the document is inactive, yet a compromised renderer may keep calling the interface as if nothing happened.
So for every implementation, one question: does the code that can run while the document is inactive depend on an explicit lifecycle, permission or activation guard to stay safe? The canonical guard both tests inactivity and disallows or evicts, and it has to be applied on every entry point and every observer callback.
What this is, and what it is not
This is an inventory and triage pass, not an exploit and not a chain. Its output classifies each method by the first guard layer present, and where it finds none it says only "a human must read this" — never "vulnerability".
The value is in shrinking the search space. Instead of reading every implementation by hand, a reviewer gets a short, line-referenced list of the methods that actually warrant a careful read.
The method
The tool enumerates DocumentService subclasses, resolves each one to its implementation file, its Mojo interface and method list, and its binder site to judge whether the interface is web-reachable at all.
For each method it does not grep the whole file: it locates the method body by brace matching and scans only that body for guards, so a guard sitting in a different method cannot be miscredited as covering this one. That single detail removes a whole class of false positives that plain text search produces.
File-level guards are recorded separately as indirect coverage, and each method is classified by the first guard layer it actually has.
Why it matters
Browser lifecycle safety is exactly the kind of surface where an automated scan is worse than useless: it either drowns you in noise or gives false confidence. A triage pass that is honest about its own limits — that ends in a question, not a verdict — is what turns an unreadable universe of code into a reviewable list.
That discipline is the same one we bring to client work: automation for breadth, a human for the decision, and no finding asserted without someone reproducing it.
Automation should narrow the question, not answer it. The output here is a list of things worth a human read — and the honesty to say so.