Cómo el casino supervisa la seguridad de las solicitudes de API

Por qué la seguridad de la API en iGaming es crítica

API - sistema nervioso del casino: apuestas, billetera, taquilla, proveedores de juegos, KYC/KYT, telemetría. Cualquier agujero = dinero, PII, licencia, reputación. A diferencia de los e-commerce convencionales, los casinos tienen características: dinero en tiempo real, regulación, alta motivación de los atacantes y una compleja matriz de integración.

Principios arquitectónicos («esqueleto» de protección)

1. Zero-Trust & Least Privilege. No confiamos ni en la red ni en los clientes. Cada llamada es verificada, los accesos son los mínimos necesarios (RBAC/ABAC).

2. Separación de dominios. Dinero/PII/taquilla/pasarelas de juego - diferentes perímetros y redes, diferentes claves y políticas.

3. Puerta de enlace única API. Punto: mTLS, WAF/bot management, OAuth2/JWT, rate limits, threat-feeds, lógica.

4. Observabilidad predeterminada. Treking, correlación 'traceId', alertas a anomalías (SLO/SIEM).

5. Impagos seguros. Fichas TTL cortas, prohibición de «ancho» CORS, deny-by-default en NetworkPolicy.

Autenticación y autorización

Llamadas interservicios: mTLS + JWT de vida corta (5-10 min) con 'aud/iss/kid' y rotación de claves; opcionalmente firma HMAC del cuerpo.

Llamadas al cliente: OAuth2 (PKCE para móviles), cookies de sesión con 'HttpOnly', 'SameSite = Lax	Strict`, `Secure`.
Administración/API de sapport: SSO + MFA, IP-allowlist, privilegios - sólo por roles.
Pagos/operaciones críticas: principio de 4 ojos y paso de confirmación.

Integridad de la llamada: firmas, tiempo, idempotencia

Firma HMAC de la solicitud de presentación canonizada: ordenamiento de parámetros, serialización estable de JSON (sin espacios innecesarios, el mismo orden de claves), encabezados:


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…

Protección de respuesta: ventana de tiempo válida (± 300 segundos), comprobación de 'nonce' en la caché.

Idempotency-Key para dinero/webhooks: la repetición de la solicitud no crea un segundo débito/crédito.

mTLS al monedero/cajero/proveedores: encriptación de transporte + verificación mutua de las partes.

Ejemplo 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"
}

Validación de entrada: circuitos y canonicalización

JSON Schema/OpenAPI como contrato. Cualquier cadena es a través de la validación de tipos, rangos y whitelists (códigos ISO de monedas/países, enum de estados).

Límites de tamaño: limitar el tamaño del cuerpo y las matrices, prohibir los anidamientos «profundos».

Canonicalización de JSON antes de la firma/logs, blindaje de vehículos especiales, riguroso 'Content-Type'.

Bloqueo de asignación masiva (mass assignment): allow-lists explícitos de campos.

Protección de superficie: WAF, bots, velocidad

WAF/bot management: firmas e identificación del comportamiento (rate, geo, device-fingerprint).

Rate limits/quotas: por IP/token/cliente/método; límites individuales de dinero y no-dinero.

DoS/abuse-control: circuit-breakers, timeouts, backpressure, «listas grises».

CORS: puntos 'Access-Control-Allow-Origin', prohibición de comodines y 'Authorization' en navegadores sin necesidad.

OWASP API Top-10 → medidas específicas

BOLA/BFLA (Broken Object/Function Level Auth): ABAC por propietario del recurso, filtros por 'playerId', prohibición de identificadores «ajenos».

Inyección/SSRF: consultas parametrizadas, denegación de URLs externas en llamadas de servidor, hosts allowlist.

Excessive Data Exposure: shaping response (fields mask), paginación, normalización de errores sin filtrar detalles.

Misconfiguración de seguridad: unidad de versiones TLS/cifrado, encabezados CSP/Permissions-Policy/Referrer-Policy.

Consumo seguro de APIs: envolturas sobre APIs providenciales con temporizadores, retraídas, deduplicación.

PII y privacidad

Tokenización y cifrado PII (atributos del jugador, documentos KYC): KMS/HSM, campos - AES-GCM.

Minimización de datos: en eventos/registros - sólo alias ('playerId'), nunca - números de documentos/tarjetas.

Retention: TTL diferente para dominios (monedero/juego/caja registradora) según los requisitos de las jurisdicciones.

Acceso por roles: Delimitación de la lectura de PII en el nivel de BD y servicios (seguridad de nivel de fila/políticas).

Webhooks y cajeros seguros

Verificación de dos factores: mTLS a webhook + firma HMAC del proveedor.

Anti-respuesta: 'X-Idempotency-Key', 'X-Timestamp', una ventana de tiempo.

