Pruebas de Seguridad de APIs: 10 Cosas Que Todo Principiante Debe Saber

Las APIs impulsan casi todas las aplicaciones modernas. Cuando abres una aplicacion movil, consultas tu saldo bancario, pides comida o actualizas tu perfil, una API esta trabajando en segundo plano. El sitio web es la parte que ves. La API es la parte que envia, recibe y procesa los datos.

Esta es tambien la razon por la que las APIs son uno de los objetivos mas importantes para las pruebas de seguridad. Un sitio web puede parecer seguro desde el exterior, pero la API detras de el puede seguir exponiendo datos privados, provocando una brecha de datos, o aceptar acciones del usuario equivocado. Muchos bugs graves en APIs no se encuentran mediante payloads complejos. Se encuentran leyendo cuidadosamente las solicitudes, cambiando pequenos valores y haciendo una pregunta: deberia este usuario poder hacer esto?

Esta guia te lleva a traves de todo lo que necesitas para empezar con las pruebas de seguridad de APIs, desde cero.

1. Que es la seguridad de APIs y por que importa?

Para los usuarios normales, la aplicacion es la pantalla que ven. Para los testers de seguridad, la aplicacion real vive dentro del trafico de la API. Cada clic en un boton, actualizacion de perfil, carga de archivo, accion de pago y cambio de contrasena genera una solicitud de API.

La API es donde residen los datos mas sensibles. Si una API no esta debidamente protegida, el frontend no puede salvarla. Un boton puede ocultarse, pero la solicitud aun puede enviarse manualmente. Un campo puede estar deshabilitado en el navegador, pero aun puede modificarse en Burp Suite. Una aplicacion movil puede ocultar datos de la pantalla, pero la respuesta completa de la API puede seguir conteniendolos.

La regla es simple: nunca confies solo en lo que muestra la interfaz de usuario. El frontend es la capa de presentacion. La seguridad real debe ocurrir en el lado del servidor. El servidor debe verificar quien es el usuario, a que tiene permitido acceder y si los datos que envio deben ser confiables.

Como principiante, esto es una buena noticia. No necesitas habilidades de explotacion altamente avanzadas. Si entiendes la autenticacion, la autorizacion, las respuestas de API y la modificacion basica de solicitudes, ya puedes empezar a encontrar problemas reales de seguridad en APIs.

2. Como un bug IDOR explica las pruebas de seguridad de APIs

Eran alrededor de las 11 de la noche cuando Arjun, un cazador de bug bounty principiante, estaba probando una plataforma de reclutamiento de empleo. Llevaba aprendiendo solo unos meses. Creo una cuenta, inicio sesion, abrio su perfil y comenzo a observar las solicitudes en Burp Suite.

Una solicitud llamo su atencion. El endpoint de la API se veia asi: /api/v1/users/1147/profile. La respuesta mostraba los detalles de su propio perfil: nombre, direccion de correo electronico, numero de telefono y direccion guardada. Todo parecia normal. Pero entonces noto el numero en la URL. Parecia un ID de usuario.

Por curiosidad, cambio 1147 por 1148 y envio la solicitud de nuevo. Esperaba un error. Quizas 403 Forbidden. Quizas 404 Not Found. En cambio, la API devolvio el perfil completo de otro usuario. Cambio el numero de nuevo. Otro perfil aparecio.

Arjun habia encontrado Broken Object Level Authorization, tambien conocido como BOLA o IDOR. La API estaba verificando que el habia iniciado sesion, pero no estaba comprobando si el perfil solicitado realmente le pertenecia. Este es uno de los errores de seguridad de APIs mas comunes y peligrosos.

La leccion: Arjun no uso un exploit complejo. No eludio un firewall. Simplemente cambio un valor en una solicitud de API, y el servidor devolvio datos que deberian haber estado protegidos.

He visto este patron exacto cientos de veces a lo largo de mis mas de 250 entradas en el Hall of Fame. BOLA es consistentemente el primer bug real que mis estudiantes encuentran, y sigue siendo la vulnerabilidad IDOR mas comun en el mundo real. La tecnica es simple, pero el impacto es casi siempre critico.

3. Los 6 prerrequisitos antes de probar APIs

Antes de empezar a probar APIs, necesitas una base. No necesitas dominar todo, pero deberias entender que sucede cuando envias una solicitud y recibes una respuesta.

1. Hardware de computadora y redes. Entiende como los dispositivos usan las redes para compartir datos. Aprende que hacen las direcciones IP, DNS y los routers. Familiarizate con el modelo OSI.

