Cómo proteger una REST API en 2026

Wed Aug 19 2026

Pero no existe un OWASP API Security Top 10 para 2026. La edición oficial actual sigue siendo OWASP API Security Top 10 2023. El año de esta guía es la fecha de publicación y el contexto de las recomendaciones actuales, no una nueva versión de OWASP.

Esa lista de 2023 coloca BOLA en primer lugar. También incluye Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Security Misconfiguration e Improper Inventory Management entre sus riesgos. OWASP clasifica los riesgos. El informe State of API Security 2026 de 42Crunch informa sobre fallos en un conjunto de datos seleccionado por proveedores. Esas mediciones responden preguntas diferentes.

Esta guía convierte las prácticas recomendadas de seguridad para REST API en controles que puedes probar antes del lanzamiento. Además, el recorrido de la solicitud avanza desde el transporte, pasando por la identidad, los permisos, la entrada, los controles contra abusos, los datos y la observabilidad, hasta la verificación. La autorización y la validación reciben la mayor atención porque “usar HTTPS” es fácil de configurar; decidir exactamente quién puede cambiar qué objeto es donde las API tienden a fallar.

En este artículo

Coloca controles independientes en el recorrido de la solicitud

Un gateway puede rechazar un token mientras tu aplicación sigue devolviendo el pedido de otro tenant. Los controles deben mantenerse separados incluso cuando la infraestructura coloque varios de ellos en un mismo servicio.

  1. TLS protege la conexión.
  2. Un gateway puede encargarse del enrutamiento, las comprobaciones generales de tokens o las cuotas.
  3. La autenticación establece la identidad del solicitante.
  4. La autorización decide si ese solicitante puede usar el endpoint y acceder al objeto.
  5. La validación comprueba la estructura y el significado de la entrada.
  6. La limitación de velocidad controla el consumo de recursos.
  7. La aplicación devuelve únicamente los datos permitidos.
  8. Los registros y la monitorización registran las señales de seguridad.

Este modelo describe el flujo de control en lugar de prescribir una topología de software. Por tanto, un servicio perimetral puede aplicar la limitación de velocidad antes de la autenticación. El código de la aplicación puede aplicar después un límite más preciso por usuario.

Como explica Postman, “Ningún control individual es suficiente”. Además, las guías de Postman y StackHawk ofrecen consejos prácticos de implementación. No son estándares. Usa sus recomendaciones para crear controles y después adapta la política a tu aplicación.

TLS protege la solicitud antes de que tu código la vea

Configura la seguridad del transporte antes de revisar los permisos de las rutas. Por tanto, las credenciales, los tokens y los datos de las solicitudes necesitan protección antes de que tu aplicación tome su primera decisión.

Usa TLS 1.2 o superior, preferiblemente TLS 1.3. Desactiva SSLv3, TLS 1.0, RC4 y 3DES. Usa certificados de autoridades de certificación de confianza, y convierte la caducidad y sustitución de certificados en una tarea operativa asignada.

Añade HSTS únicamente cuando todos los subdominios cubiertos sean compatibles con HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Rechaza HTTP sin cifrado en el perímetro. Una redirección todavía permite que la solicitud inicial viaje sin cifrar, por lo que la ruta en texto claro debe fallar.

Para el tráfico entre servicios, evalúa mutual TLS. Ambos lados presentan certificados, lo que proporciona a los servicios internos una comprobación de identidad más sólida que la ubicación de red por sí sola. No añadas mTLS a todas las integraciones de clientes públicos; la emisión y rotación de certificados generan trabajo que debe tener un responsable.

El cifrado del transporte cubre los datos en movimiento. Los datos almacenados necesitan una protección independiente. Usa el estándar de cifrado requerido por tu entorno, incluido AES-256 cuando esa sea tu política, y gestiona las claves mediante un KMS, Key Vault o HSM. Cubre las capas de almacenamiento relevantes para la clasificación de los datos: los campos y discos de la base de datos pueden necesitar un conjunto de controles. Las réplicas y copias de seguridad pueden necesitar otro.