Allowlist IP/ASN del proveedor, egresos-IP salientes estáticos con nosotros.

Payloads «venenosos»: límites de cota, ignorar campos no utilizados, esquema estricto.

Auditoría y prueba de endpoint: sandbox del proveedor + pruebas contractuales.

Secretos y llaves

Almacenamiento: KMS/HSM/Secrets-manager, nunca en git/variables de entorno sin cifrado.

Rotación: automática, 'kid' en encabezados/metadatos, revocación de claves comprometidas.

Acceso: break-glass procedimientos, registro de todas las llamadas a secretos.

Registros, tracks, alertas

Correlación: 'traceId/requestId/playerId/roundId' en cada capa (ingress → API → billetera → proveedor → webhook).

Anomalías: estallido de '401/403/429', crecimiento de 'VOID', saltos 'bet. reject 'por región, fallas HMAC/mTLS.

Señales de ataque: muchos 'nonce' -ovitores, intentos de los viejos 'timestamp', cuerpos largos, desconocidos 'kid'.

Almacén de registros: inmutable (WORM), zona de acceso independiente, enmascaramiento PII.

Plan de prueba y control de calidad

Static/Dynamic AppSec: SAST/DAST en cada CI, firmas de secretos, dependencias - SCA.

Pentests y red-tim: scripts replay, firma en el canal incorrecto, bypass rate-limits, BOLA, SSRF.

Pruebas contractuales: en OpenAPI/JSON-Schema, «casos negativos».

Chaos/latency drills: comportamiento en los tiempos de espera de los proveedores/caja registradora, idempotencia correcta.

Bug-bounty: un programa con un perímetro separado y reglas de reportaje.

Títulos y configuraciones útiles

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

`Content-Security-Policy: default-src 'none'; frame-ancestors 'none "(para dominios API)

`Referrer-Policy: no-referrer`

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

`X-Content-Type-Options: nosniff`

'Cache-Control: no-store' en endpoints privados

Respuestas de error: formato único

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

Anti-patrones (que rompe la seguridad)

Tokens JWT/refresh de larga vida sin rotar ni enlazar con el dispositivo.

Firma «tal cual» sin canonicalización JSON → controles de salida.

La ausencia de 'Idempotency-Key' en el dinero/webhooks → cargos dobles.

Wildcard-CORS y "in 'Access-Control-Allow-Origin' para endpoints con 'Authorization'.

Logs con PII/secretos, compartiendo logs «para todos».

Una única clave HMAC compartida para todas las integraciones.

No hay límites en el tamaño/profundidad de JSON, no hay temporizadores y circuitos-rompecabezas.

Errores que revelan detalles internos (stack traces, SQL, versiones de bibliotecas).

Lista de verificación de seguridad de la API del casino

Perímetro y transporte

mTLS en canales entre servicios y proveedores; TLS 1. 3 en todas partes.
Puerta de enlace API con WAF/bot management, rate limiting, threat-feeds.
CORS - sólo direcciones, sin comodín.

Autenticación/autorización

OAuth2/OpenID para clientes, JWT con TTL ≤ 10 min, rotación de llaves ('kid').
RBAC/ABAC por dominios; admin - SSO + MFA + IP-allowlist.

Integridad y consultas repetidas

Firma HMAC, 'X-Request-Timestamp', 'X-Request-Nonce' y ventana de tiempo.
'X-Idempotency-Key' en dinero, webhooks, taquilla; almacenar las claves en la caché.

Validatsiya

OpenAPI/JSON-Schema, canonicalización JSON, límites de tamaño/profundidad.
Enmascaramiento y whitelists para campos; prohibición de mass assignment.

PII y datos

Tokenización/cifrado PII (KMS/HSM), minimización, políticas de retención separadas.
Almacenamiento dividido para PII/telemetría/dinero.

Integraciones

Webhooks: mTLS + HMAC, allowlist IP, anti-replay, pruebas contractuales.
Caja/cripta: dos proveedores y diferentes llaves/redes, idempotency en la entrada/salida.

Observabilidad

Senderismo con 'traceId/playerId/roundId', alertas a las señales de ataque.
Los registros son inmutables (WORM), sin PII/secretos.

Procesos

SAST/DAST/SCA en CI, pentests/red-tim regularmente, bug-bounty.
Incidentes de Runbooks: revoke claves, retroceso, comunicaciones.

La seguridad de la API en iGaming no es «poner WAF». Se trata de un sistema: mTLS + firmas + idempotencia, validación y canonicalización rigurosas, protección perimetral y de velocidades, aislamiento PII, webhooks de taquilla segura, observabilidad e inspecciones regulares. Al hacerlo parte de la cultura de ingeniería, protege el dinero, los jugadores y la licencia, al tiempo que mantiene la velocidad del producto y la estabilidad de los lanzamientos.