2. Linea de comandos y Linux. Deberias sentirte comodo con los comandos basicos de Linux y una distribucion de pruebas como Kali Linux. Lee archivos, ejecuta herramientas, envia solicitudes y formatea respuestas JSON. Aprende scripting basico en Bash o Python para automatizacion.

3. Fundamentos de HTTP. Las APIs funcionan a traves de solicitudes HTTP. Una solicitud tiene un metodo, cabeceras y, a veces, un cuerpo o parametros. Conoce los metodos comunes: GET (leer), POST (crear), PUT/PATCH (actualizar), DELETE (eliminar). Conoce los codigos de estado: 200 (exito), 401 (no autorizado), 403 (prohibido), 404 (no encontrado), 500 (error del servidor).

4. Autenticacion vs. autorizacion. La autenticacion significa demostrar quien eres, como iniciar sesion con una contrasena. La autorizacion significa decidir que tienes permitido hacer despues de iniciar sesion. Un usuario normal y un administrador pueden estar ambos conectados, pero no deberian tener los mismos permisos. Muchos bugs graves en APIs ocurren porque la autenticacion existe pero la autorizacion es debil o inexistente. Aprende los tipos comunes: Basic, basada en Token, JWT, Session, SSO y OAuth.

5. Tipos y estructura de APIs. Una API es una forma en que dos sistemas se comunican. El cliente envia una solicitud, el servidor devuelve datos, generalmente en JSON. Conoce los tipos principales: REST (el mas comun, usa URLs estandar y metodos HTTP), GraphQL (un solo endpoint, el cliente especifica exactamente que datos quiere), SOAP (mas antiguo, basado en XML, aun se usa en banca), WebSockets (comunicacion en tiempo real) y gRPC (rapido, moderno, comunicacion entre servicios). Empieza con REST, luego pasa a GraphQL.

6. Burp Suite y Postman. Estas son las herramientas mas importantes para las pruebas de APIs. Burp Suite te permite capturar solicitudes, modificar valores y observar las respuestas del servidor. Postman te ayuda a construir y organizar solicitudes de API. Dedica tiempo dentro de estas herramientas en lugar de solo ver tutoriales.

4. Las 5 vulnerabilidades de APIs que veras con mas frecuencia

Existen muchos tipos de vulnerabilidades en APIs, pero algunas aparecen una y otra vez. Estas son las que todo principiante deberia aprender primero.

4.1 Broken Object Level Authorization (BOLA/IDOR)

BOLA ocurre cuando una API te permite acceder a un objeto que no te pertenece. Un objeto puede ser un perfil, pedido, factura, ticket, archivo, mensaje o metodo de pago.

Imagina que abres los detalles de tu pedido. La solicitud de API se ve asi: /api/v1/orders/8842. El servidor verifica tu token y devuelve el pedido. Ahora cambias 8842 por 8843, y el servidor devuelve el pedido de otra persona. Eso es BOLA.

El error es simple: la API verifico que habias iniciado sesion, pero no comprobo si el pedido 8843 pertenecia a tu cuenta. BOLA ha mantenido la posicion numero uno en el OWASP API Security Top 10 desde que la lista se publico por primera vez.

Como probar BOLA:

• Busca cada solicitud que contenga un ID (ID de usuario, ID de pedido, ID de factura, ID de ticket, UUID, GUID)
• Cambia el ID y observa la respuesta
• Usa dos cuentas y prueba si la cuenta A puede acceder a los datos de la cuenta B
• Verifica tanto IDs numericos secuenciales como UUIDs

4.2 Broken authentication

Broken authentication significa que el sistema tiene una debilidad en como verifica a los usuarios o gestiona las sesiones. En las pruebas de APIs, esto tipicamente involucra tokens, flujos de restablecimiento de contrasena, comportamiento de cierre de sesion y sistemas OTP.

Problemas comunes a probar:

• Refresh tokens que nunca expiran. Un access token puede expirar en 15 minutos, pero si el refresh token nunca expira, un refresh token robado significa acceso permanente
• Cierre de sesion solo del lado del cliente. La aplicacion elimina el token del almacenamiento, pero el servidor aun lo acepta. Un cierre de sesion adecuado debe invalidar la sesion del lado del servidor
• Tokens de restablecimiento de contrasena reutilizables. Un token de restablecimiento deberia ser aleatorio, expirar rapidamente y funcionar solo una vez. Si puede ser reutilizado o adivinado, el impacto escala a la toma de control de la cuenta
• Sin limitacion de frecuencia en OTP. Si la API permite intentos ilimitados de OTP sin las protecciones de autenticacion de dos factores, un atacante puede usar fuerza bruta o credential stuffing para eludir el codigo

4.3 Broken Object Property Level Authorization

