# Seguridad de APIs REST: autenticación, permisos y validaciones

**Categoría:** Hacking ético · **Nivel:** Intermedio · **Lectura:** 12 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/hacking/seguridad-de-apis-rest-autenticacion-permisos-y-validaciones/

## Respuesta rápida

Una [API REST](../../programacion/como-crear-una-api-con-nodejs-y-express/index.md) expone datos y operaciones a través de la red, así que protegerla es proteger todo lo que hay detrás. Su seguridad se organiza en **tres capas** que responden preguntas distintas. La **autenticación** responde «¿quién sos?»: verifica la identidad de quien llama, hoy habitualmente con **tokens** (como los de OAuth 2.0), no con la contraseña en cada pedido. La **autorización** responde «¿qué podés hacer?»: aunque estés autenticado, comprueba que tengas permiso para *esa* acción sobre *ese* recurso. Y la **validación** responde «¿estos datos son aceptables?»: nunca confiar en lo que llega del cliente, comprobar todo lo que entra. El fallo más común y grave de las APIs no es criptografía rota, sino un error de autorización llamado **BOLA** (autorización rota a nivel de objeto): la API verifica que estás logueado pero **no** que el recurso que pedís es tuyo, así que cambiando un número en la URL ves los datos de otro. El **OWASP API Security Top 10** recoge estos riesgos, y casi todos son fallos **simples y prevenibles**. Más: usar siempre HTTPS, limitar la tasa de peticiones (*rate limiting*), no exponer datos de más, y guardar los [secretos](../../devops-cloud/como-administrar-secretos-en-pipelines-y-aplicaciones/index.md) fuera del código.

## Las tres capas de defensa

La seguridad de una API se entiende mejor separando **tres preguntas** que muchas veces se confunden, y cuya confusión es la raíz de las brechas:

Las tres capas son **autenticación** (¿quién sos?), **autorización** (¿qué podés hacer?) y **validación** (¿estos datos son aceptables?). Una petición debe atravesarlas todas antes de tocar los datos. Confundir autenticación con autorización —creer que «estar logueado» basta— es la causa del fallo más frecuente, como se verá.

## Autenticación: quién sos

La **autenticación** verifica *la identidad* de quien hace la petición. En una API moderna no se manda la contraseña en cada llamada: la aplicación se autentica una vez y recibe un **token** de acceso —una credencial temporal— que adjunta en cada petición siguiente. El estándar más extendido para emitir y gestionar esos tokens es **OAuth 2.0**.

> **Buenas prácticas de autenticación**
>
> Usar **tokens con vencimiento** (no eternos), transmitirlos **siempre por HTTPS** (un token robado es una identidad robada), no ponerlos en la URL (quedan en registros), y tratarlos como [secretos](../../devops-cloud/como-administrar-secretos-en-pipelines-y-aplicaciones/index.md). Para las contraseñas que sí se almacenan (en el sistema de usuarios), guardarlas **con un hash fuerte**, nunca en texto plano. Una autenticación débil —tokens que no expiran, sin HTTPS, contraseñas mal guardadas— abre la puerta de entrada.

## Autorización y el fallo BOLA

La **autorización** es el control que más se descuida y de donde vienen la mayoría de las brechas. Verifica que, *aunque estés autenticado*, tengas permiso para hacer **esa acción** sobre **ese recurso**. Estar logueado no significa poder acceder a todo.

> **Atención**
>
> El error más común y grave se llama **BOLA** (Broken Object Level Authorization, autorización rota a nivel de objeto). Ocurre así: la API comprueba que estás autenticado, pero **no** comprueba que el recurso que pedís sea tuyo. Entonces, estando logueado con tu cuenta, cambiás el identificador en la URL —de `/pedidos/42` (tuyo) a `/pedidos/43` (de otro)— y la API te lo devuelve, porque solo verificó que estabas autenticado, no que *ese pedido* te pertenecía. Es sorprendentemente frecuente y muy dañino. La solución: en cada acceso a un objeto, **comprobar que pertenece a quien lo pide**. Nunca alcanza con «está autenticado».

BOLA encabeza el **OWASP API Security Top 10**, la lista de referencia de los riesgos de las APIs, precisamente porque es tan común. La lección de fondo: la mayoría de las brechas de API no vienen de criptografía rota, sino de **olvidar comprobar quién pide qué**, un fallo de control de acceso simple y prevenible.

## Validación y otras defensas

La tercera capa, la **validación**, parte de un principio: **nunca confiar en lo que llega del cliente**. Todo lo que entra a la API —parámetros, cuerpo, cabeceras— puede venir manipulado, así que hay que comprobar **tipos, formatos, longitudes y rangos**, y rechazar lo que no cumpla. Esto no solo evita datos corruptos: es la principal defensa contra las [inyecciones](../sqli-xss-y-csrf/index.md) (SQLi y similares), que explotan justamente entradas no validadas.

