Segurança da API e filtragem de consultas

1) Por que é necessário

API - borda externa e interna da plataforma. Qualquer erro de autenticação, autorização, validação ou normalização de solicitações se transforma em operação de vulnerabilidades (BOLA/IDOR, inhation, SSRF, sobrepreço em massa, exaustão de recursos). O objetivo é criar uma proteção de vários níveis (defense-in-depth) do perímetro às regras empresariais, com SLO mensurável e controle de risco.

2) Inventário e classificação da API

Catálogo API: registro de todos os serviços/endpoint, proprietários, versões, tipos de clientes (web, mobile, associados), modo (público/sócio/interno), PII/finded.
Crítica: High (transações financeiras/autorizações), Medium (leitura de perfil), Low (guias públicos).
Superfície de ataque: REST, GraphQL, gRPC, WebSocket, webhooks.
Estado: prod/estaging/experimental, política de deprekate, vida de tokens/chaves.
Shadow/API abandonada: detecção de logs no ingrete, eBPF/Service Mesh telemetria, comparado com o catálogo.

3) Modelo de ameaças (breve)

Identificação: roubo de tokens, fixação de sessão, MitM, replay.
Autorização: BOLA/IDOR, escalação horizontal/vertical.
Entrada: injeções (SQL/NoSQL/LDAP), padrão/serilização, path traversal, cabeçalhos.
Tráfego: DDoS/L7-Fluds, consultas lentas, retraias fantasmas.
Integrações: webhooks não seguros, SSRF através de configurações de URL, downloads de arquivos/raias.
Lógica: abuso de bónus, corrida, idempotidade incoerente.

4) Padrão básico de segurança (mínimo)

1. TLS 1. 2 + por todo o lado; HSTS; Os códigos fracos foram desligados.
2. Autenticação: OAuth2/OIDC para clientes, mTLS/ou HMAC - serviço-K.
3. Autorização: PDP centralizado (RBAC/ABAC), verificação de objeto (BOLA).
4. Validação: esquema rigoroso (OpenAPI/JSON Schema/Protobuf), rejeição em campos extras.
5. Os limites são rate/cotas + burst, para-cliente/para-IP/para-token.
6. Idempotidade em operações write, proteção contra repetições/corridas.
7. Filtragem WAF/gateway: normalização de caminhos/cabeçalhos, folhas deny, bloco payload-anti-pattern.
8. Segredos: KMS/Vault, rotação de chaves/certificados, controle de vazamentos.
9. Rastreamento, auditoria-logs de segurança (quem/o/quando/o resultado), alertas.
10. Procedimentos: playbook incidentes, malas de teste e pentestes regulares/DAST.

5) Autenticação e gerenciamento de torneios

OAUTh2/OIDC: tokens de curta duração, refresh com OIDC; audience/issuer/exp são testados em gatway.
JWT: RS256/ES256; um conjunto mínimo de claimes; 'nbf/exp/aud' são obrigatórios; proibição de armazenamento de PII. Rotação de chaves via JWKS.
DPoP/PoP: Alinhar o tocador à chave do cliente para reduzir o risco de reprodução/roubo.
mTLS para sistemas internos e parceiros de confiança (avaliação CN/SAN, CRL/OCSP).
HMAC (assinaturas): canonização definida (método + caminho + timestamp + nonte + body-hash); Janela de Tempo Permitido (£300s).
Sessões do navegador: SameSite=strict/lax, HttpOnly, Secure; Proteção contra CSRF (duplo submit/token state).
Armazém cliente: no celular - armazenamento seguro (Keychain/Keystore), proteção contra debag, pinning certificados.

6) Autorização (BOLA-first)

Object-level: Cada operação verifica o direito a um recurso específico (resource owner/scope/atributos).
RBAC/ABAC: rol + atributos (país, segmento, limite de risco, nível KYC).
Políticas: deny-by-default; allow explícito; versionização de políticas; Testes de mala negativa.
Solução kesh: TTL adaptativo + deficiência quando os papéis/segmentos são alterados.

7) Filtrar e normalizar solicitações (por gatway/WAF)

