Boas Práticas de Segurança

Um resumo condensado das 25 práticas de segurança de programa mais importantes extraídas de cada página nesta seção.

Signatário em toda mutação: Mapeie cada movimento de lamport/token para um Signer obrigatório (Verificações de Signatário e Owner).
Contas tipadas em vez de UncheckedAccount: Padrão Account<'info, T>; documente exceções.
has_one para campos de autoridade: Vincule pubkeys de autoridade de estado a contas assinantes.
Constraints de mint e owner: Contas de token devem corresponder ao mint esperado e vínculo de cofre (Validação de Conta).
Sementes PDA canônicas: Armazene bump no init; use seeds + bump em toda ix PDA (Ataques de PDA).
Evite init_if_needed: Prefira init dedicado; se necessário, proteja com is_initialized (Reinicialização).
Matemática verificada em todo lugar: Sem +/- simples em saldos (Aritmética).
Intermediários u128: Multiplique antes de dividir para matemática de share e AMM.
Arredonde contra usuários: Taxas arredondam para cima; pagamentos para baixo - documente política.
Checks-effects-interactions: Atualize estado antes de CPI (Riscos de CPI).
Lista de permissões de programa CPI: require_keys_eq! em todo ID de programa externo.
Programa de token tipado: Use Program<'info, Token> não AccountInfo bruto.
Obsolescência de oráculo: get_price_no_older_than com idade máxima apertada (Oráculos).
Fixe pubkeys de oráculo: Nunca feed fornecido pelo usuário sem lista de permissões.
Sem metas de conta duplicadas: constraint = a.key() != b.key() onde double-counting é possível.
Sysvars tipados: Sysvar<'info, Clock> em vez de contas falsificáveis.
Atributo close com segurança: close = destination somente com verificações de autoridade.
Execute catálogo Sealevel por PR: Passagem rápida contra S1-S15 (Catálogo).
Testes negativos LiteSVM: Conjuntos de contas adversariais para cada ix (Testando CPIs).
Fuzz em caminhos de matemática: Trident em handlers deposit/withdraw/swap (Fuzzing).
Builds verificáveis: Publique hash solana-verify com releases.
Autoridade de upgrade multisig: Sem upgrade de chave única em TVL de produção.
Minimize escopo de invoke_signed: Sementes PDA estreitas por CPI.
Auditoria antes de TVL na mainnet: Siga Fluxo de Auditoria.
Fail closed: Quando validação incerta, retorne erro - nunca continue com melhor esforço.

FAQs

Qual é a prática de maior ROI?

Constraints de signatário + mint + owner em todas as instruções de token - previne a maioria dos exploits históricos.

Devo banir init_if_needed totalmente?

Banir em caminhos de admin de produção; se usado para onboarding de usuário, guarda is_initialized obrigatória.

Como as práticas interagem com limites de CU?

Constraints adicionam CU mas muito mais barato que exploits - otimize somente após cobertura de segurança.

Relacionados

Noções Básicas de Segurança - entrada da seção
Catálogo de Ataques Sealevel - mapa de ataques
Boas Práticas de Testes - política de testes
Boas Práticas de Deploy - segurança de release

Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.

Boas Práticas de Segurança

Um resumo condensado das 25 práticas de segurança de programa mais importantes extraídas de cada página nesta seção.

Signatário em toda mutação: Mapeie cada movimento de lamport/token para um Signer obrigatório (Verificações de Signatário e Owner).

Contas tipadas em vez de UncheckedAccount: Padrão Account<'info, T>; documente exceções.

has_one para campos de autoridade: Vincule pubkeys de autoridade de estado a contas assinantes.

Constraints de mint e owner: Contas de token devem corresponder ao mint esperado e vínculo de cofre (Validação de Conta).

Sementes PDA canônicas: Armazene bump no init; use seeds + bump em toda ix PDA (Ataques de PDA).

Evite init_if_needed: Prefira init dedicado; se necessário, proteja com is_initialized (Reinicialização).

Matemática verificada em todo lugar: Sem +/- simples em saldos (Aritmética).

Intermediários u128: Multiplique antes de dividir para matemática de share e AMM.

Arredonde contra usuários: Taxas arredondam para cima; pagamentos para baixo - documente política.

Checks-effects-interactions: Atualize estado antes de CPI (Riscos de CPI).

Lista de permissões de programa CPI: require_keys_eq! em todo ID de programa externo.

Programa de token tipado: Use Program<'info, Token> não AccountInfo bruto.

Obsolescência de oráculo: get_price_no_older_than com idade máxima apertada (Oráculos).

Fixe pubkeys de oráculo: Nunca feed fornecido pelo usuário sem lista de permissões.

Sem metas de conta duplicadas: constraint = a.key() != b.key() onde double-counting é possível.

Sysvars tipados: Sysvar<'info, Clock> em vez de contas falsificáveis.

Atributo close com segurança: close = destination somente com verificações de autoridade.

Execute catálogo Sealevel por PR: Passagem rápida contra S1-S15 (Catálogo).

Testes negativos LiteSVM: Conjuntos de contas adversariais para cada ix (Testando CPIs).

Fuzz em caminhos de matemática: Trident em handlers deposit/withdraw/swap (Fuzzing).

Builds verificáveis: Publique hash solana-verify com releases.

Autoridade de upgrade multisig: Sem upgrade de chave única em TVL de produção.

Minimize escopo de invoke_signed: Sementes PDA estreitas por CPI.

Auditoria antes de TVL na mainnet: Siga Fluxo de Auditoria.

Fail closed: Quando validação incerta, retorne erro - nunca continue com melhor esforço.

FAQs

Qual é a prática de maior ROI?

Constraints de signatário + mint + owner em todas as instruções de token - previne a maioria dos exploits históricos.

Devo banir init_if_needed totalmente?

Banir em caminhos de admin de produção; se usado para onboarding de usuário, guarda is_initialized obrigatória.

Como as práticas interagem com limites de CU?

Constraints adicionam CU mas muito mais barato que exploits - otimize somente após cobertura de segurança.

Relacionados

Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.

Boas Práticas de Segurança

FAQs

Relacionados

Buscar na documentação

Boas Práticas de Segurança

FAQs

Relacionados