auth-validation

AUTH_VALIDATION Skill (Soroban)

Trigger Pattern: Always required for Soroban audits Inject Into: Breadth agents, depth agents Finding prefix: [AV-N] Rules referenced: R4, R6, R10, R13

Soroban's authorization model differs fundamentally from EVM: instead of msg.sender, callers invoke require_auth() or require_auth_for_args() on an Address. Missing or incorrectly scoped auth is the most common critical bug class on Soroban.

1. Auth Inventory

For EVERY pub fn in each contract, determine whether it modifies state and whether auth is present:

Function	Modifies State?	Modifies Balance/Config/Ownership?	require_auth Present?	Auth Address	Missing?
{fn_name}	YES/NO	YES/NO	YES/NO	{address_var or NONE}	FLAG if modifies state but NO auth

Critical patterns to flag:

• Any function writing to storage without a prior require_auth() call
• Any function that transfers funds or mints tokens without auth
• Any function that updates privileged config (admin, fee, whitelist) without auth

Soroban note: require_auth() panics if the address has not authorized the invocation. It does NOT return a bool — absence means the call proceeds without authorization.

2. Auth Tree Propagation

When a contract calls another contract via invoke_contract, the auth context must propagate to sub-calls. Trace each cross-contract invocation:

Calling Fn	Sub-Contract Invocation	Auth Expected in Sub-Call?	AuthorizedInvocation Provided?	Sub-Call Protected?
{fn}	invoke_contract({contract}, {fn})	YES/NO	YES/NO	YES/NO

Attack surface: If a top-level function calls require_auth(user) but then invokes a sub-contract on behalf of the user without passing the correct AuthorizedInvocation tree, the sub-contract cannot verify the user actually authorized the sub-call.