Mantén los valores sensibles fuera de las URL. Los proxies, servidores web, herramientas de analítica y otra infraestructura suelen registrar las cadenas de consulta.

Autentica cada solicitud y después toma una decisión de permisos independiente

OAuth 2.0 con tokens de acceso JWT es un patrón de producción razonable para el acceso delegado y la verificación local de tokens. JWT es una elección de implementación, y la seguridad sigue dependiendo de cómo lo valides y utilices. Usa las reglas de validación documentadas por el emisor, y elige tokens opacos con introspección cuando la revocación centralizada sea el requisito dominante.

Para cada solicitud protegida, valida la firma, la caducidad, el emisor, la audiencia y los scopes o claims requeridos. Los tokens de acceso de corta duración limitan la ventana de exposición; los refresh tokens permiten sesiones más largas, pero necesitan su propia política de rotación y revocación. Para scopes de alto riesgo, considera la introspección. Una deny-list es otra opción. No puedo elegir tu límite de revocación a partir de una guía genérica. Documenta con qué rapidez debe cortarse el acceso y después verifícalo.

Los consejos sobre JWT se repiten habitualmente sin reflexión. “Usamos JWT” no significa nada hasta que los tokens malformados, caducados, firmados incorrectamente, con el emisor equivocado o con la audiencia equivocada fallen correctamente.

Considera la siguiente API de pedidos multi-tenant:

GET /api/orders/123
Authorization: Bearer <access-token>

El token identifica al solicitante y puede contener un ID de usuario, un ID de tenant y scopes. Por sí mismo, no concede acceso al pedido 123. La siguiente capa debe aplicar la política del tenant y del recurso.

Las API keys funcionan para integraciones entre servidores. Proporciona a cada integración su propia clave, asígnale un scope, establece una caducidad, rótala y monitoriza su uso. Una clave identifica a la aplicación que realiza la llamada; no puede autorizar el acceso de un usuario al pedido de otro usuario.

Para clientes de navegador, define una política de almacenamiento y verifica que los tokens de acceso no se escriban en almacenamiento persistente del navegador sin un diseño de seguridad explícito. El frontend no es un límite de seguridad.

El hallazgo de autenticación ausente del informe de 42Crunch procede de casos de 2025 seleccionados por proveedores; no mide una tasa universal de brechas. Mi criterio es más sencillo: prueba primero la autenticación ausente porque el fallo es barato de detectar y caro de justificar. Una ruta protegida sin token debe devolver 401.

La autorización merece más ingeniería que la configuración de TLS

OWASP incluye Broken Object Level Authorization, o BOLA, como API1:2023. Las rutas predecibles como /api/orders/123 facilitan el sondeo sistemático de objetos.

La implementación peligrosa comprueba únicamente que el solicitante haya iniciado sesión:

// WRONG: authentication exists, ownership does not
const order = await Order.findById(req.params.id);

Para una API en la que la pertenencia al tenant concede acceso a todos los pedidos de ese tenant, vincula la búsqueda al tenant:

// Correct only when tenant membership grants order access
const order = await Order.findOne({
  _id: req.params.id,
  tenant_id: req.user.tenant_id
});

Esa consulta solo es suficiente si la pertenencia al tenant constituye toda la política. Si el acceso también depende de la propiedad individual, el rol, el estado del pedido u otra regla de negocio, incluye también ese predicado o comprobación de política. Prueba la pertenencia al tenant y la propiedad del objeto de forma independiente cuando ambas sean relevantes.

Supón que el usuario A pertenece al tenant North y el usuario B al tenant South. Cuando el usuario A solicite /api/orders/123, debe recibir el 404 no divulgativo documentado y ningún dato del pedido si el pedido 123 pertenece a South. Un usuario del mismo tenant sin permiso debe recibir 403 si tu contrato distingue ese caso. No elijas 404 si los clientes necesitan distinguir los errores de autorización.