Esta categoria cubre dos problemas relacionados: Excessive Data Exposure y Mass Assignment.

Excessive Data Exposure ocurre cuando la API devuelve mas informacion de la que el frontend necesita. Los desarrolladores a veces envian objetos completos de la base de datos al cliente y confian en que el frontend muestre solo los campos seguros.

Por ejemplo, una pagina de resenas puede mostrar solo el nombre del autor y el comentario. Pero la respuesta de la API puede contener tambien el correo electronico del autor, su numero de telefono, el ID interno de usuario y el codigo de departamento. El sitio web oculta estos campos, pero cualquiera que intercepte la respuesta los ve.

Mass Assignment ocurre cuando la API acepta mas campos del usuario de los que deberia. Los desarrolladores a veces vinculan el cuerpo completo de la solicitud al objeto de la base de datos y olvidan bloquear campos sensibles.

Por ejemplo, una pagina de actualizacion de perfil puede permitir cambiar solo el nombre y el numero de telefono. Pero si la API tambien acepta role, isAdmin, isVerified o accountBalance, el usuario puede cambiar valores que nunca deberia controlar.

Como probar:

• Para exposicion de datos: inspecciona cada respuesta JSON cruda en Burp Suite. Busca campos como email, phone, isAdmin, token, role, internalId
• Para asignacion masiva: agrega campos adicionales a los cuerpos de las solicitudes. Prueba "role": "admin", "isVerified": true, "plan": "enterprise" y verifica si la API los acepta

4.4 Broken Function Level Authorization

Esto ocurre cuando un usuario puede realizar una accion que solo otro rol deberia tener permitido realizar. A diferencia de BOLA (acceder a los datos de otro usuario), esto se trata de ejecutar una funcion que tu rol no deberia tener.

Un usuario normal no deberia poder llamar a endpoints de administrador que crean usuarios, eliminan cuentas, aprueban pagos o exportan datos de la empresa. Esto es efectivamente una forma de escalada de privilegios. Incluso si el boton de administrador esta oculto en la interfaz, el endpoint de la API aun necesita verificaciones de permisos del lado del servidor.

Enfoque de prueba:

• Mapea todos los endpoints y entiende que acciones pertenecen a cada rol
• Captura una solicitud de una cuenta de mayor privilegio y reproducela con un token de menor privilegio
• Busca campos en la solicitud como role, isAdmin, type, privilege, accessLevel
• El servidor nunca deberia confiar en el rol enviado por el cliente

4.5 Unrestricted Resource Consumption

Esto ocurre cuando una API permite a los usuarios consumir recursos excesivos: memoria, CPU, almacenamiento, ancho de banda o costos de servicios de terceros.

Por ejemplo, una API de productos normalmente devuelve 20 resultados por pagina con limit=20. Si lo cambias a limit=999999 y el servidor intenta devolver todo, la API puede ralentizarse o colapsar. Un endpoint de generacion de PDF que acepta pageCount=99999 puede consumir toda la memoria disponible.

Parametros a probar: limit, pageSize, batchSize, count, quantity, width, height, duration, fileSize, pageCount.

Advertencia: muchos programas de bug bounty no permiten pruebas de denegacion de servicio. Siempre mantente dentro del alcance y prueba con cuidado.

5. El OWASP API Top 10 explicado

El OWASP API Security Top 10 es la lista estandar de la industria sobre riesgos de seguridad en APIs. La actualizacion de 2023 reorganizo varias categorias:

Para principiantes, enfocate en estos primero:

1. API1 - Broken Object Level Authorization
2. API2 - Broken Authentication
3. API3 - Broken Object Property Level Authorization
4. API4 - Unrestricted Resource Consumption
5. API5 - Broken Function Level Authorization

Las cinco categorias restantes merecen atencion a medida que crecen tus habilidades de API hacking:

• API6 - Unrestricted Access to Sensitive Business Flows: abuso automatizado de logica de negocio (reventa de entradas, creacion masiva de cuentas)
• API7 - Server-Side Request Forgery (SSRF): forzar al servidor a hacer solicitudes a servicios internos mediante URLs proporcionadas por el usuario
• API8 - Security Misconfiguration: politicas CORS permisivas, errores detallados, TLS ausente, endpoints de depuracion expuestos
• API9 - Improper Inventory Management: APIs ocultas, versiones antiguas sin parches (siempre prueba /api/v1/ cuando existe /api/v2/), y documentacion Swagger expuesta
• API10 - Unsafe Consumption of Third-Party APIs: confiar en respuestas de APIs externas sin validacion

