auditing-move-resource-ownership

Auditing Move resource ownership: acting on a resource without proving the caller owns it

Move's safety rests on linear resources and abilities, and the bug is a function that acts on a resource or an object without proving the caller is entitled to it. A public entry function with no signer-authority check, an object passed in and mutated without verifying its owner, a capability resource that leaks because it can be stored or returned, an ability granted too broadly, these are the ways an arbitrary signer reaches a privileged state change. You audit it by resolving each function's visibility (who can call it) and the ability set of the types it touches (what can be copied, stored, or dropped), then checking whether the function asserts ownership or authority before it acts. The account-model and reentrancy shapes belong to the EVM smart-contract skills; this skill owns the resource-and-ability model of Move.

When to use

• You are reviewing a Move module's functions, their visibility, and the resources and objects they touch.
• A public or entry function acts on a passed object or a global resource, or hands out a capability.
• You want to know whether an arbitrary signer can drive a state change on a resource they do not own.

Scope check

Audit only contracts you own or are authorized to assess, and submit a transaction only against a network in scope (a devnet or testnet, or a mainnet only with authorization), a call that passes moves real value. Adjudicate on the module source. If you can't name the authorization, stop.

The loop

1. Resolve the visibility and the ability set first. For each function, determine who can call it (public, public entry, public-to-friend or package-internal, or private) and for each type it touches determine the abilities it carries (key, store, copy, drop). Visibility decides whether an arbitrary signer reaches the function, and the abilities decide whether a resource or capability can be duplicated or leaked, so settle both before flagging.