Solana Security Auditing

Systematic security review framework for Solana programs, supporting both Anchor and native Rust implementations.

Review Process

Follow this systematic 5-step process for comprehensive security audits:

Step 1: Initial Assessment

Understand the program's context and structure:

• Framework: Anchor vs Native Rust (check for use anchor_lang::prelude::*)
• Anchor version: Check Cargo.toml for compatibility and known issues
• Dependencies: Oracles (Pyth, Switchboard), external programs, token programs
• Program structure: Count instructions, identify account types, analyze state management
• Complexity: Lines of code, instruction count, PDA patterns
• Purpose: DeFi, NFT, governance, gaming, etc.

Step 2: Systematic Security Review

For each instruction, perform security checks in this order:

1. Account Validation - Verify signer, owner, writable, and initialization checks
2. Arithmetic Safety - Check all math operations use checked_* methods
3. PDA Security - Validate canonical bumps and seed uniqueness
4. CPI Security - Ensure cross-program invocations validate target programs
5. Oracle/External Data - Verify price staleness and oracle status checks

→ See references/security-checklists.md for detailed checklists

Step 3: Vulnerability Pattern Detection

Scan for common vulnerability patterns:

• Type cosplay attacks
• Account reloading issues
• Improper account closing
• Missing lamports checks
• PDA substitution attacks
• Arbitrary CPI vulnerabilities
• Missing ownership validation
• Integer overflow/underflow

→ See references/vulnerability-patterns.md for code examples and exploit scenarios

Step 4: Architecture and Testing Review

Evaluate overall design quality:

• PDA design patterns and collision prevention
• Account space allocation and rent exemption
• Error handling approach and coverage
• Event emission for critical state changes
• Compute budget optimization
• Test coverage (unit, integration, fuzz)
• Upgrade strategy and authority management

Step 5: Generate Security Report

Provide findings using this structure:

Severity Levels:

• 🔴 Critical: Funds can be stolen/lost, protocol completely broken
• 🟠 High: Protocol can be disrupted, partial fund loss possible
• 🟡 Medium: Suboptimal behavior, edge cases, griefing attacks
• 🔵 Low: Code quality, gas optimization, best practices
• 💡 Informational: Recommendations, improvements, documentation

Finding Format:

## 🔴 [CRITICAL] Title

**Location:** `programs/vault/src/lib.rs:45-52`

**Issue:**
Brief description of the vulnerability

**Vulnerable Code:**
```rust
// Show the problematic code

Exploit Scenario: Step-by-step explanation of how this can be exploited

Recommendation:

// Show the secure alternative

References:

• [Link to relevant documentation or similar exploits]

**Report Summary:**
- Total findings by severity
- Critical issues first (prioritize by risk)
- Quick wins (easy fixes with high impact)
- Recommendations for testing improvements

## Quick Reference

### Essential Checks (Every Instruction)

**Anchor:**
```rust
// ✅ Account validation with constraints
#[derive(Accounts)]
pub struct SecureInstruction<'info> {
    #[account(
        mut,
        has_one = authority,  // Relationship check
        seeds = [b"vault", user.key().as_ref()],
        bump,  // Canonical bump
    )]
    pub vault: Account<'info, Vault>,

    pub authority: Signer<'info>,  // Signer required

    pub token_program: Program<'info, Token>,  // Program validation
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

Native Rust:

// ✅ Manual account validation
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}

if vault.owner != program_id {
    return Err(ProgramError::IllegalOwner);
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ProgramError::ArithmeticOverflow)?;

Critical Anti-Patterns

❌ Never Do:

• Use saturating_* arithmetic methods (hide errors)
• Use unwrap() or expect() in production code
• Use init_if_needed without additional checks
• Skip signer validation ("they wouldn't call this...")
• Use unchecked arithmetic operations
• Allow arbitrary CPI targets
• Forget to reload accounts after mutations

✅ Always Do:

• Use checked_* arithmetic (checked_add, checked_sub, etc.)
• Use ok_or(error)? for Option unwrapping
• Use explicit init with proper validation
• Require Signer<'info> or is_signer checks
• Use Program<'info, T> for CPI program validation
• Reload accounts after external calls that mutate state
• Validate account ownership, discriminators, and relationships

Framework-Specific Patterns

Anchor Security Patterns

→ See references/anchor-security.md for:

• Account constraint best practices
• Common Anchor-specific vulnerabilities
• Secure CPI patterns with CpiContext
• Event emission and monitoring
• Custom error handling

Native Rust Security Patterns

→ See references/native-security.md for:

• Manual account validation patterns
• Secure PDA derivation and signing
• Low-level CPI security
• Account discriminator patterns
• Rent exemption validation

Modern Practices (2025)

• Use Anchor 0.30+ for latest security features
• Implement Token-2022 with proper extension handling
• Use InitSpace derive for automatic space calculation
• Emit events for all critical state changes
• Write fuzz tests with Trident framework
• Document invariants in code comments
• Follow progressive roadmap: Dev → Audit → Testnet → Audit → Mainnet

Security Fundamentals

→ See references/security-fundamentals.md for:

• Security mindset and threat modeling
• Core validation patterns (signers, owners, mutability)
• Input validation best practices
• State management security
• Arithmetic safety
• Re-entrancy considerations

Common Vulnerabilities

→ See references/vulnerability-patterns.md for:

• Missing signer validation
• Integer overflow/underflow
• PDA substitution attacks
• Account confusion
• Arbitrary CPI
• Type cosplay
• Improper account closing
• Precision loss in calculations

Each vulnerability includes:

• ❌ Vulnerable code example
• 💥 Exploit scenario
• ✅ Secure alternative
• 📚 References

Security Checklists

→ See references/security-checklists.md for:

• Account validation checklist
• Arithmetic safety checklist
• PDA and account security checklist
• CPI security checklist
• Oracle and external data checklist
• Token integration checklist

Known Issues and Caveats

→ See references/caveats.md for:

• Solana-specific quirks and gotchas
• Anchor framework limitations
• Testing blind spots
• Common misconceptions
• Version-specific issues

Security Resources

→ See references/resources.md for:

• Official security documentation
• Security courses and tutorials
• Vulnerability databases
• Audit report examples
• Security tools (Trident, fuzzers)
• Security firms and auditors

Key Questions for Every Audit

Always verify these critical security properties:

1. Can an attacker substitute accounts?

   • PDA validation, program ID checks, has_one constraints

2. Can arithmetic overflow or underflow?

   • All math uses checked operations, division by zero protected

3. Are all accounts properly validated?

   • Owner, signer, writable, initialized checks present

4. Can the program be drained?

   • Authorization checks, reentrancy protection, acco