Hunt by Invariant, Not by Checklist

For Cloudflare's security-audit skill, a hunter's job is to settle a security invariant inside an assigned boundary, not to collect alarming patterns. This chapter turns the coverage unit into an investigation method: define who can do what, trace the exact path through controls and copies, test only accepted edge states, and stop at the smallest result that proves or disproves the claim.

An invariant is a condition the system must preserve. “Only the owner can change this record” is an invariant. So is “a callback completes the session that initiated it,” “a tool acts only on the resource the requester approved,” or “a bounded request cannot create unbounded shared work.” The wording is useful because it gives the hunt a before-and-after test. Either the path preserves the condition, or it does not.

Turn a broad concern into one testable path

A request to “look for vulnerabilities” is too broad to guide careful reasoning. The skill's method narrows it through a sequence of questions.

First name the lower-trust principal and their starting capability. An ordinary tenant may read and change their own records. A contributor may submit a pull request but not publish a release. A browser page may send a message but not be a trusted application frame. A model may influence a tool argument but may not be allowed to grant itself a credential. Stating the starting capability prevents the hunt from quietly giving the principal more authority than the product does.

Then name the accepted value, action, or state transition. It could be a resource selector, an upload, a message, a role change, a callback, a file path, a quantity, or a retry. The important question is what the interface actually accepts, not what a well-behaved client normally sends. If a batch endpoint accepts an array of record identifiers, the invariant concerns every item, not just the first item the user interface displays. If a workflow accepts a cancellation after work has started, the invariant includes what remains running after cancellation.

Next locate the control that should reject, bind, isolate, limit, or revoke the action. A check may be present but applied at the wrong point. It may bind an authenticated account but not the selected resource, validate a value before normalization but use a different representation later, or enforce a limit per message while the attacker accumulates state across messages. A control should be compared with the exact guarantee the sink requires.

Now trace the path. Follow parsing, identity, authorization, normalization, state transitions, derived copies, and the final sink only as far as they bear on the assigned boundary or a guarantee that boundary relies on. Read the sibling paths that produce the same effect: direct and batch operations, retries, cancellations, migrations, compatibility routes, error paths, and background work. The purpose is not to read everything. It is to find whether the same invariant is enforced equivalently wherever the effect can occur.

Finally state the smallest result that would settle the claim. A wrong return value, an unauthorized dummy record, a policy difference, an invalid image load, a repeatable stale alias, or a bounded shared-resource effect may be enough. If the smallest result is not observable under safe local conditions, the source may still support a specific unresolved lead, but the hunt must not invent a stronger effect.