Sobre las tres capas se apoyan otras defensas imprescindibles:

- **HTTPS siempre.** Sin cifrado, tokens y datos viajan en claro y se pueden interceptar.
- **Rate limiting.** Limitar cuántas peticiones puede hacer un cliente por unidad de tiempo frena la fuerza bruta y el abuso.
- **No exponer datos de más.** Devolver solo los campos necesarios; una respuesta con datos internos filtra información.
- **Manejo de errores prudente.** No devolver detalles internos (rutas, versiones, trazas) que ayuden a un atacante.
- **Secretos fuera del código,** en variables de entorno o un [gestor de secretos](../../devops-cloud/como-administrar-secretos-en-pipelines-y-aplicaciones/index.md).
- **Registro y monitoreo,** para detectar patrones de abuso a tiempo.

## Errores frecuentes

- **Confundir autenticación con autorización.** «Está logueado» no es «puede hacer esto»; de ahí sale BOLA.
- **No comprobar la propiedad del recurso.** El fallo BOLA: se accede a datos de otro cambiando un identificador.
- **Confiar en la entrada del cliente.** Todo lo que entra se valida; es la puerta de las inyecciones.
- **Tokens sin vencimiento o en la URL.** Un token eterno o registrado es una identidad expuesta.
- **API sin HTTPS.** Tokens y datos viajan en claro; inaceptable.
- **Exponer datos internos en las respuestas o los errores.** Filtra información útil para atacar.
- **Sin rate limiting.** Permite fuerza bruta y abuso sin freno.

## Preguntas frecuentes

**¿Cuál es la diferencia entre autenticación y autorización?**
Son dos controles distintos que a menudo se confunden, y esa confusión es la raíz de la mayoría de las brechas en las APIs. La autenticación responde a la pregunta de quién sos: verifica la identidad de quien realiza la petición, comprobando que efectivamente es quien dice ser, habitualmente mediante un token de acceso que la aplicación obtuvo al iniciar sesión. La autorización responde a una pregunta diferente y posterior: qué podés hacer. Una vez verificada la identidad, la autorización comprueba que ese usuario concreto tenga permiso para realizar esa acción específica sobre ese recurso específico. La clave está en entender que estar autenticado no significa estar autorizado para todo: que la API sepa quién sos no implica que puedas acceder a cualquier dato u operación. Confundir ambas cosas, es decir asumir que porque un usuario está logueado ya puede acceder a lo que pida, lleva directamente al fallo más común de las APIs, en el que un usuario legítimo termina accediendo a datos que no le pertenecen. Por eso una API segura aplica ambos controles por separado y en orden: primero autentica, luego autoriza cada acceso.

**¿Qué es el fallo BOLA y por qué es tan común?**
BOLA, sigla en inglés de autorización rota a nivel de objeto, es el fallo de seguridad más común y grave de las APIs, y encabeza por ello el listado de referencia del OWASP API Security Top 10. Ocurre cuando la API verifica correctamente que el usuario está autenticado, es decir que inició sesión, pero olvida verificar que el objeto o recurso que solicita realmente le pertenece o que tiene permiso para acceder a él. El escenario típico es el siguiente: un usuario legítimo, logueado con su propia cuenta, observa que la dirección para ver su pedido contiene un número identificador, por ejemplo el pedido cuarenta y dos, y simplemente lo cambia por otro número, digamos el cuarenta y tres; si la API solo comprobó que estaba autenticado pero no que ese pedido concreto era suyo, le devolverá los datos del pedido de otra persona. Es sorprendentemente frecuente porque es fácil olvidar esa comprobación durante el desarrollo, especialmente cuando todo funciona bien con los datos propios, y es muy dañino porque permite acceder a datos ajenos de forma trivial. La solución es comprobar en cada acceso a un objeto que este pertenece a quien lo solicita, sin dar nunca por suficiente el hecho de que el usuario esté autenticado.

**¿Cómo se autentica una API moderna?**
En una API moderna, la práctica habitual es no enviar la contraseña del usuario en cada petición, sino usar tokens de acceso. El flujo funciona así: la aplicación cliente se autentica una sola vez, por ejemplo presentando las credenciales del usuario, y a cambio recibe un token de acceso, que es una credencial temporal. A partir de ese momento, adjunta ese token en cada petición siguiente a la API, y la API verifica el token para saber quién está llamando, sin necesidad de manejar la contraseña una y otra vez. El estándar más extendido para emitir y gestionar estos tokens es OAuth 2.0, ampliamente adoptado en la industria. Para que esta autenticación sea segura, hay que seguir varias buenas prácticas: los tokens deben tener un vencimiento y no ser eternos, deben transmitirse siempre a través de HTTPS porque un token robado equivale a una identidad robada, no deben colocarse en la dirección URL porque quedarían registrados en los historiales, y deben tratarse con el mismo cuidado que cualquier secreto. Además, las contraseñas que sí se almacenan en el sistema de usuarios deben guardarse siempre protegidas mediante un hash fuerte, jamás en texto plano.

