10 prácticas de seguridad imprescindibles para APIs: guía rápida para desarrolladores

Las APIs se han convertido en el pegamento de la economía digital. Conectan aplicaciones móviles, frontends web, microservicios, partners, integraciones y automatizaciones internas. Ese protagonismo tiene un precio: también son una de las superficies de ataque más explotadas.

La mayoría de incidentes no ocurren por ?hackers de película?, sino por fallos cotidianos: endpoints sin control de acceso, tokens eternos, validaciones débiles, errores verbosos o dependencias sin parchear. Esta guía, pensada para lectores de programación que están construyendo APIs en su día a día, repasa 10 prácticas esenciales que reducen drásticamente el riesgo sin convertir el desarrollo en un infierno.

1) HTTPS siempre (y configurado con criterio)

HTTPS no es ?un extra?: es el mínimo. Sin cifrado en tránsito, cualquier actor con acceso a la red puede interceptar o modificar tráfico (credenciales, tokens, datos, respuestas).

Recomendaciones:

• Usar TLS moderno (idealmente TLS 1.3; como mínimo 1.2).

• Forzar redirección de HTTP ? HTTPS.

• Activar HSTS para evitar downgrades (y valorar includeSubDomains si aplica).

• Evitar configuraciones antiguas y suites débiles.

Detalle práctico: si la API está tras un proxy (CDN, balanceador, reverse proxy), conviene revisar cómo se transmite el ?esquema real? (cabeceras tipo X-Forwarded-Proto) para no terminar sirviendo contenido ?creyendo? que va cifrado cuando no lo está.

2) Autenticación robusta y tokens con caducidad real

Una API pública sin autenticación es, casi siempre, una API en problemas. La autenticación debe asegurar que quien llama es quien dice ser y que la sesión no sea fácil de robar o reutilizar.

Buenas prácticas:

• Para ecosistemas con usuarios y apps: OAuth 2.0 + OpenID Connect suele ser la ruta más estándar.

• Si se usan JWT: validar siempre firma, iss, aud, exp, nbf y tolerancias de reloj.

• Tokens de corta duración y con rotación (especialmente refresh tokens).

• MFA en paneles, backoffice y accesos administrativos.

Error típico: ?con que tenga token vale?. Sin validaciones correctas, un token emitido para una audiencia distinta o un entorno equivocado puede acabar aceptándose.

3) Autorización: donde nacen muchos incidentes reales

Autenticación y autorización no son lo mismo:

• Autenticación: ?¿Quién eres??

• Autorización: ?¿Qué puedes hacer y sobre qué recursos??

Claves:

• Aplicar RBAC (roles) o ABAC (atributos) según el modelo de negocio.

• Verificar permisos en cada request, no solo al inicio.

• Proteger el acceso por objeto (evitar el clásico IDOR/BOLA: cambiar un id y leer lo de otra persona).

• Principio de menor privilegio por defecto.

En APIs, la autorización rota suele camuflarse como ?bug funcional?: endpoints que devuelven demasiado, filtros inexistentes o validaciones solo en el cliente.

4) Rate limiting y throttling para resistir abuso y automatizaciones

Las APIs no solo caen por ataques masivos: también por automatizaciones baratas (scripts) que fuerzan endpoints de login, búsqueda, scraping o subida de ficheros.

Estrategias recomendables:

• Rate limiting por IP, por usuario y por token/app.

• Límites específicos por endpoint (más estrictos en login, reset, búsquedas caras).

• Throttling gradual (ralentizar) y respuesta clara con HTTP 429 cuando toque.

• Permitir ?bursts? controlados si hay casos legítimos.

Esto protege rendimiento, reduce coste y dificulta ataques de fuerza bruta o enumeración.

5) Validación estricta de entradas (no confiar en el cliente)

Toda entrada es sospechosa: parámetros, query strings, JSON, formularios, ficheros, cabeceras. La validación evita fallos lógicos y también clases enteras de ataques.

Buenas prácticas:

• Validar con esquemas (OpenAPI/JSON Schema o validadores equivalentes).

• Preferir allowlist: ?solo acepto lo que espero?.

• Limitar tamaños (body, strings, arrays, ficheros) y tipos.

• Usar consultas parametrizadas (para evitar inyecciones).

• Cuidado con la deserialización y formatos complejos.

Muchas brechas empiezan por algo tan simple como ?no se validó el tipo? o ?se aceptó un campo inesperado?.