Repite la prueba con:

PATCH /api/orders/123

La respuesta debe dejar el registro sin cambios. Una lectura segura no implica una escritura segura.

Aplica la autorización en cuatro niveles:

  • Endpoint: ¿puede esta identidad llamar a la ruta?
  • Objeto: ¿puede el solicitante acceder a este pedido?
  • Propiedad: ¿puede el solicitante cambiar cada campo enviado?
  • Función: ¿puede este rol realizar una operación administrativa?

Un usuario normal podría actualizar una nota de entrega, pero nunca tenant_id, el precio, el estado del pago o un rol interno. Las listas de campos permitidos explícitamente evitan la asignación masiva. Usa RBAC cuando los permisos se correspondan claramente con roles; usa ABAC cuando las decisiones dependan del tenant, la propiedad, la región o el estado del pedido.

La validación de entradas debe cubrir rutas, consultas y cuerpos

El informe de 42Crunch identifica la validación incorrecta de entradas, incluida la inyección, la asignación masiva y el traversal de rutas, como la categoría de fallos más común en su conjunto de datos seleccionado. Esa es una frecuencia observada, no la clasificación de riesgos de OWASP.

Define la estructura de solicitud aceptada y rechaza todo lo demás. Valida los campos obligatorios, los tipos, las longitudes y los rangos. Comprueba también los formatos, los valores de enumeración y los objetos anidados. Valida los parámetros de ruta y de consulta. Un sistema de schemas como Joi, Zod o JSON Schema mantiene las reglas en un solo lugar.

Usa esta secuencia de límites:

  1. Confirma el método y Content-Type.
  2. Analiza la solicitud contra un schema estricto.
  3. Valida los parámetros de ruta y consulta mediante listas permitidas.
  4. Aplica límites al tamaño del cuerpo y de las colecciones.
  5. Rechaza los campos desconocidos antes de la lógica de negocio o del acceso a la base de datos.

Un cuerpo JSON es solo un canal de entrada. /api/orders/123, ?status=pending, las cabeceras, los tipos de contenido y los tamaños de carga también están bajo el control del usuario.

Una entrada como esta nunca debe convertirse en un operador de base de datos sin comprobar:

/api/users?status[$ne]=inactive

Permite únicamente claves de consulta y valores escalares documentados. La prueba negativa debe devolver 400, sin ejecutar ninguna consulta a la base de datos usando la estructura del operador anidado.

La autorización de PATCH debe permanecer junto al modelo de permisos anterior. La capa de validación debe aplicar el schema resultante: rechaza los campos que el solicitante no tenga permitido enviar, en lugar de vincularlos silenciosamente a un modelo de base de datos. Las entradas no válidas deben devolver 400 sin trazas de pila, fragmentos SQL ni información interna de la base de datos.

Los límites de velocidad deben seguir el coste del endpoint

Un único límite de velocidad global es práctico, pero deja sin abordar los costes de abuso específicos de cada endpoint. El inicio de sesión y el restablecimiento de contraseña tienen un perfil de abuso. Los pagos y las escrituras tienen otro. Las listas de solo lectura tienen costes diferentes.

  • Inicio de sesión y restablecimiento de contraseña: usa umbrales por IP y por cuenta; devuelve 429 y Retry-After después del límite documentado.
  • Listas de pedidos de solo lectura: usa un límite más alto por usuario, tenant o clave; monitoriza el scraping.
  • Escrituras de pedidos: aplica límites más estrictos por usuario y tenant porque las escrituras consumen más capacidad empresarial.
  • POST /api/payments: aplica un límite estricto al cliente y exige una clave de idempotencia para que los reintentos no creen cargos duplicados.