**¿Por qué hay que validar todo lo que entra a la API?**
Porque nunca se puede confiar en los datos que llegan del cliente, ya que cualquier parámetro, cuerpo o cabecera de una petición puede haber sido manipulado deliberadamente por un atacante o simplemente contener datos incorrectos. La validación consiste en comprobar que todo lo que entra a la API cumple con lo esperado en cuanto a tipos, formatos, longitudes y rangos, y en rechazar cualquier cosa que no cumpla. Esto cumple dos funciones importantes. La primera es evitar que datos corruptos o inesperados provoquen errores o comportamientos indebidos en la aplicación. La segunda, y crítica desde el punto de vista de la seguridad, es que la validación es la principal defensa contra los ataques de inyección, como la inyección de SQL y otros similares, que funcionan precisamente introduciendo entradas maliciosas que la aplicación procesa sin controlar. Si la API valida rigurosamente todo lo que recibe, cierra la puerta a que una entrada manipulada se transforme en un comando o una operación no deseada. Por eso la validación de entradas es una de las tres capas fundamentales de la seguridad de una API, junto con la autenticación y la autorización, y su ausencia es una de las causas más frecuentes de vulnerabilidades explotables.

**¿Qué es el OWASP API Security Top 10?**
Es un documento de referencia elaborado por OWASP, una organización sin fines de lucro dedicada a la seguridad del software, que recopila los diez riesgos de seguridad más críticos y frecuentes específicos de las APIs. Es el equivalente, para el mundo de las APIs, del conocido OWASP Top 10 general de aplicaciones web, pero enfocado en los problemas particulares que enfrentan las interfaces de programación. Su gran valor es que sistematiza, a partir de datos reales de brechas e incidentes, cuáles son los fallos que efectivamente comprometen a las APIs, permitiendo a quienes las desarrollan concentrar sus esfuerzos de seguridad donde más importa. Un hallazgo revelador de esta lista es que los riesgos principales no tienen que ver con criptografía rota ni con técnicas sofisticadas, sino sobre todo con fallos de control de acceso, encabezados por la autorización rota a nivel de objeto. Esto confirma que la mayoría de las brechas de API provienen de olvidar comprobar adecuadamente quién puede acceder a qué, que son errores simples y prevenibles. Usar el OWASP API Security Top 10 como guía y como lista de verificación al diseñar, construir y auditar una API es una de las formas más eficaces de evitar los problemas de seguridad más habituales.

**Además de las tres capas, ¿qué más protege una API?**
Sobre las tres capas fundamentales de autenticación, autorización y validación se apoyan varias defensas complementarias que también son imprescindibles. La primera es usar siempre HTTPS, para que los tokens y los datos viajen cifrados y no puedan interceptarse en tránsito; una API sin HTTPS expone todo en texto claro. La segunda es la limitación de tasa de peticiones, conocida como rate limiting, que restringe cuántas peticiones puede hacer un cliente en un período dado y así frena los ataques de fuerza bruta y el abuso del servicio. La tercera es no exponer más datos de los necesarios en las respuestas, devolviendo únicamente los campos que el cliente realmente precisa, ya que incluir datos internos o de más filtra información útil para un atacante. La cuarta es un manejo prudente de los errores, que no revele detalles internos como rutas, versiones de software o trazas técnicas que faciliten un ataque. La quinta es mantener los secretos y las claves fuera del código, en variables de entorno o en un gestor de secretos. Y la sexta es implementar registro y monitoreo, para detectar a tiempo patrones de abuso o intentos de ataque. En conjunto, estas medidas complementan las tres capas y elevan significativamente la seguridad de una API.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Desarrollo web](https://underc0de.org/foro/desarrollo-web/). Backend, APIs y seguridad de aplicaciones.
2. **Underc0de, foro.** [Sección Hacking](https://underc0de.org/foro/hacking/). Auditoría y seguridad de APIs.

### Documentación oficial

1. **OWASP.** [API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x00-header/). Los riesgos principales de las APIs, citados en la guía.
2. **OWASP.** [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html). Buenas prácticas de autenticación.
3. **OWASP.** [Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). Control de acceso.
4. **IETF.** [RFC 6749: OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749). El marco de autorización estándar.

## Guías relacionadas

- [Crear una API con Node](../../programacion/como-crear-una-api-con-nodejs-y-express/index.md)
- [SQLi, XSS y CSRF](../sqli-xss-y-csrf/index.md)
- [OWASP Top 10 (2025)](../owasp-top-10-2025-explicado/index.md)
- [Administrar secretos](../../devops-cloud/como-administrar-secretos-en-pipelines-y-aplicaciones/index.md)
- [Índice de Hacking ético](../index.md)