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, account confusion prevention

5. What happens in edge cases?

   • Zero amounts, max values, closed accounts, expired data

6. Are external dependencies safe?

   • Oracle validation (staleness, status), CPI targets verified, token program checks

Audit Workflow

Before Starting

1. Understand the protocol purpose and mechanics
2. Review documentation and specifications
3. Set up local development environment
4. Run existing tests and check coverage

During Audit

1. Follow the 5-step review process systematically
2. Document findings with severity and remediation
3. Create proof-of-concept exploits for critical issues
4. Test fixes and verify they work

After Audit

1. Present findings clearly prioritized by severity
2. Provide actionable remediation steps
3. Re-audit after fixes are implemented
4. Document lessons learned for the protocol

Testing for Security

Beyond code review, validate security through testing:

• Unit tests: Test each instruction's edge cases
• Integration tests: Test cross-instruction interactions
• Fuzz testing: Use Trident to discover unexpected behaviors
• Exploit scenarios: Write POCs for found vulnerabilities
• Upgrade testing: Verify migration paths are secure

Core Principle

In Solana's account model, attackers can pass arbitrary accounts to any instruction.

Security requires explicitly validating:

• ✅ Every account's ownership
• ✅ Every account's type (discriminator)
• ✅ Every account's relationships
• ✅ Every account's state
• ✅ Every signer requirement
• ✅ Every arithmetic operation
• ✅ Every external call

There are no implicit guarantees. Validate everything, trust nothing.