Los principiantes deberian primero fortalecerse en API1 a API5. Una vez que entiendas el control de acceso, la autenticacion, la exposicion de datos y los limites de recursos a traves de la practica, la lista completa se mapea naturalmente a los bugs que ya has probado.

6. Como configurar tu primer laboratorio de pruebas de APIs

Nunca pruebes sitios web aleatorios sin permiso. Las pruebas no autorizadas pueden violar leyes como la Computer Fraud and Abuse Act (CFAA) en Estados Unidos, la Computer Misuse Act en el Reino Unido, o legislacion equivalente en tu jurisdiccion. Usa primero laboratorios intencionalmente vulnerables para que puedas aprender sin riesgo legal. Para un recorrido completo del entorno, consulta nuestra guia de configuracion de laboratorio de ciberseguridad.

Configuracion paso a paso:

1. Instala Burp Suite Community Edition. Configura el proxy del navegador, instala el certificado CA de Burp y confirma que puedes capturar trafico HTTPS. La Web Security Academy de PortSwigger tiene una guia gratuita.

2. Despliega crAPI (Completely Ridiculous API). Este proyecto de OWASP esta construido especificamente para aprender seguridad de APIs. Incluye BOLA, broken authentication, excessive data exposure y otras vulnerabilidades mapeadas al API Top 10. Este es el mejor punto de partida.

3. Prueba VAmPI. Una REST API vulnerable simple para practicar pruebas de autenticacion y autorizacion.

4. Pasa a DVGA. Una vez comodo con las REST APIs, este laboratorio ensena problemas especificos de GraphQL como abuso de introspeccion, manipulacion de consultas y autorizacion rota en resolvers.

El metodo de practica: abre el laboratorio, usalo normalmente y captura el trafico en Burp Suite. Envia solicitudes al Repeater. Cambia IDs. Elimina tokens. Cambia roles. Modifica los cuerpos de las solicitudes. Aumenta los limites. Reproduce tokens antiguos. Lee cada respuesta.

Toma notas mientras practicas. Anota el endpoint, que cambiaste, que devolvio el servidor y por que el comportamiento es incorrecto. Este habito se traduce directamente en escribir informes de bugs reales y construir tu portafolio de seguridad.

7. Las 8 herramientas esenciales para pruebas de seguridad de APIs

No necesitas cien herramientas. Al principio, entiende unas pocas en profundidad.

1. Burp Suite - Tu herramienta principal. Intercepta, modifica, reproduce y compara solicitudes. Repeater es fundamental para probar una solicitud con pequenos cambios.

2. Postman - Construye solicitudes de API manualmente y organizalas en colecciones. Util cuando conoces el endpoint y quieres un flujo de trabajo estructurado.

3. jwt.io - Decodifica tokens JWT para ver claims como ID de usuario, rol, tiempo de expiracion y emisor. No hackea nada, pero te ayuda a entender que informacion lleva el token.

4. ffuf - Fuzzer web rapido para descubrir rutas, endpoints, parametros y valores ocultos.

5. Gobuster - Herramienta de descubrimiento de directorios y archivos. Complementa a ffuf para un escaneo mas amplio.

6. Kiterunner - Descubrimiento de rutas de API disenado especificamente para rutas de APIs. Mas consciente de APIs que los brute forcers de directorios genericos.

7. gau / waybackurls - Recopila URLs antiguas de archivos web para encontrar endpoints historicos de APIs como /api/ o /graphql.

8. Nmap - Descubre puertos abiertos y servicios. Usalo para encontrar servicios de API ejecutandose en puertos no estandar.

Para el analisis de trafico de APIs a nivel de red, Wireshark tambien es util, especialmente al depurar problemas de TLS y capa de transporte.

Las herramientas ahorran tiempo, pero no reemplazan el pensamiento. La mayoria de los buenos bugs en APIs se encuentran porque el tester entiende la logica, no porque una herramienta imprimio un resultado.

8. Como encontrar endpoints de APIs

Antes de encontrar bugs, necesitas encontrar la superficie de la API. Esto significa descubrir tantos endpoints como sea posible.

Usa la aplicacion. Inicia sesion, actualiza tu perfil, sube un archivo, busca algo, cambia la configuracion, crea un pedido, cancelalo, invita a un usuario, mira las notificaciones. Cada accion puede generar una solicitud de API.

Revisa los archivos JavaScript. Las aplicaciones web modernas almacenan rutas de API dentro de JavaScript. Busca palabras como api, v1, v2, graphql, auth, token, upload, admin, payment, settings, internal.

Busca documentacion de la API. Los archivos de Swagger UI u OpenAPI expuestos revelan endpoints, parametros, cuerpos de solicitud, requisitos de autenticacion y respuestas de ejemplo. Encontrar documentacion expuesta puede ahorrarte horas.

