APIs e Melhores Práticas de Segurança
A linha de base de segurança do Rust para APIs HTTP - autenticação, validação, segredos, dependências e operabilidade.
Como Usar Esta Lista
- Execute antes de publicar um novo endpoint público ou integração.
- Mapeie cada regra para verificações de CI sempre que possível (
cargo audit, testes, linters). - Revise após incidentes de segurança e atualizações de dependências.
A - Design de API
- Envelope de erro estável com
codelegível por máquina. Mesma forma JSON para todos os 4xx/5xx. - Versionar APIs públicas explicitamente. Prefixo
/v1ou contrato de cabeçalhoAccept. - Documentar códigos de status e regras de idempotência. POST de pagamentos requer
Idempotency-Key. - Paginar coleções; limitar
limit. Prevenir leituras de banco de dados ilimitadas. - Separar roteadores públicos e de administração. Autenticação e limites de taxa diferentes.
B - Autenticação e Autorização
- Autenticar todas as rotas protegidas. Middleware ou extrator - sem endpoints esquecidos.
- Tokens de acesso de curta duração; rotacionar tokens de atualização.
expdo JWT validado com margem. - Armazenar senhas com argon2id. Nunca apenas SHA-256.
- Autorizar por recurso, não apenas por rota. Usuário A não pode ler o ID do Usuário B por adivinhação.
- Retornar 401 vs 403 corretamente. Falta de autenticação vs permissão insuficiente.
C - Entrada e Dados
- Validar na fronteira HTTP. Serde +
validatorantes do DB. - SQL parametrizado apenas. Sem
format!para valores de consulta. - Limitar o tamanho do corpo da requisição. Tower
RequestBodyLimitLayer. - Verificar assinaturas de webhook. HMAC antes de processar o payload.
- Limites de profundidade/complexidade GraphQL. Se GraphQL estiver exposto.
D - Segredos e Criptografia
- Segredos de env/vault, nunca no git. Usar tipos
secrecyna configuração. - TLS em todos os lugares em produção. rustls ou terminação de borda documentada.
- Rotacionar chaves com janela de sobreposição. JWKS do JWT suporta várias chaves.
- Usar crates de criptografia verificados. ring/RustCrypto - sem cifras personalizadas.
- Redigir Autorização e cookies nos logs.
E - Abuso e Cadeia de Suprimentos
- Limitar taxa de login e endpoints caros. Contadores Redis quando multi-instância.
- Executar
cargo auditecargo denyem CI. Falhar em avisos críticos. - Commit
Cargo.lockpara aplicações. Builds reproduzíveis. - Verificar novas dependências em PR. cargo vet ou checklist de revisão de segurança.
- Cabeçalhos de segurança em respostas HTTP. CSP,
X-Content-Type-Options,frame-ancestors.
FAQs
Maior erro de segurança em produção?
Falta de autenticação em uma nova rota e log de segredos em rastreamentos de depuração.
Segurança de memória do Rust é suficiente?
Não - falhas lógicas, injeção e bugs de autenticação ainda acontecem.
Pilha de autenticação mínima?
Senhas argon2 ou OIDC + validação JWT + HTTPS + limites de taxa.
OpenAPI público?
Desativar ou proteger em produção; expõe o mapa da superfície de ataque.
Cadência de teste de penetração?
Anualmente ou antes do lançamento público principal; corrigir descobertas por gravidade.
SBOM exigido?
Cada vez mais para clientes corporativos - cargo cyclonedx.
código `unsafe`?
Isolar em crate auditado; #![forbid(unsafe_code)] no binário da API se a política permitir.
Exclusão GDPR?
Documentar mapa de dados; cascatear exclusão de tokens, chaves de cache e política de backups.
Campeões de segurança?
Um proprietário revisa PRs sensíveis à segurança semanalmente.
Runbook de incidentes?
Revogar tokens, rotacionar segredos, habilitar logging aprimorado, notificar clientes conforme política.
Relacionados
- Noções Básicas de Design de API - Convenções REST
- JWT e OAuth2 - Fluxos de token
- Validação de Entrada e Injeção - Defesas contra ataques
- Segurança da Cadeia de Suprimentos - Auditoria de dependências
- Melhores Práticas de Backends Web - Regras de serviço HTTP
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4 e Polars 0.46+.