Auditing a Solana program isn't about reading every line top to bottom and hoping something jumps out. It's about knowing the small set of places where Anchor programs actually go wrong and checking each one deliberately. This guide walks through that process in the order an experienced reviewer would follow, and ends with a checklist you can paste into your review notes.
Anchor does a lot of validation for you — but only when you use its typed accounts and constraints. Most Anchor vulnerabilities are places where the author quietly opted out of that protection. So a large part of auditing an Anchor program is finding where the safety rails were removed.
Step 1: Map the instructions and their authority
Before reading any logic, list every instruction and answer one question for each: who is allowed to call this, and how is that enforced?
For every privileged instruction (withdraw, close, update-config, mint, set-authority), find the account that authorizes it and confirm it's declared as Signer<'info> and tied to the state it acts on with has_one or an explicit constraint. If the authority is an AccountInfo or UncheckedAccount, that's your first finding.
