Seguridad de API y filtrado de solicitudes

1) Por qué es necesario

La API es el límite exterior e interior de la plataforma. Cualquier error en la autenticación, autorización, validación o normalización de solicitudes se convierte en explotación de vulnerabilidades (BOLA/IDOR, inyección, SSRF, mamparas masivas, agotamiento de recursos). Objetivo: crear protección multinivel (defense-in-depth) desde el perímetro hasta las reglas de negocio, con SLOs medibles y control de riesgos.

2) Inventario y clasificación de API

Directorio API: registro de todos los servicios/endpoints, propietarios, versiones, tipos de clientes (web, mobile, partners), modo (público/afiliado/interno), PII/findans.
Criticidad: Alta (transacciones financieras/autorización), Media (lectura de perfil), Baja (manuales públicos).
La superficie de ataque es: NAT, GraphQL, gRPC, WebSocket, webhooks.
Estado: prod/staging/experimental, política de deprecat, vida útil de tokens/claves.
APIs shadow/abandonadas: detección a través del Ingrest Logs, eBPF/Mesh Mesh telemetría, comparación con el directorio.

3) Modelo de amenazas (breve)

Identificación: robo de tokens, fijación de sesión, MitM, replay.
Autorización: BOLA/IDOR, escalada horizontal/vertical.
Entrada: inyecciones (SQL/NoSQL/LDAP), plantillas/serilización, path traversal, encabezados.
Tráfico: DDoS/L7-flood, consultas lentas, retraídas fantasma.
Integraciones: webhooks inseguros, SSRF a través de parámetros URL, descargas de archivos/escáneres.
Lógica: abuso de bonificaciones, carreras, incoherencia de idempotencia.

4) Estándar básico de seguridad (mínimo)

1. TLS 1. 2 + en todas partes; HSTS; los cifrados débiles están desactivados.
2. Autenticación: OAuth2/OIDC para clientes, mTLS/o HMAC - servicio-a-servicio.
3. Autorización: PDP centralizado (RBAC/ABAC), verificación a nivel de sitio (BOLA).
4. Validación: esquema estricto (OpenAPI/JSON Schema/Protobuf), falla en campos adicionales.
5. Límites: rate/quotas + burst, per-client/per-IP/per-token.
6. Idempotencia en operaciones de escritura, protección contra repeticiones/carreras.
7. Filtrado WAF/gateway: normalización de paths/heads, deny-sheets, bloque payload-anti-patrones.
8. Secretos: KMS/Vault, rotación de claves/certificados, control de fugas.
9. Observabilidad: seguimiento, auditoría-registros de la seguridad (quién/qué/cuándo/resultado), alertas.
10. Procedimientos: incidentes de playbook, casos de prueba y pentests/DAST regulares.

5) Autenticación y administración de tokens

OAuth2/OIDC: tokens de acceso de vida corta, refresh estrictamente según OIDC; audience/issuer/amb se comprueban en la gateway.
JWT: RS256/ES256; un conjunto mínimo de climas; 'nbf/amb/aud' son obligatorios; Prohibición del almacenamiento de PII. Rotación de claves a través de JWKS.
DPoP/PoP: vincular el token a la clave del cliente para reducir el riesgo de replay/secuestros.
mTLS para sistemas internos y socios de confianza (certificación CN/SAN, CRL/OCSP).
HMAC (firmas): canonicalización determinista (método + ruta + timestamp + nonce + body-hash); ventana de tiempo permitido (± 300s).
Sesiones del navegador: SameSite = strict/lax, HttpOnly, Secure; protección contra CSRF (double submit/state tokens).
Almacenamiento de clientes: en mobile - almacenamiento seguro (Keychain/Keystore), protección contra debags, impresión de certificados.

6) Autorización (BOLA-first)

Objeto-nivel: cada operación valida el derecho a un recurso específico (recursos/scope/atributos).
RBAC/ABAC: roles + atributos (país, segmento, límites de riesgo, nivel KYC).
Políticas: deny-by-default; allow explícito; versionar directivas; pruebas de casos negativos.
Soluciones de caché: TTL adaptativo + discapacidad al cambiar roles/segmentos.

