solana-security

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](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](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:**

// 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:

// ✅ 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](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](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](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](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](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](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](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?
2. PDA validation, program ID checks, has_one constraints

1. Can arithmetic overflow or underflow?
2. All math uses checked operations, division by zero protected

1. Are all accounts properly validated?
2. Owner, signer, writable, initialized checks present

1. Can the program be drained?
2. Authorization checks, reentrancy protection, acco