Solana Program Security Audit Checklist
This checklist provides a structured, technical, and security-oriented framework for auditing Solana programs (commonly referred to as "smart contracts" in other blockchain contexts). Solana's architecture, featuring stateless programs that manage data via separate accounts, introduces unique risks such as account forgery, signer mismatches, and cross-program invocation (CPI) abuses. The checklist is derived from established Solana audit practices, emphasizing an attacker mindset to identify vulnerabilities that could lead to fund theft, state manipulation, or denial-of-service (DoS) attacks.
Audits should prioritize invariants (e.g., total token supply integrity), edge cases (e.g., zero balances, maximum values), and economic incentives. Use tools like Anchor for safer development, but verify all custom logic. Automated scanners (e.g., Soteria, Cargo Audit) complement manual review, but human analysis is essential for logic flaws.
Pre-Audit Preparation
Establish context and scope before code review to align with intended functionality and identify discrepancies early.
- Review Project Specifications: Examine all available documentation, including whitepapers, Notion docs, Excel sheets, text descriptions, or similar. Identify core features (e.g., token minting, staking, yield farming). If insufficient, request clarification from the project team on invariants, user flows, and security assumptions. This prevents misalignment between code and intent, such as unintended upgrade paths.
- Map Account Structure: Analyze how accounts store data due to Solana's statelessness. Identify:
- Program-Derived Addresses (PDAs) and non-PDAs for state (e.g., vaults, configs).
- User-associated accounts (e.g., SPL token accounts).
- System accounts (e.g., rent sysvar, clock).
- Unused or arbitrary accounts: Check for paths allowing injection of malicious data, which could enable account takeovers or data poisoning.
- Adopt Attacker Mindset: After initial code reading, ask:
- Can I steal funds (SPL tokens, SOL, or other assets)?
- Can I freeze the program (e.g., lock funds, disable deposits/withdrawals, halt upgrades)?
- Can I misdirect funds to incorrect users?
- Can I alter critical states (e.g., change owners, multisig thresholds, validator lists)?
- Can I upgrade the program to malicious code?
- Can I exploit pricing (e.g., buy tokens cheaply via oracle manipulation)?
- Can I claim excess refunds?
- Can I acquire more tokens than permitted (e.g., via overflow exploits)?
- Compare with Solana Program Library (SPL): Reference SPL implementations (e.g., Token Program, Associated Token Accounts) as audited standards from Solana Labs. If code mirrors SPL, focus audit on custom logic; deviations may introduce risks like incompatible CPI calls.
- Additional Related Preparation Steps:
- Set up a local Solana validator for simulation testing.
- Review program dependencies via
cargo depsand check for vulnerabilities usingcargo audit. - Document entry points (instructions) and their required accounts/signers.
Code Structure Analysis
Solana programs are typically composed of 3-4 Rust files (e.g., lib.rs for entrypoints, instructions.rs for logic, state.rs for data structs, errors.rs for custom errors). Ensure modular design reduces complexity.
- Overall Structure Review: Verify separation of concerns (e.g., no business logic in deserialization). Look for unused modules or functions that could harbor dead code vulnerabilities.
- Account Validation Best Practices: Always validate account types, sizes, and discriminators at instruction entry. Use Anchor constraints (e.g.,
#[account(mut, has_one = owner)]) if applicable.
- Additional Related Checks:
- Ensure proper use of Borsh or Anchor serialization to prevent deserialization attacks (e.g., buffer overflows from malformed data).
- Check for compute budget management: Instructions should not exceed 200,000 compute units to avoid DoS via exhaustion.
Common Vulnerabilities
Scan for known Solana-specific issues, which often stem from account model mismatches or unchecked inputs. These are high-priority as they enable direct exploits.
| Vulnerability | Technical Description | Security Impact | Detection & Mitigation |
|---|---|---|---|
| Missing Ownership Check | Failure to verify account.owner == program_id allows passing fake accounts with forged data. | Fund theft via simulated states (e.g., fake vault balances). | Use if account.owner != ctx.program_id { return Err(ProgramError::IncorrectProgramId); }. In Anchor: #[account(owner = program_id)]. |
| Missing Signer Check | Omitting account.is_signer check permits unauthorized calls to privileged instructions. | Unauthorized state changes (e.g., admin transfers). | Enforce if !account.is_signer { return Err(ProgramError::MissingRequiredSignature); }. Anchor: #[account(signer)]. |
| Solana Account Confusions | Incorrect indexing or typing in Accounts array (e.g., mistaking token account for config). | Data overwrites or unauthorized accesses. | Validate indices and use typed structs. Test with shuffled accounts in unit tests. |
| Arbitrary Signed Program Invocation | Unvalidated CPI to external programs or signed CPIs from untrusted sources. | Malicious program execution draining funds. | Hardcode expected program IDs in CPIs: if invoked_program.key != TOKEN_PROGRAM_ID { err }. Restrict signers. |
| Integer Overflow & Underflow | Wrapping arithmetic in release mode (e.g., u64 overflow). | Negative balances, infinite mints. | Use checked ops: a.checked_add(b).ok_or(ArithmeticOverflow)?. Consider safe math crates like checked-arithmetic. |
- Additional Related Vulnerabilities:
- PDA Seed Collisions: Reusable or predictable seeds allow account overwrites. Mitigate with unique nonces or hashes.
- Rent Exemption Bypass: Accounts not checked for rent exemption (
account.lamports() >= Rent::get()?.minimum_balance(data.len())) can be reclaimed, leading to data loss. - Sysvar Tampering: Validate sysvars (e.g., Clock, RecentBlockhashes) aren't faked in tests, as they're trusted in production.
General Issues
Address non-specific but pervasive problems that amplify risks.
- Reentrancy: Solana caps CPI depth at 4, limiting recursion-based attacks. Still, check for self-CPI loops causing state inconsistencies or compute exhaustion.
- Unsafe Rust Code:
unsafeblocks bypass memory safety; manually verify for issues like buffer overflows, use-after-free, or uninitialized memory.
- Outdated Dependencies: Dependencies may contain CVEs. Use
cargo-outdatedandcargo auditto identify and update.
- Redundant Code: Dead or duplicated code increases attack surface. Refactor for simplicity.
- Failure to Follow Best Practices: Lack of assertions (e.g.,
assert_eq!(balance_after, balance_before + amount)), poor error propagation, or absent multi-sig for upgrades. Enforce timelocks on critical actions.
- Additional Related Issues:
- Zero-Knowledge Proof Integration: If used (e.g., via zk-SNARKs), verify proof verification logic to prevent forgery.
- Cross-Chain Bridge Risks: If bridging assets, check for replay attacks or invalid proofs.
- Zero-Knowledge Proof Integration: If used (e.g., via zk-SNARKs), verify proof verification logic to prevent forgery.
High-Level Logic and Economic Errors
Evaluate semantics, incentives, and novel risks beyond low-level bugs.
- Logic Implementation Verification: Simulate user flows against specs to ensure correctness (e.g., deposit/withdraw balances match expectations).
- Contract-Specific Low-Level Vulnerabilities: Identify unique risks, e.g., in AMMs: price slippage exploits; in governance: vote dilution.
- Economic Attacks: Rule out flash loans, oracle manipulations, or sandwich attacks on time-sensitive instructions.
- Denial-of-Service Attacks: Check for loops over unbounded data, excessive account creations, or compute-intensive ops.
- Front-Running/Sandwiching: Instructions vulnerable to MEV (e.g., trades without commit-reveal schemes).
- Unsafe Designs for Future Vulnerabilities: E.g., upgradable patterns without delays or audits.
- Novel Solana-Specific Vulnerabilities: Parallel execution races, CPI ordering issues, or account resize abuses.
- Rug-Pull Mechanisms/Backdoors: Hidden admin mints, pause functions, or escape hatches abusable by deployers.
- Additional Related Checks:
- Flash Loan Resistance: Ensure atomicity in borrowing/repaying to prevent griefing.
- Oracle Security: If using oracles, validate freshness and sources to avoid manipulation.
- Upgradeability Risks: If upgradable, enforce multi-sig and timelocks; verify proxy patterns.
- Flash Loan Resistance: Ensure atomicity in borrowing/repaying to prevent griefing.
Testing and Validation
- Unit and Integration Tests: Cover 100% of instructions with edge cases; use fuzzing for inputs.
- Simulation on Local/Devnet: Reproduce exploits in a controlled environment.
- Penetration Testing: Build Proof-of-Concept (PoC) exploits for suspected issues.
- Post-Audit Recommendations: Suggest monitoring invariants via off-chain tools and bounty programs.