Normalização: compressão de barras repetidas, proibição de '../', decodificação uma vez, corte de espaços/zero-bytes.
Os cabeçalhos são allow-list («Hosts',» Conteúdo-Tipo «,» Aceitt', «Autorization», «Data», «Idempotency-Key», cabeçalhos trace).
Métodos: 'GET/HEAD' sem corpo; 'POST/PUT/PATCH' - com 'aplicação/json' ou estritamente permitidos.
Dimensões: max-body, max-headers, max-path; early-reject 413/431.
Arquivos: Validador MIME, antivírus/sandbox, proibição de conteúdo ativo, ressaiz/saneamento de imagens.
URL/fetches: bloco SSRF (deny private ranges/metadata IP, esquema apenas «https», allow-list doms).
SQL/NoSQL-Pattern: assinaturas de injeção via WAF rule-sets + configuração de solicitação por servidor.

Exemplo de política de cabeçalho (formato pseudo)

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Limites, quotas e proteção antibot

Rate limiting: token-bucket/ leaky-bucket; níveis - per IP, per API key, per usuário, per org.
Cotas: diárias/mensais, separadas para métodos write/expensive.
Adaptabilidade: endurecimento dinâmico para anomalias (sudden burst/credential stuffing).
Slow-loris/slow-POST: tempo de leitura/keep-alive, restrição de conexões paralelas.
Antibot: device-fingerprint, sinais comportamentais, proof-of-work/capcha para risco elevado, lista de tor/redes proxy.
Controle de IP: filtros geo/ASN, folhas deny «sujas», folhas de alow para associados/painéis.

9) Validação de dados e esquemas de entrada

Fail-closed: Tudo o que não passa pelo esquema é 400. Os campos extras são para rejeitar.
Tipos/faixas: números, datas (UTC/ISO-8601), valores enum, comprimento de linha, regexos.
Qualidade JSON: max-nesting, proibição de grandes matrizes/chaves, canonical order (opcional).
Validação de negócios: Idempotidade por 'Idempotency-Key'; regras anti-frod (limites de frequência de operações, amount caps).
GraphQL: depth/complexity-limites, allow-listed queries, para-campo de autorização.
gRPC: esquemas Protobuf rigorosos, campos obrigatórios, limites de tamanho de mensagens.

10) Webhooks e chamadas externas

Assinaturas: HMAC com temporizador/nonce; verificação antes do processamento; janela +/- 5 min

Entrega: Retraias com pausa exponencial e jitter; max-tentativa; Deduplicação com ID de evento.
IP allow-list do fornecedor; falso/caminho individual; Uma pilha mínima de hospedagem.
Respostas: 2xx somente após a gravação interna de sucesso; senão 4xx/5xx com código compreensível.
Controle SSRF de saída: ao callback URL - allow-list, não é permitido endereços privados.

11) Criptografia e gerenciamento de segredos

No canal: TLS 1. 2+/1. 3, pinning, política de código rigorosa.
Em paz: criptografia de BD/armazenamento de objetos, chaves individuais para PII/finded.
KMS/Vault: armazenamento centralizado de segredos, TTL curto, rotação automática.
Chaves e certificados: separados para ambientes; auditoria das emissões; Não permitir a entrada nos logs.
Token-introspation: listas de revogação offline (revocation), curtas 'exp'.

12) Observação, auditoria e resposta

Logs de segurança: tentativas/avanços de autenticação, falhas de autorização, eventos rate-limit, alterações de papéis/limites.
Traçado: correlation-ID de passagem; Rastreamento de chamadas externas.
Métricas: RPS, P95/P99 latency, error-rate, proporção de 401/403/429, hit-rate limites, anomalias.
Alerts: picos de 401/403/429, crescimento de 5xx, conflitos de idempotency frequentes, desvios acentuados de grafQL-complexity.
Playbooks: bloqueio de chaves/tokens, reversão rápida de regras, aquecimento da folha deny, notificação dos donos de serviços.
Forenzica: Preservação de payload controverso (com edição segura do PII), replica em estande isolado.

