Como o Casino monitora a segurança das APIs

Por que a API de segurança é iGaming crítica

API - sistema nervoso do casino: apostas, carteira, caixa, provedores de jogos, KYC/KYT, telemetria. Qualquer buraco = dinheiro, PII, licença, reputação. Ao contrário do e-commerce convencional, o casino tem características: real-tempo de dinheiro, regulação, alta motivação de atacantes e matriz complexa de integração.

Princípios arquitetônicos («esqueleto» de proteção)

1. Zero-Trust & Least Privilege. Não confiamos na rede, nem nos clientes. Cada chamada é verificada e as acessíveis são minimamente necessárias (RBAC/ABAC).

2. Divisão de domínios. Dinheiro/PII/caixa/hall de jogos - diferentes perímetros e redes, diferentes chaves e políticas.

3. Uma única porta de API. Ponto: mTLS, WAF/bot management, OAuth2/JWT, rate limits, threat-feeds, loging.

4. Observabilidade padrão. Tracing, correlação 'traceId', alertas em anomalias (SLO/SIEM).

5. Incumprimento seguro. TTL de toques curtos, proibição de «amplo» CORS, deny-by-default em NetworkPolicy.

Autenticação e autorização

Chamadas entre servidores: mTLS + JWT de curta duração (5-10 min) s 'aud/iss/kid' e rotação de chaves; opcional para a assinatura corporal HMAC.

Chamadas de cliente OAuth2 (PKCE para celulares), sessão cookies com 'HttpOnly', 'SameSite=Lax	Strict`, `Secure`.
Admin/API saforta: SSO + MFA, IP-allowlist, privilégios para apenas papéis.
Pagamentos/operações críticas: princípio de quatro olhos e etapa de confirmação.

Integridade da chamada: assinaturas, tempo, idempotação

A assinatura HMAC do pedido de apresentação canonizada: triagem de parâmetros, serialização estável do JSON (sem espaços, ordem de chaves idêntica), cabeçalhos:


X-Request-Timestamp: 2025-10-17T14:22:05Z
X-Request-Nonce: 8c1c...fa
X-Request-Signature: v1=HMAC-SHA256:base64(…)
X-Idempotency-Key: c0a4-77f…

Protecção replay: janela de tempo válida (£300 segundos), verificação de 'nonce' no cachê.

Idempotency-Key para dinheiro/webhooks: Uma repetição de pedido não cria um segundo débito/crédito.

mTLS para carteira/caixa/provedores: criptografia de transporte + verificação mútua das partes.

Exemplo de POST protegido:


POST /wallet/debit
Content-Type: application/json
X-Request-Timestamp: 2025-10-17T14:22:05Z
X-Request-Nonce: 8c1c0cfa
X-Idempotency-Key: 9a7f-2b1c
X-Request-Signature: v1=HMAC-SHA256:Z2V…==
{
"playerId":"p_123",  "amount":"10. 00",  "currency":"EUR",  "reason":"bet. place",  "roundId":"R-2025-10-17-PRAGM-12"
}

Validação de entrada: esquemas e canonização

A JSON Schema/OpenAPI como um contrato. Qualquer linha é através da validação de tipos, faixas e whitelistas (códigos ISO de moedas/países, enum estatais).

Size limits: limitação do tamanho do corpo e das matrizes, proibição de anexos «profundos».

Canonização do JSON antes da assinatura/logs, ecrã especial, rigoroso 'Content-Estando'.

Bloquear atribuição maciça (mass assignment): campos alow-lists explícitos.

Proteção da superfície: WAF, bots, velocidade

WAF/bot management: assinaturas e detecção comportamental (rate, geo, device-fingerprint).

Rate limits/cotas: por IP/token/cliente/método; limites individuais para dinheiro e não-dinheiro.

DoS/abuse-controle: circuito-breakers, timeouts, backpressure, «listas cinzentas».

CORS: pontos 'Access-Control-Allow-Origin', proibição wildcard e 'Autorization' em cruzados de navegador sem necessidade.

OWASP API Top-10 → medidas específicas

BOLA/BBLA (Broken Object/Funcition Level Auth): ABAC para o dono do recurso, filtros por 'playerId', proibição de identificadores «alheios».

Inhation/SSRF: Consultas personalizadas, exclusão de URL externos em chamadas de servidor, alowlist de hosts.

Excessive Data Exposure: shaping de respostas (fields mask), paginação, normalização de erros sem vazamento de peças.

Segurança Misconfiguration: unidade de versões TLS/cifra, títulos CSP/Percussões-Policy/Referrer-Policy.

Unsafe Consumition of APIs: embrulhos sobre API de provedor com temporizadores, retais, dedução.

PII e privacidade

Tocando e criptografando PII (atributos de jogador, documentos KYC): KMS/HSM, campos - AES-GCM.

Data minimization: em eventos/logs - apenas pseudônimos ('playerId'), nunca - números de documentos/cartões.

Retenção: TTL diferente para domínios (carteira/jogo/caixa) de acordo com os requisitos de jurisdição.

Acesso por papéis: separação de leitura de PII em BD e serviços (row-level security/políticas).