7) Filtrado y normalización de solicitudes (en gateway/WAF)

Normalización: compresión de slashes repetidos, prohibición de '../', decodificación una vez, recorte de espacios/cero bytes.
Encabezados: allow-list ('Host', 'Content-Type', 'Accept',' Authorization ',' Date ',' Idempotency-Key ', títulos trace deseados).
Métodos: 'GET/HEAD' sin cuerpo; 'POST/PUT/PATCH' - con tipo 'application/json' o estrictamente permitido.
Dimensiones: max-body, max-headers, max-path; early-reject 413/431.
Archivos: Validador MIME, anti-virus/sandbox, prohibición de contenido activo, imágenes de resaise/saneamiento.
URL de reenvío/fetch: bloque SSRF (deny private ranges/metadata IP, esquema sólo 'https', allow-list de dominios).
Patrones SQL/NoSQL: firmas de inyección a través de WAF rule-sets + parametrización de solicitudes de servidor.

Ejemplo de política de encabezado (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) Límites, cuotas y protección antibot

Rate limiting: token-bucket/ leaky-bucket; los niveles son per IP, per API key, per user, per org.
Quotas: dietas/mensualidades separadas para los métodos write/expansive.
Adaptabilidad: apriete dinámico en anomalías (sudden burst/credential stuffing).
Slow-loris/slow-POST: tiempos de lectura/keep-alive, restricción de conexiones paralelas.
Antibot: device-fingerprint, signos de comportamiento, proof-of-work/capcha en mayor riesgo, lista de redes tor/proxy.
Control IP: filtros geo/ASN, hojas deny de subredes «sucias», hojas allow para partners/panel de administración.

9) Validación de entradas y esquemas

Fail-cerrado: todo lo que no pasa por el circuito es 400. Campos superfluos - rechazar.
Tipos/rangos: números, fechas (UTC/ISO-8601), valores de enum, longitudes de fila, regexpas.
Calidad JSON: max-nesting, prohibición de grandes arreglos/llaves, orden canónica (opcional).
Validación empresarial: idempotencia por 'Idempotency-Key'; reglas anti-frod (límites de frecuencia de operación, amount caps).
GraphQL: depth/complexity-limites, allow-listed queries, po-campo autorización.
gRPC: esquemas Protobuf estrictos, campos obligatorios, límites de tamaño de mensaje.

10) Webhooks y llamadas externas

Firmas: HMAC con timestamp/nonce; Verificación previa al procesamiento; ventana +/- 5 minutos.
Entrega: retraídas con pausa exponencial y jitter; intentos max; deduplicación por ID de evento.
Lista IP allow del proveedor; subdominio/ruta independiente; pila de alojamiento mínima.
Respuestas: 2xx sólo después de una grabación interna exitosa; de lo contrario, 4xx/5xx con un código claro.
Control SSRF saliente: bajo la URL de callback - allow-list, prohibición de direcciones privadas.

11) Encriptación y administración de secretos

En el canal: TLS 1. 2+/1. 3, pinning, estricta política de cifrado.
En reposo: cifrado de BD/almacenamiento de objetos, claves individuales para PII/Findans.
KMS/Vault: almacenamiento centralizado de secretos, TTL corto, rotación automática.
Claves y certificados: individuales para entornos; Auditoría de las entregas; prohibición de derivar a los registros.
Token-introspection: listas de revocación offline (revocation), cortas 'amb'.

12) Observabilidad, auditoría y respuesta

Registros de seguridad: intentos/aciertos de autenticación, fallos de autorización, eventos rate-limit, cambios de roles/límites.
Seguimiento: correlación-ID de extremo a extremo; trasiego de llamadas externas.
Métricas: RPS, latency P95/P99, error-rate por códigos, fracción de 401/403/429, límites de tasa de éxito, anomalías.
Alertas: ráfagas de 401/403/429, crecimiento 5xx, conflictos de idempotencia frecuentes, desviaciones bruscas de grafoQL-complexity.
Playbooks: bloquear claves/tokens, revertir reglas rápidamente, calentar la lista de deny, notificar a los propietarios de servicios.
Forenzika: preservación de un payload controvertido (con edición PII segura), replay en un stand aislado.