13) Erros e respostas ao cliente

Um único formato de erro (código, mensagem, trace-id, categoria).
Sem vazamentos: não revelar SQL, nomes de tabela, idis internos; 403 em vez de «porquê não».
Códigos: 400 (validação), 401 (nenhuma autenticação), 403 (nenhuma habilitação), 404 (camuflar existência), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; para Idempotação, um conselho de repetição com a mesma chave.

14) Patrões arquitetônicos

Zero-Trust: mTLS, autorização explícita entre todos os serviços, privilégios mínimos.
Entrada API + WAF + serviço-mesh: divisão de responsabilidades - perímetro, políticas L7, autenticação interna.
Canary/Blue-Green: descolar novas regras de filtragem em etapas com observação.
Fail-closed: Para write crítico, é melhor falhar em segurança do que permitir uma cirurgia incorreta.
Backpressure: filas/tampões, circuito breaker, timeouts/budgets.

15) Exemplos de regras práticas (pseudo-config)

15. 1 Limitação de caminhos e métodos

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 Idempotidade

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 Assinatura do pedido (HMAC)

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. Proteção SSRF 4

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL limite

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Especificidades do iGaming/Finanças

Limites segmentais: dependem do CUS/país/perfil de risco.
Janelas de tempo: regras de taxa de depósito/conclusão, «resfriamento» entre transações.
Bónus anti-abuse: bloqueios consistentes para conta/dispositivo/IP/ferramenta de pagamento.
Auditoria dos requisitos dos reguladores: armazenamento de logs de ação e solução (KYC/AML), períodos de retenção, registros imutáveis.

17) Lista de controle pró-prontidão

• Diretório completo de API e mapa de fluxo de dados (PII/finanças marcadas).
• Adobe API/Protobuf, testes de validação e contratos em CI.
• mTLS/HMAC/OAuth2 configurados; TTL KTL; Rotação de chaves.
• Testes de BOLA e malas de autorização negativas; PDP centralizado.
• Limites/quotas/anti-bot, proteção contra slow-loris; Filtros IP.
• Regras de normalização WAF/gateway, assinaturas anti-injecção.
• Idempotidade das operações write; proteção contra replay.
• Assinaturas webhook e allow-list; endpoints isolados.
• Segredos no KMS/Vault; storajs encriptados; Alertas para anomalias.
• Dashboards, alertas, auditorias; incidentes playbooks trabalhados.
• Penteste regular/DAST/SAST, trechos de vulnerabilidade e depósito de patches.

18) Antipattern (o que não pode)

Confiar em 'X-Forwarded-' sem a terminação rígida do TLS no seu perímetro.
Aceitar os esquemas de JSON «Conteúdo-Tipo» e «suave» aleatórios.
JWT longa vida sem reversão/rotatividade.
Misturar papéis e regras de negócios em código sem políticas centralizadas.
Logs com segredos/PII; Mensagens detalhadas de 500 para fora.
Endpoints abertos temporariamente, sem limites ou permissões.

19) Versionização e decolagem

Versões no caminho/cabeçalho; política de suporte (por exemplo, N-2).
Anúncios: prazo de decolagem, monitoramento do uso de versões antigas, desligamento controlado.
Compatibilidade: contratos e matrizes de teste de clientes/parceiros.

20) Testes de segurança

Testes contratuais de esquemas/políticas, entradas fuzzing, negative auth.
Perfis perfomance com limites/quotas, teste de bloqueio (chaos-tráfego).
Red-team/bug-bounty: cenários BOLA, SSRF, assinaturas/réplicas, GraphQL-complexity.

TL; DR

1. Catálogo API + esquemas rigorosos.
2. OAuth2/OIDC para clientes mTLS/HMAC internamente.
3. Perímetro de BOLA por recurso (ABAC/RBAC).
4. Filtragem: normalização de caminhos/cabeçalhos, limites, regras WAF.
5. Idempotidade, assinaturas, proteção contra replay/SSRF.
6. KMS/Vault e rotação de segredos.
7. Observabilidade, alertas, playbooks.