6) Logging y monitorización: sin visibilidad no hay seguridad

Una API sin logs útiles es una API que no se puede defender ni depurar cuando algo va mal.

Qué conviene registrar:

• Método, ruta, código de respuesta, tiempos, request-id/correlation-id.

• Identidad del cliente (usuario/app) cuando exista.

• IP y user-agent (con criterio y cumpliendo normativa).

Qué no debe registrarse:

• Tokens, cookies, contraseñas, secretos o PII innecesaria.

Además del log, la guía práctica incluye alertas:

• Pico de 401/403, aumento de 429, patrones de enumeración, spikes por endpoint.

• Latencias anómalas o errores 5xx sostenidos.

7) Auditorías y pruebas (la seguridad no se da por hecha)

Que una API funcione no significa que sea segura. Las auditorías regulares encuentran fallos que pasan desapercibidos.

Pruebas útiles:

• SAST (análisis estático de código) para detectar patrones inseguros.

• DAST (dinámico) para encontrar fallos en ejecución.

• Fuzzing para inputs inesperados.

• Load/stress testing para entender el punto de ruptura.

• Pentest puntual en releases importantes o APIs críticas.

La clave es meterlo en el ciclo de desarrollo: que sea rutina, no ?un susto?.

8) Dependencias y cadena de suministro (la puerta trasera habitual)

Muchas vulnerabilidades vienen de librerías viejas, transitive dependencies o paquetes abandonados. La dependencia ?pequeña? puede ser la más peligrosa.

Medidas:

• Auditorías automáticas (npm audit, pip-audit, herramientas del ecosistema).

• Renovación controlada con bots (Dependabot/Renovate) y revisión humana.

• Lockfiles y versiones fijadas con criterio.

• Eliminar dependencias sin uso y vigilar paquetes con mantenimiento dudoso.

Esto también aplica a imágenes Docker, base images y runtimes.

9) Manejo de errores sin filtrar información sensible

Mensajes de error demasiado detallados ayudan al atacante: rutas internas, queries SQL, nombres de tablas, stack traces o configuraciones.

Buenas prácticas:

• Errores consistentes y genéricos hacia el cliente.

• Stack traces solo en logs internos (y protegidos).

• Desactivar debug en producción.

• Usar códigos HTTP correctos (400/401/403/404/429/500) sin ?inventarlos?.

La seguridad también es experiencia: respuestas claras, sin revelar el mapa del sistema.

10) Gestión de secretos: fuera del repositorio y con rotación

Si una API maneja claves en el código o en un .env que termina filtrándose, el incidente está a una mala práctica de distancia.

Buenas prácticas:

• Secret manager (Vault, AWS/GCP/Azure, o equivalente).

• Variables de entorno gestionadas y con permisos mínimos.

• Rotación de credenciales y auditoría de accesos.

• Service accounts con privilegios mínimos y separación por entornos (dev/staging/prod).

El objetivo: que un fallo en un entorno no dé acceso al resto.

Checklist rápido para revisar una API antes de ponerla en producción

• HTTPS forzado + HSTS.

• Autenticación sólida (tokens cortos, validaciones correctas).

• Autorización por recurso (anti IDOR/BOLA).

• Rate limiting en endpoints sensibles y costosos.

• Validación de inputs + límites de tamaño.

• Logs sin secretos + métricas y alertas.

• Pruebas SAST/DAST y revisiones periódicas.

• Dependencias auditadas y parcheadas.

• Errores sin detalles internos.

• Secretos fuera del repo y con rotación.

Preguntas frecuentes

¿Qué es más importante: autenticación o autorización en una API?
Ambas, pero la autorización suele ser el punto donde aparecen los fallos más graves: usuarios legítimos accediendo a recursos que no les corresponden (IDOR/BOLA).

¿Los JWT son ?inseguros??
No por sí mismos. El riesgo aparece cuando no se valida bien firma, audiencia, emisor o expiración, o cuando se usan tokens demasiado largos y sin revocación/rotación.

¿Rate limiting basta para frenar ataques de fuerza bruta?
Ayuda mucho, pero debe combinarse con controles adicionales: límites por usuario/IP, detección de patrones, bloqueo temporal y buenas prácticas en autenticación.

¿Qué debería loguear una API sin incumplir privacidad?
Información técnica mínima para trazabilidad (endpoint, status, latencia, request-id, app/user id si procede). Evitar registrar contenido sensible o datos personales innecesarios.

Fuente: Administración de sistemas