Webhooks seguros e caixa

Verificação de dois efeitos: mTLS ao webhoop + HMAC do provedor.

Anti-replay: 'X-Idempotency-Key', 'X-Timestamp', janela do tempo.

Allowlist IP/ASN do provedor, egress-IP estático em nós.

Payloads «venenosos»: limites de tamanho, ignorar campos não utilizados, esquema rigoroso.

Auditoria e teste de endpoint, caixa de areia do provedor + testes contratuais.

Segredos e chaves

Armazenamento: KMS/HSM/Secret-Management, nunca em git/variáveis de ambiente sem criptografia.

Rotação: automático, 'kid' em cabeçalhos/metadados, retirada de chaves comprometidas.

Acesso: break-glass procedimentos, registro de todas as consultas de segredos.

Logs, trailers, alertas

Correlação «traceId/requestId/playerId/roundId» em cada camada (ingress → API → carteira → provedor → webhook).

Anomalias, «401/403/429», «VOID», «bet». reject 'por região, inconclusão HMAC/mTLS.

Sinais de ataque: muitos 'nonce' - provadores, tentativas antigas 'timestamp', corpos longos, 'kid' desconhecidos.

Armazenamento de logs: inatingível (WORM), área de acesso separada, camuflagem PII.

Plano de teste e controle de qualidade

Static/Dinamic AppSec: SAST/DAST em cada CI, assinaturas de segredos, dependências - SCA.

Pentestes e Red Tim: cenários replay, assinatura no canal errado, contornação rate-limits, BOLA, SSRF.

Testes contratuais, «negative cases».

Chaos/latency drills: comportamento em temporizações de provedores/caixa, idempotação correta.

Bug-bounty: programa com perímetro separado e regras de reportagem.

Títulos e configurações úteis

`Strict-Transport-Security: max-age=63072000; includeSubDomains; preload`

`Content-Security-Policy: default-src 'none'; frame-ancestors 'none' (para domínios API)

`Referrer-Policy: no-referrer`

`Permissions-Policy: geolocation=(), microphone=(), camera=()`

`X-Content-Type-Options: nosniff`

'Cachê-Controle: no-store' em endpoentes privados

Respostas de erro: formato único

json
{ "error":"INVALID_SIGNATURE", "code":"SEC_401", "traceId":"tr_5f1", "ts":"2025-10-17T14:22:06Z" }

Anti-pattern (que quebra a segurança)

Os tokens JWT/refresh de longa vida, sem rotação ou ligação com o dispositivo.

Assinar «como é» sem canonizar a JSON → deslizar verificações.

A ausência de 'Idempotency-Key' em dinheiro/webhooks → pagamentos duplos.

Wildcard-CORS e "em 'Access-Control-Allow-Origin' para endpoints com 'Autorization'.

Logs PII/segredos, compartilhamento de logs «para todos».

Chave HMAC comum para todas as integrações.

Não há limites para o tamanho/profundidade do JSON, nem temporizadores ou circuito-breakers.

Erros que revelam detalhes internos (stack traces, SQL, versões de bibliotecas).

Folha de segurança API do casino

Perímetro e transporte

mTLS nos canais entre servidores e provedores; TLS 1. Em todo o lado.
Gateway API com WAF/bot management, rate limiting, threat-feeds.
CORS - apenas direcionados, sem wildcard.

Autenticação/Autorização

OAuth2/OpenID para clientes, JWT com TTL ≤ 10 min, rotação de chaves ('kid').
RBAC/ABAC para domínios; admin - SSO + MFA + IP-allowlist.

Integridade e reaproximações

Assinatura HMAC, 'X-Request-Timestamp', 'X-Request-Nince' e janela do tempo.
'X-Idempotency-Key' em dinheiro, webhooks, caixa; armazenamento de chaves no cachê.

Validação

OpenAPI/JSON-Schema, canonização do JSON, limites de tamanho/profundidade.
Camuflagem e whitelists para campos; proibição de mass assignment.

PII e dados

Toquenização/criptografia PII (KMS/HSM), minimização, políticas de retenção individuais.
Armazéns separados para PII/telemetria/dinheiro.

Integração

Webhooks: mTLS+HMAC, allowlist IP, anti-replay, testes contratuais.
Caixa/cripta: dois provedores e diferentes chaves/redes, idempotency para entrada/saída.

Observabilidade

Tracing s 'traceId/playerId/roundId', alertas a sinais de ataques.
Logs inalterados (WORM), sem PII/segredos.

Processos

SAST/DAST/SCA em CI, pentestes/red-tim regularmente, bug-bounty.
Incidentes runbooks revoke chaves, retrocesso, comunicações.

A API segura no iGaming não é «colocar WAF». Este sistema é mTLS + assinaturas + idempotidade, validação rigorosa e canonização, proteção de perímetro e velocidades, isolamento PII, webhooks de caixa seguro, observabilidade e verificações regulares. Fazendo parte da cultura de engenharia, você protege o dinheiro, os jogadores e a licença, mantendo a velocidade do produto e a estabilidade dos lançamentos.