En el mundo real, una API rara vez vive sola. Detrás hay reverse proxies, WAFs, balanceadores, contenedores, colas, bases de datos, observabilidad, CI/CD y, casi siempre, más de un equipo tocando piezas distintas. Por eso, cuando una API cae o se filtra información, el problema suele estar en la frontera entre dos mundos: el código y la infraestructura.
Esta guía está pensada para administradores de sistemas y programadores que operan y mantienen APIs en producción. No pretende sustituir un marco completo (OWASP, CIS, NIST), sino ofrecer un checklist práctico de medidas que se pueden aplicar hoy: desde el borde (proxy/CDN) hasta el backend.
1) HTTPS + TLS moderno: no basta con “tener candado”
Para desarrollo:
- Asegurar que todas las rutas se sirven por HTTPS y que no existen endpoints “auxiliares” en HTTP.
- Validar correctamente el esquema cuando hay proxies (
X-Forwarded-Proto) y evitar redirecciones en bucle o falsos positivos.
Para sistemas:
- Forzar TLS 1.3 cuando sea posible (o 1.2 como mínimo).
- Activar HSTS para evitar downgrades.
- Deshabilitar cifrados débiles y mantener bibliotecas criptográficas actualizadas.
- Revisar certificados, rotación y automatización (ACME si aplica).
En APIs internas también: el “es solo interno” es uno de los grandes mitos que terminan en incidentes.
2) Autenticación: tokens que expiran, validación estricta y trazabilidad
Buenas prácticas comunes:
- OAuth 2.0 / OIDC cuando hay ecosistemas de apps.
- Tokens de corta duración (y refresh tokens con rotación).
- Validación completa de tokens: firma, emisor, audiencia, expiración, y tolerancia de reloj.
Puntos de fricción típicos en producción:
- JWT aceptados sin validar
audoiss. - Tokens largos “por comodidad”.
- Endpoints de refresh sin rate limit.
Para sysadmins, esto se traduce en políticas: quién emite tokens, dónde se almacenan claves de firma, cómo se rota el material criptográfico y cómo se audita.
3) Autorización: el fallo silencioso (IDOR/BOLA)
Aquí se cae más gente de la que reconoce. Es el clásico: el usuario tiene sesión válida, pero accede a recursos que no debería.
Medidas:
- Control de acceso por roles (RBAC) o atributos (ABAC), según el caso.
- Verificación por recurso: no basta con “está logueado”.
- Revisiones periódicas de permisos y endpoints.
Desde sistemas, conviene medir y alertar: picos de 403, rutas que se convierten en objetivo y patrones de enumeración.
4) Rate limiting y throttling: en el borde primero
En APIs reales, el rate limit en la app está bien, pero el primer filtro suele ser el reverse proxy o API gateway.
Recomendaciones:
- Limitar por IP + por token + por cliente (si hay client_id).
- Endpoints sensibles con límites propios: login, reset, búsqueda, exportaciones.
- Respuestas 429 consistentes y soporte de “backoff” en clientes.
Para sysadmins: poner el control en el borde evita que el backend “pague” CPU y DB por tráfico basura.
5) Validación de entrada y límites duros (no solo “sanitize”)
Desde desarrollo:
- Validación estructural con esquemas (OpenAPI/JSON Schema).
- Tipos estrictos, allowlists, validación de formatos y longitud.
Desde sistemas:
- Limitar tamaño de body, cabeceras, número de parámetros y timeouts en proxy.
- Control de cargas (uploads) con límites y antivirus/escaneo si aplica.
- Prevenir payloads masivos que convierten tu API en un generador de costes.
Esto protege tanto de inyecciones como de ataques de agotamiento (DoS lógico).
6) Errores y respuestas: menos información, mejor operación
Una API que devuelve stack traces o errores SQL está enseñando el mapa interno.
Buenas prácticas:
- Mensajes genéricos hacia el cliente y detalle solo en logs internos.
- Desactivar debug en producción.
- Códigos HTTP coherentes (400/401/403/404/429/500), sin “inventar”.
Para sysadmins: normalizar el formato de error facilita correlación en logs y reduce ruido en alertas.
7) Observabilidad: logs útiles sin filtrar secretos
Qué conviene registrar:
- request-id/correlation-id, ruta, método, status, latencia, tamaño de respuesta.
- Identidad del cliente (si existe), user_id, app_id, IP (con criterio legal).
Qué nunca:
- Tokens, cookies, contraseñas, API keys, datos sensibles.
Y lo importante: alertas accionables:
- picos de 401/403/429
- aumento de 5xx
- latencias anómalas
- patrones de enumeración o scraping
En producción, monitorizar no es “por si acaso”: es parte del control de daños.
8) Dependencias, imágenes y parches: la cadena de suministro
Para desarrolladores:
- Auditorías de dependencias (npm/pip/maven) y lockfiles.
- Eliminar dependencias innecesarias.
Para sistemas:
- Escaneo de imágenes (base images incluidas) y actualización planificada.
- Parches de runtime y sistema (OpenSSL, glibc, kernels, etc.).
- Política de “ventana de parcheo” para CVEs críticas.
Muchas brechas empiezan por “no tocamos eso porque funciona”.
9) Secretos y configuración: fuera del repositorio, rotación y mínimo privilegio
La gestión de secretos ya no puede ser artesanal.
Buenas prácticas:
- Secret manager (Vault o equivalentes cloud).
- Service accounts con privilegios mínimos por entorno.
- Rotación de claves y auditoría de accesos.
- Prohibir secrets en repos y en imágenes.
Esto reduce impacto si hay filtración de CI/CD, backups o artefactos.
10) Controles de infraestructura: WAF, mTLS interno y segmentación
Dos medidas que suelen marcar la diferencia cuando la API crece:
WAF / API gateway
- Bloqueo de patrones comunes, reputación de IPs, reglas por endpoint.
- Control de bots y scraping.
mTLS y segmentación interna (cuando aplica)
- mTLS entre servicios críticos.
- Redes segmentadas y políticas de egress (no todo debe hablar con todo).
- “Zero trust” realista: al menos, limitar movimientos laterales.
No siempre es necesario desde el día uno, pero en entornos sensibles suele ser el salto natural.
Checklist rápido “sysadmin + dev” antes de un despliegue
- HTTPS forzado + TLS moderno + HSTS.
- Tokens cortos y validados correctamente (
iss,aud,exp). - Autorización por recurso (anti IDOR/BOLA).
- Rate limit en borde + límites por endpoint.
- Límites de tamaño/timeout en proxy y backend.
- Errores sin información interna.
- Logs con request-id, sin secretos, con alertas útiles.
- Dependencias e imágenes auditadas y parcheadas.
- Secretos en un gestor dedicado y rotación.
- WAF/gateway y segmentación si la criticidad lo exige.
Preguntas frecuentes (FAQ)
¿Dónde es mejor aplicar el rate limiting: en la app o en el proxy?
En ambos, pero el primer control suele ser el proxy/API gateway: filtra antes de gastar CPU y DB en el backend.
¿Qué es el fallo IDOR/BOLA y por qué es tan común?
Es cuando un usuario autenticado accede a recursos ajenos cambiando identificadores (por ejemplo, user_id o invoice_id). Ocurre cuando la autorización no se valida por recurso.
¿Qué debería monitorizar un sysadmin para detectar ataques a una API?
Picos de 401/403/429, crecimiento de 5xx, latencias anómalas, rutas “calientes” por endpoint, y patrones de enumeración (muchos IDs distintos en poco tiempo).
¿Qué medida da más retorno rápido para una API ya en producción?
Si hay que elegir una: rate limiting en el borde + logs/alertas bien hechos. Reduce abuso y mejora el tiempo de respuesta ante incidentes.