Escanea subdominios. Las APIs a menudo viven en subdominios como api.example.com, mobile.example.com, dev.example.com o staging.example.com. Las APIs mas antiguas o de staging frecuentemente tienen seguridad mas debil.

Busca en archivos web. Herramientas como gau y waybackurls revelan endpoints antiguos que aun existen en el servidor. Las busquedas en GitHub pueden revelar rutas de APIs, documentacion o claves filtradas en repositorios publicos.

El objetivo es construir un mapa completo antes de probar en profundidad. Si no conoces los endpoints, no sabes que probar.

Ahora que entiendes lo que estas buscando, construyamos la metodologia para encontrar tu primer bug real.

9. De los laboratorios de seguridad de APIs a programas reales de bug bounty

Una vez comodo con los laboratorios, empieza a probar programas reales. No te apresures con este paso.

Antes de probar:

• Lee el alcance del programa. Asegurate de que las pruebas de APIs estan permitidas
• Verifica que dominios y aplicaciones estan dentro del alcance
• Confirma si el escaneo automatizado o las pruebas de DoS estan restringidos
• Entiende las expectativas de divulgacion responsable del programa

Tu metodologia inicial:

1. Captura el trafico y mapea todos los endpoints de la API
2. Entiende los roles de usuario y los permisos
3. Prueba el acceso a nivel de objeto (BOLA/IDOR)
4. Inspecciona todas las respuestas de la API en busca de datos excesivos
5. Prueba el comportamiento de autenticacion (expiracion de tokens, cierre de sesion, restablecimiento de contrasena)
6. Verifica si los usuarios normales pueden llamar a funciones de administrador
7. Documenta todo a medida que avanzas

Seguir este checklist de seguridad de APIs para cada objetivo construye consistencia. Tu primer informe valido te ensenara mas que cualquier curso. Tu primer rechazo tambien te ensenara algo. Los rechazos son parte del bug bounty: a veces el problema no tiene suficiente impacto, a veces ya es conocido, a veces tus pasos no son claros. Lee la respuesta, mejora tu metodo y sigue probando.

10. Recursos de practica y proximos pasos

La practica con laboratorios y la lectura de informes reales deben ir juntas. Los laboratorios te ayudan a entender el bug. Los informes reales te ayudan a entender el impacto y el estilo de reporte.

Laboratorios y cursos:

• PortSwigger Web Security Academy - Formacion gratuita y completa en seguridad web con modulos enfocados en APIs
• crAPI - Laboratorio de seguridad de APIs creado por OWASP
• VAmPI - REST API vulnerable para pruebas de autenticacion
• Kontra - Explicaciones interactivas de vulnerabilidades
• APIsec University - Cursos dedicados a seguridad de APIs

Libros:

• Hacking APIs de Corey Ball - La guia practica definitiva para pruebas de penetracion de APIs
• Black Hat GraphQL de Nick Aleks y Dolev Farhi - Inmersion profunda en seguridad de GraphQL

Lee informes divulgados. Busca en HackerOne y Bugcrowd informes etiquetados con API, IDOR, BOLA, broken authentication y excessive data exposure. Leer algunos informes cada semana entrena tu reconocimiento de patrones.

Ejemplos de Google dorks para encontrar informes publicos:

• site:hackerone.com/reports/* intext:API
• site:hackerone.com/reports/* intext:IDOR
• site:hackerone.com/reports/* intext:GraphQL

Tu ruta de aprendizaje:

Si empiezas desde cero, sigue esta secuencia: aprende HTTP y JSON, luego Burp Suite. Practica con crAPI. Entiende BOLA en profundidad. Pasa a broken authentication, excessive data exposure, function-level authorization y limites de recursos. Lee informes reales. Inicia programas de bug bounty. Valida tus habilidades con certificaciones de ciberseguridad para principiantes para ver donde encajan las pruebas de seguridad de APIs en el panorama mas amplio de la seguridad ofensiva.

Tu primer bug en una API puede venir de cambiar un ID, reproducir un token o notar un campo oculto en una respuesta JSON. Las pruebas de seguridad de APIs no se tratan de memorizar payloads. Se tratan de entender la confianza y aplicar las mejores practicas de seguridad de APIs en cada capa. Puede la API confiar en este usuario? Puede confiar en este ID? Puede confiar en este valor de rol? La mayoria de los bugs en APIs ocurren cuando el servidor confia en algo que deberia verificar.

Esa es exactamente la razon por la que las pruebas de penetracion de APIs son un lugar tan poderoso para iniciar tu carrera en ciberseguridad.