SOLANA ATTACK
📚 Learning Center
Understand Solana smart contract security fundamentals
Solana Account Model
Program
Executable code
Accounts
Program state
Signer?
Authorization
PDA?
Derived address
Owner? Field
Each account stores which program owns it. Always validate this field to ensure accounts are managed by your program, not an attacker's.
Constraint? System
Anchor constraints automate validation. Using #[account(...)] attributes prevents manual validation errors.
Account Validation?
Verify accounts meet all expected constraints before using them. Check ownership, signer status, and data types.
Program ID? Validation
In CPI calls, always verify the program ID matches your expected target to prevent redirection attacks.
Real-World Vulnerability Patterns
Account Validation in Solana
The Solana ledger stores data in accounts. Each account has an owner field that identifies which program controls it. Failing to validate this can allow attackers to swap your expected account with one they control.
> Learn how to prevent this vulnerability in the Attack Simulator
Cross-Program Invocation (CPI) Security
When your program calls another program, you must validate that the called program is what you expect. Attackers can create fake programs that intercept and redirect fund transfers.
> Learn how to prevent this vulnerability in the Attack Simulator
PDA Derivation and Seed Safety
Program Derived Addresses must use unique, unpredictable seeds. If seeds are reused or predictable, attackers can create PDAs and claim ownership of accounts meant for legitimate users.
> Learn how to prevent this vulnerability in the Attack Simulator
Essential Anchor Concepts
#[account(signer)]
Enforces cryptographic signature validation. Use this on accounts that must authorize transactions.
#[account(owner = ...)]
Validates that an account is owned by a specific program. Critical for preventing account substitution.
Account<'info, T>
Type-safe account wrapper that validates data structure. Preferred over UncheckedAccount in most cases.
Signer<'info>
Ensures an account has signed the current transaction. Use for authorization checks.
require!(..., Error)
Validation macro for custom checks. Essential for implementing business logic constraints.
UncheckedAccount<'info>
Raw account without validation. Use only when necessary and always manually validate.
Ready to Test Your Knowledge?
Apply these concepts to solve real vulnerability scenarios.
Start Challenge Mode