Considera las dimensiones por usuario, IP, tenant y API key cuando encajen con tu modelo de amenazas. Cuando un cliente supere una ventana definida por el proveedor, devuelve:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000000

Esos valores son ilustrativos. Documenta la ventana real y la dimensión de identidad junto a la política.

No conozco la forma de tu tráfico legítimo, así que no prescribiré un número universal. Ajusta los valores a partir de la telemetría. Unos límites demasiado agresivos generan falsos positivos; unos límites generosos convierten los endpoints costosos en servicios públicos.

Mantén los secretos y las respuestas más pequeños que la base de datos

Nunca codifiques credenciales, claves de firma, contraseñas de bases de datos ni API keys directamente en el código. Eliminar un secreto de la rama actual no lo elimina del historial del repositorio.

Usa variables de entorno para implementaciones sencillas y un gestor de secretos dedicado para el acceso gestionado. Limita las credenciales al conjunto mínimo de permisos útil, asigna caducidades y rótalas tras una posible exposición. Monitoriza el uso para detectar volúmenes u orígenes inusuales.

La autenticación y la autorización pueden completarse correctamente mientras la respuesta filtra demasiada información. Selecciona los campos explícitamente. Un cliente que solicita un nombre visible no necesita hashes de contraseñas, IDs internos, roles, metadatos del tenant ni el registro completo del usuario.

Los errores de producción deben ser genéricos e incluir un ID de solicitud:

{
  "error": "request_failed",
  "request_id": "7f3c2a91"
}

Registra el contexto detallado del servidor asociado a ese ID. Devuelve el mismo comportamiento de fallo externo para “usuario no encontrado” y “contraseña incorrecta”, de modo que los solicitantes no puedan enumerar cuentas.

Registra señales sin crear una segunda brecha

Registra las autenticaciones correctas y fallidas, los fallos de autorización y las infracciones de los límites de velocidad. Registra también los cambios en recursos sensibles, los volúmenes de solicitudes inusuales y las llamadas a endpoints inexistentes. Estos eventos proporcionan al investigador un rastro utilizable sin requerir cuerpos completos de solicitudes.

No registres contraseñas, tokens de acceso, números de tarjetas de pago ni cuerpos completos de solicitudes sensibles. La redacción debe producirse antes de que el evento llegue al almacenamiento.

Entre las heurísticas de detección útiles se incluyen:

  • un aumento brusco de respuestas 401 puede indicar credential stuffing;
  • un grupo de respuestas 500 alrededor de un endpoint puede indicar un intento de explotación;
  • respuestas 403 repetidas contra IDs de objetos vecinos pueden indicar sondeo de autorización;
  • infracciones de límites de velocidad concentradas en una clave pueden indicar una integración comprometida.

Estas señales necesitan investigación y no conclusiones automáticas. Los responsables de las alertas necesitan una forma de inspeccionar el ID de solicitud, la ruta, un identificador seguro del principal y el estado de respuesta sin exponer secretos.

Mantén un inventario de las API, versiones, entornos y rutas documentados. Cada ruta desplegada necesita un responsable, un requisito de autenticación, una clasificación de datos, una versión y un estado de retirada. El inventario es la forma de implementar la preocupación detrás de API9:2023: las rutas no documentadas u obsoletas deben tener un responsable y un camino hacia su eliminación.

Mide las duraciones de los tokens, los límites de velocidad y los umbrales de alerta en función de tu tráfico. Esta guía puede definir controles; no puede elegir esos valores operativos por ti.

Demuestra los controles antes del lanzamiento

Ejecuta pruebas negativas en CI/CD y repítelas durante las auditorías y las pruebas de penetración independientes.

