Pruebas de seguridad de API REST y GraphQL
Gjethe prueba las API directamente, como lo hacen los atacantes: autorización en cada objeto, autenticación, cuántos datos devuelven las respuestas, asignación masiva, límites de peticiones y flujos de negocio. Las pruebas siguen el OWASP API Security Top 10, y cada hallazgo incluye evidencias, una corrección y una nueva prueba.
- Primera consulta gratuita
- Presupuesto por escrito para su proyecto
- Pagos fraccionados por hitos, con flexibilidad
De un vistazo
- Tipos de API
- REST, GraphQL, WebSocket
- Standard
- OWASP API Security Top 10
- Enfoque
- Autorización, exposición de datos, límites de peticiones
- Resultado
- Informe, correcciones y nueva prueba
Definition
Qué es las pruebas de seguridad de API?
Las pruebas de seguridad de API son la evaluación de una interfaz de programación de aplicaciones en busca de puntos débiles que permitan a quien la llama acceder a datos o funciones que no debería, enviando peticiones manipuladas directamente a sus endpoints.
Las aplicaciones móviles, las aplicaciones web de una sola página, los socios y las integraciones hablan todos con su API. La interfaz puede ocultar campos y botones, pero la API responde a cualquiera que envíe la petición correcta. Por eso las API a menudo exponen más de lo previsto: registros completos cuando la aplicación solo muestra un nombre, acciones accesibles cambiando una dirección o ningún límite a la rapidez con que alguien puede probar inicios de sesión o extraer datos. Las pruebas de API dejan la interfaz a un lado y comprueban lo que permite el propio servidor.
¿Para quién es?
Equipos con una API pública o para socios
Todo lo que se expone a otros desarrolladores queda expuesto a cualquiera que lea su documentación.
Backends de aplicaciones móviles
La aplicación es solo un cliente; la API tiene que defenderse de cualquier petición.
Arquitecturas de microservicios
Los servicios internos a menudo confían demasiado entre sí; revisamos esos límites.
Productos con pagos o créditos
El dinero, los saldos y las cuotas son objetivos principales de abusos de lógica y de límites de peticiones.
Qué está incluido y qué se queda usted
Qué incluye
- Revisión de la documentación y del esquema de la API
- Descubrimiento de endpoints y operaciones
- Pruebas de autorización a nivel de objeto
- Pruebas de autorización a nivel de función
- Revisión de autenticación y gestión de tokens
- Comprobaciones de exposición excesiva de datos
- Pruebas de asignación masiva y tratamiento de entradas
- Pruebas de límites de peticiones y abuso de recursos
- Pruebas de flujos de negocio y secuencias
- Comprobaciones específicas de GraphQL cuando proceda
- Revisión del transporte y la configuración
- Informe con evidencias, correcciones y una nueva prueba
Lo que recibe
Se entrega al final. Suyo para siempre.
- Informe de pruebas de seguridad de API
- Hallazgos asignados al OWASP API Top 10
- Descripción clara de cada problema confirmado
- Recomendaciones de corrección para cada hallazgo
- Informe de la nueva prueba
Áreas del OWASP API Security Top 10 que cubrimos
| Área | Ejemplo de lo que comprobamos |
|---|---|
| Autorización rota a nivel de objeto | Leer el registro de otro usuario cambiando un identificador |
| Autenticación rota | Tokens débiles, ausencia de caducidad, credenciales adivinables |
| Autorización rota a nivel de propiedad de objeto | Establecer campos que quien llama no debería controlar |
| Consumo de recursos sin restricciones | Sin límites de peticiones en operaciones costosas o sensibles |
| Autorización rota a nivel de función | Llamar a operaciones de administrador como un usuario normal |
| Acceso sin restricciones a flujos de negocio | Automatizar un flujo pensado para hacerse una sola vez |
| Server-side request forgery (SSRF) | La API accede a direcciones que controla quien la llama |
| Configuración de seguridad incorrecta | Errores detallados, endpoints de depuración, ajustes laxos |
| Gestión inadecuada del inventario | Versiones antiguas olvidadas que siguen aceptando peticiones |
| Uso inseguro de terceros | Confiar en datos de una API externa sin comprobarlos |
Por qué las API filtran más de lo que muestra la aplicación
Una página web muestra a un cliente su propio nombre y nada más. Sin embargo, la petición que hay detrás puede devolver el registro completo del usuario, incluidos campos que la página ignora sin más. Los atacantes leen las respuestas directamente, así que todo lo que envía el servidor es, en la práctica, público para quien pueda llamar al endpoint.
Probamos desde el lado de quien llama: cada endpoint se ejercita como distintos usuarios y roles, con identificadores y campos modificados, para ver si el servidor comprueba quién pregunta y devuelve solo lo que esa persona puede ver. GraphQL recibe una atención adicional, porque una única consulta flexible puede llegar mucho más lejos que una ruta REST fija si las reglas no se aplican por campo.
Por qué las API necesitan sus propias pruebas
Es tentador pensar que probar el sitio web también prueba la API que hay detrás. No es así. El sitio web usa la API de la forma que sus diseñadores pretendían, a través de los botones y pantallas que construyeron. Un atacante ignora todo eso y llama directamente a los endpoints, en cualquier orden, con cualquier valor y como cualquier cuenta que pueda conseguir. Categorías enteras de problemas solo aparecen desde ese ángulo: un endpoint que confía en un ID de usuario de la petición, un campo que debería ser de solo lectura pero se puede escribir, una operación sin límite de veces que puede ejecutarse.
Probar la API por separado también protege a todos los clientes que dependen de ella. Una sola API suele dar servicio a una aplicación web, una aplicación móvil y a menudo integraciones de socios a la vez. Un punto débil allí queda expuesto a todos ellos, así que corregirlo a nivel de API protege todo el producto y no solo una pantalla.
Cómo funcionan las pruebas de seguridad de API, paso a paso
Cada paso tiene un resultado claro que puede revisar. Los plazos se acuerdan en su presupuesto.
- 1
Alcance
API, entornos, roles y credenciales de prueba acordados por escrito.
- 2
Mapa
Endpoints, operaciones y roles catalogados a partir de la documentación y del tráfico.
- 3
Probar
Autorización, autenticación, exposición de datos y abusos probados manualmente.
- 4
Verificar
Cada hallazgo confirmado con cuidado, con evidencias seguras.
- 5
Informe
Hallazgos asignados al API Top 10, con correcciones.
- 6
Repetición de pruebas
Correcciones verificadas e informe actualizado.
Herramientas y qué determina su presupuesto
El precio depende de su proyecto y se acuerda en su presupuesto. Esto es lo que lo hace variar.
| Factor | Por qué importa |
|---|---|
| Número de endpoints | Más operaciones implican más pruebas de autorización y de entradas. |
| Número de roles | Cada rol debe probarse en cada operación sensible. |
| REST frente a GraphQL | GraphQL requiere comprobaciones por campo y pruebas del coste de las consultas. |
| Calidad de la documentación | Unos buenos esquemas y colecciones hacen que las pruebas sean más rápidas y completas. |
| Flujos de negocio | Los pagos, las cuotas y los flujos de varios pasos requieren pruebas de lógica cuidadosas. |
| Área | Tools |
|---|---|
| Pruebas | Burp Suite, Postman, scripts a medida |
| GraphQL | herramientas de introspección de esquemas, herramientas de consultas |
| Support | herramientas OpenAPI, captura de tráfico |
| Orientación | OWASP API Security Top 10, OWASP ASVS, CVSS |
Errores habituales que evitar
Lo que vemos fallar con más frecuencia y cómo lo evita un buen proyecto.
Comprobar los permisos solo en la aplicación
Si la API no vuelve a comprobar en cada petición, las restricciones de la aplicación no sirven de nada.
Devolver objetos completos
Enviar registros completos y dejar que el cliente elija los campos lo expone todo a cualquiera que lea las respuestas.
Sin límites de peticiones
Sin límites, se pueden adivinar inicios de sesión y extraer datos de forma masiva.
Versiones antiguas olvidadas
Las versiones antiguas de una API que siguen funcionando a menudo carecen de las correcciones añadidas a la actual.
Preguntas frecuentes
¿Necesitan nuestra documentación de la API?
Ayuda mucho. Un esquema, una colección de Postman o una definición OpenAPI o GraphQL acelera las pruebas y mejora la cobertura. Cuando falta, mapeamos los endpoints a partir del tráfico de sus clientes.
¿Pueden probar una API GraphQL?
Sí. GraphQL requiere comprobaciones de autorización por campo y pruebas del coste de las consultas, que cubrimos junto con las áreas estándar de las API.
¿Afectarán las pruebas a nuestros datos de producción?
Preferimos un entorno de pruebas con datos de prueba. Si debemos probar en producción, usamos cuentas de prueba, acordamos ventanas horarias y evitamos acciones que modifiquen registros reales.
¿Prueban proveedores de autenticación como OAuth?
Probamos cómo usa su API los tokens y las sesiones: caducidad, alcance, validación y tratamiento. El proveedor de identidad en sí suele quedar fuera del alcance, salvo que lo gestione usted.
¿En qué se diferencia de una prueba de aplicación web?
Una prueba de aplicación web trabaja a través de la interfaz; una prueba de API trabaja directamente contra los endpoints, que es donde se conectan realmente las aplicaciones móviles, las integraciones y las aplicaciones de una sola página.
¿Incluyen una nueva prueba?
Sí. Cuando haya corregido los hallazgos, los volvemos a probar y actualizamos el informe.
¿Pueden ayudar a corregir los hallazgos?
Sí. Nuestros desarrolladores pueden implementar las correcciones o revisar los cambios de su equipo antes de la nueva prueba.
¿Firman un acuerdo de confidencialidad?
Sí. Los hallazgos son confidenciales y solo se comparten con los contactos que usted indique, y los datos de prueba se eliminan después.
¿Prueban también versiones antiguas de la API?
Sí, cuando están dentro del alcance. Las versiones antiguas que siguen funcionando son un punto débil habitual, porque las correcciones añadidas a la versión actual a menudo no se aplican nunca a ellas.
¿Qué necesitan de nosotros para empezar?
La dirección base de cada API, credenciales para cada rol, cualquier esquema o documentación de que disponga y un contacto designado por si algo requiere atención durante las pruebas.
Servicios relacionados
Pruebas de penetración
Pruebas de seguridad autorizadas y acotadas, con un informe de correcciones.
Pruebas de penetración de aplicaciones web
Pruebas manuales OWASP de inicios de sesión, control de acceso y lógica.
Revisión de código seguro
Revise su código en busca de fallos de seguridad antes del lanzamiento.
Desarrollo de API a medida
API REST, GraphQL y WebSocket documentadas.
Integración de API
Conecte las herramientas que ya utiliza para que los datos fluyan solos.
Evaluación de vulnerabilidades
Identifique, priorice y planifique las correcciones de debilidades conocidas.
Pruebas de seguridad de API por sector
Vea lo que su API permite realmente.
Cuéntenos qué necesita. Recibirá una valoración honesta, un plan claro y un presupuesto por escrito. La primera consulta es siempre gratuita.
- Qué ocurre después
- 1Usted nos cuenta qué necesita
- 2Nos proponemos responder en 24 horas con preguntas
- 3Recibe un presupuesto por escrito para su proyecto