13) Errores y respuestas al cliente

Formato único de error (código, mensaje, trace-id, categoría).
Sin fugas: no revelar SQL, nombres de tabla, aidi interno; 403 en lugar de «por qué no exactamente».
Códigos: 400 (validación), 401 (no autenticación), 403 (no derechos), 404 (enmascarar la existencia), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; para la idempotencia - consejos para repetir con la misma clave.

14) Patrones arquitectónicos

Zero-Trust: mTLS, autorización explícita entre todos los servicios, privilegios mínimos.
API-gateway + WAF + servicio-mesh: separación de responsabilidades - perímetro, políticas L7, autenticación interna.
Canary/Blue-Green: deslizar las nuevas reglas de filtrado por etapas con vigilancia.
Fail-closed: para la escritura crítica, es mejor fallar con seguridad que permitir una operación incorrecta.
Backpressure: colas/búferes, circuit breaker, timeouts/budgets.

15) Ejemplos de reglas prácticas (pseudo-config)

15. 1 Limitación de rutas y métodos

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

15. 2 Idempotencia

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

15. 3 Firma de solicitud (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. 4 protección SSRF

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

15. 5 Límite GraphQL

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Especificidad de iGaming/finanzas

Límites segmentarios: dependen del CCA/país/perfil de riesgo.
Ventanas temporales: reglas de frecuencia de depósitos/retiros, «enfriamiento» entre transacciones.
Bonos antibugs: bloqueos consistentes en la cuenta/dispositivo/IP/herramienta de pago.
Auditoría de requisitos reguladores: almacenamiento de registros de acciones y soluciones (KYC/AML), períodos de retén, registros inmutables.

17) Lista de comprobación de preparación prod

• Directorio API completo y mapa de flujos de datos (PII/finanzas etiquetadas).
• OpenAPI/Protobuf-circuitos, pruebas de validación y contratos en CI.
• mTLS/HMAC/OAuth2 configurados; TTL cortos de tokens; rotación de llaves.
• Pruebas BOLA y casos negativos de autorización; PDP centralizado.
• Límites/cuotas/anti-bot, protección contra slow-loris; Filtros IP.
• Reglas de normalización WAF/gateway, firmas anti-inyección.
• Idempotencia de las operaciones de escritura; Protección contra replay.
• Firmas webhook y allow-list; endpoints aislados.
• Secretos en KMS/Vault; storags encriptados; alertas a las anomalías.
• Dashboards, alertas, registros de auditoría; playbooks de incidentes trabajados.
• Pentest/DAST/SAST regulares, pistas de vulnerabilidad y parches deplay.

18) Antipattern (que no se puede)

Confiar en 'X-Forwarded-' sin la dura terminacion TLS en su perímetro.
Aceptar «Content-Type» arbitrario y circuitos «blandos» JSON.
JWT de larga vida sin revocación/rotación.
Mezclar roles y reglas de negocio en un código sin políticas centralizadas.
Registros con secretos/PII; 500 mensajes detallados hacia afuera.
Endpoints abiertos «temporales» sin límites ni autorización.

19) Versificación y depreciación

Versiones en ruta/título; política de apoyo (por ejemplo, N-2).
Anuncios: plazos de depreciación, monitoreo del uso de versiones antiguas, desconexión administrada.
Compatibilidad: contratos y matrices de prueba de clientes/socios.

20) Pruebas de seguridad

Pruebas contractuales de esquemas/políticas, entradas fuzzing, auth negative.
Perfiles de perfomance con límites/cuotas, prueba de protección (tráfico de chaos).
Red-team/bug-bounty: scripts BOLA, SSRF, firmas/réplicas, GraphQL-complexity.

TL; DR

1. Directorio API + esquemas estrictos.
2. OAuth2/OIDC para clientes, mTLS/HMAC en el interior.
3. BOLA-perímetro por recurso (ABAC/RBAC).
4. Filtrado: normalización de rutas/encabezados, límites, reglas WAF.
5. Idempotencia, firmas, protección de replay/SSRF.
6. KMS/Vault y la rotación de secretos.
7. Observabilidad, alertas, playbooks.