Autenticación y autorización

  • Una ruta protegida sin token debe devolver 401.
  • Un token válido debe llegar al handler esperado.
  • Los tokens caducados, malformados, firmados incorrectamente, con el emisor equivocado o con la audiencia equivocada deben devolver 401.
  • Un token autenticado sin el scope requerido debe devolver 403, salvo que la API documente un 404 no divulgativo.
  • Una solicitud del usuario A para el pedido del usuario B debe devolver el 404 entre tenants documentado y ningún dato.
  • Un usuario del mismo tenant sin el permiso requerido para el pedido debe recibir 403 cuando el contrato distinga ese caso.
  • Rechaza la solicitud PATCH /api/orders/123 del usuario A con campos prohibidos y deja el registro sin cambios.

Validación y abuso

Envía campos ausentes, valores de ruta y consulta no válidos y cargas demasiado grandes. Prueba cadenas de inyección, campos desconocidos y tipos de contenido inesperados. Espera 400 y ningún detalle interno.

Supera la cuota documentada de cada endpoint. Espera 429 con Retry-After. Repite una solicitud de pago con una clave de idempotencia y confirma que crea una sola transacción.

Comprueba que los campos de los registros que contienen secretos estén redactados y que los errores de producción incluyan IDs de solicitud sin trazas de pila. Los scanners automatizados detectan defectos repetibles; no pueden inferir tus reglas de tenant y de negocio. Añade pruebas de penetración independientes cuando el riesgo de la API lo justifique.

Usa esta lista de comprobación de seguridad de API en el momento del lanzamiento

Marca cada línea como aprobada, fallida o no aplicable con una justificación escrita. Adjunta un responsable y el resultado de la prueba.

  • Transporte: se han verificado TLS 1.2+, HSTS cuando todos los subdominios cubiertos admiten HTTPS y el rechazo de HTTP sin cifrado; mTLS tiene una decisión explícita para las comunicaciones entre servicios.
  • Autenticación: las rutas protegidas rechazan tokens ausentes, caducados, malformados, firmados incorrectamente, con el emisor equivocado o con la audiencia equivocada mediante 401.
  • Ciclo de vida de los tokens: los tokens de acceso son de corta duración; el comportamiento de rotación y revocación de los refresh tokens está documentado y probado.
  • Autorización: las comprobaciones de endpoint, función, objeto, tenant y campo se aplican en el código de la aplicación.
  • Entrada: las comprobaciones del cuerpo, la ruta, la consulta, el tipo de contenido, los campos desconocidos y el tamaño devuelven 400; los operadores de consulta rechazados nunca llegan a la base de datos.
  • Controles contra abusos: los límites específicos por endpoint usan dimensiones documentadas por usuario, IP, tenant o clave; los excesos devuelven el 429 y Retry-After definidos por el proveedor.
  • Transacciones: los endpoints de pagos y transacciones usan claves de idempotencia y prueban el comportamiento ante solicitudes duplicadas.
  • Datos almacenados: las capas de almacenamiento sensibles, incluidas las copias de seguridad y réplicas relevantes, están cifradas; las claves se gestionan mediante un KMS, Key Vault o HSM.
  • Secretos: las comprobaciones del repositorio y de detección de secretos no encontraron credenciales activas; los hallazgos históricos están revocados, rotados y registrados.
  • Respuestas: solo se devuelven los campos necesarios; los errores de producción incluyen IDs de solicitud y no contienen trazas de pila ni detalles internos.
  • Observabilidad: los eventos de autenticación, autorización y límites de velocidad se registran sin secretos. Registra también cambios sensibles, anomalías y rutas inexistentes. Hay responsables asignados para las alertas.
  • Inventario: cada ruta desplegada tiene un responsable, una versión, un requisito de autenticación, una clasificación de datos y un estado de retirada.
  • Verificación: las pruebas de seguridad se ejecutan en CI/CD, las auditorías están programadas y las pruebas de penetración tienen un responsable y una fecha.

Lanza únicamente cuando cada línea tenga el estado aprobada, fallida o una excepción escrita, además de un responsable y un resultado de prueba. Si el ticket solo dice “usamos JWT” o “el gateway se encarga”, devuélvelo.