Icono del sitio Jaymon security

Testing de APIs REST con Burp Suite: laboratorio práctico de seguridad

Juan M. R.

El Testing de APIs REST con Burp Suite es esencial para cualquier equipo de seguridad. En este artículo realizamos un laboratorio práctico paso a paso, tal y como hacemos en Jaymon Security con nuestros clientes.

Artículos relacionados: Práctica de inyección en Base de Datos tipo NoSQL (NoSQLi) y Análisis y estudio de Inyección SQL Blind.

1. Introducción

Las APIs REST son el sistema nervioso de las aplicaciones modernas: conectan frontend con backend, microservicios entre sí, y permiten que los dispositivos móviles accedan a datos en tiempo real. Pero si una base de datos mal protegida puede ser vulnerada con SQL injection, una API mal diseñada puede exponer toda la infraestructura con un solo payload.

En este artículo vamos a realizar un laboratorio completo de seguridad sobre una API REST usando Burp Suite, la herramienta estándar de facto para pentesting web. Cubriremos desde el descubrimiento de endpoints hasta la explotación de vulnerabilidades comunes: IDOR, falta de rate limiting, inyección en parámetros y errores de autenticación.

2. ¿Qué es una API REST y por qué es un objetivo prioritario?

Una API REST (Representational State Transfer) expone recursos mediante URLs y métodos HTTP estándar (GET, POST, PUT, DELETE). Cada recurso se identifica con un endpoint como /api/v1/users/42, y los datos se intercambian en formato JSON.

A diferencia de una aplicación web tradicional donde el HTML se genera en el servidor, las APIs devuelven datos puros que cualquier cliente (navegador, app móvil, script) puede consumir. Esto significa que un atacante no necesita un navegador para explotar la API: basta con enviar peticiones HTTP.

En 2026, según el informe OWASP Top 10 for APIs, las vulnerabilidades de identificación insegura (API4) y los errores de masas (API8) son las más frecuentes. Burp Suite es la herramienta que permite detectarlas todas.

3. Montando el escenario

Usaremos un entorno local con una API REST de ejemplo construida en Python (Flask), accesible en http://localhost:5000. También puedes usar cualquier API pública de pruebas como JSONPlaceholder.

Instalamos Burp Suite Community (gratuita) o Professional. Configuramos el proxy en 127.0.0.1:8080 y configuramos nuestro navegador para que use ese proxy.

# API de ejemplo con Flask
from flask import Flask, jsonify, request

app = Flask(__name__)

# Base de datos simulada
USERS = {
    "1": {"id": 1, "email": "ana@empresa.es", "role": "admin", "saldo": 320.50},
    "2": {"id": 2, "email": "luis@empresa.es", "role": "user", "saldo": 12.00},
}

@app.route('/api/v1/users', methods=['GET'])
def get_users():
    return jsonify(list(USERS.values()))

@app.route('/api/v1/users/<id>', methods=['GET'])
def get_user(id):
    user = USERS.get(id)
    if not user:
        return jsonify({"error": "User not found"}), 404
    return jsonify(user)

@app.route('/api/v1/users', methods=['POST'])
def create_user():
    data = request.json
    new_id = str(len(USERS) + 1)
    USERS[new_id] = {"id": int(new_id), **data}
    return jsonify(USERS[new_id]), 201

if __name__ == '__main__':
    app.run(port=5000)

Fig. 1 – API REST de ejemplo con endpoints GET y POST para gestión de usuarios.

4. Descubrimiento de endpoints

El primer paso es mapear la superficie de ataque. En Burp Suite, abrimos Target → Site Map y navegamos por la API con el navegador proxy o con la herramienta Repeater.

4.1. Exploración manual con Repeater

Enviamos peticiones GET a los endpoints conocidos:

GET /api/v1/users HTTP/1.1
Host: localhost:5000
Accept: application/json

# Respuesta esperada: lista de todos los usuarios
[{"id": 1, "email": "ana@empresa.es", "role": "admin", "saldo": 320.50}, ...]

Luego probamos con IDs diferentes para ver si hay IDOR (Insecure Direct Object Reference):

GET /api/v1/users/1 HTTP/1.1
Host: localhost:5000

# Devuelve datos del admin

GET /api/v1/users/2 HTTP/1.1
Host: localhost:5000

# Devuelve datos de un usuario normal — ¿hay diferencia en la respuesta?

Si el endpoint /users/<id> devuelve todos los campos (incluido role) para cualquier ID, estamos ante una vulnerabilidad IDOR: un usuario normal puede ver si es admin o no.

4.2. Fuzzing de parámetros con Intruder

Usamos Intruder para probar valores extremos en los IDs:

Payload positions: /api/v1/users/§0§
Payloads: 0, -1, 999999, abc, NULL, '', --

Si la API devuelve datos para /users/-1 o /users/abc, puede estar sufriendo una inyección de parámetros. Si devuelve un error 500 con el stack trace, tenemos información adicional sobre la implementación.

5. Explotación: vulnerabilidades comunes

5.1. IDOR — Acceso no autorizado a recursos

El atacante cambia el ID en la URL para acceder a datos de otros usuarios:

# Usuario "ana" (admin) hace login y obtiene token JWT
# Luego consulta su propio perfil:
GET /api/v1/users/1 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# Ahora cambia el ID para ver a otro usuario:
GET /api/v1/users/2 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# Respuesta: {"id": 2, "email": "luis@empresa.es", "role": "user", "saldo": 12.00}

Defensa: validar que el usuario autenticado tiene permiso para acceder al recurso solicitado (ownership check).

5.2. Falta de rate limiting

Sin limitación de peticiones, un atacante puede hacer brute force sobre credenciales o exfiltrar datos:

# Burp Intruder con 1000 intentos en segundos
POST /api/v1/login HTTP/1.1
Content-Type: application/json

{"email": "admin@empresa.es", "password": "§0§"}

# Payloads: lista de contraseñas comunes (rockyou.txt)

Defensa: implementar rate limiting por IP y por usuario, con respuestas 429 Too Many Requests.

5.3. Inyección en parámetros JSON

Al crear un nuevo usuario, enviamos datos adicionales que la API no filtra:

POST /api/v1/users HTTP/1.1
Content-Type: application/json

{
  "email": "test@empresa.es",
  "password": "pass123",
  "role": "user"
}

# Ahora añadimos un campo extra:
{
  "email": "hacker@empresa.es",
  "password": "pass123",
  "role": "admin"
}

# Si la API no filtra el campo "role", creamos un admin.

Defensa: usar listas blancas de campos aceptados (whitelist) en el backend.

5.4. Error mass assignment

Similar a la inyección anterior, pero con campos ocultos como is_verified, balance o created_at:

{
  "email": "hacker@empresa.es",
  "password": "pass123",
  "balance": 9999.99,
  "is_verified": true
}

Defensa: mapear explícitamente los campos del request a las columnas de la base de datos.

6. Análisis con Burp Suite Professional (opcional)

Si disponemos de la versión Professional, podemos automatizar el análisis:

Fig. 2 – Panel de resultados del Automated Scan mostrando vulnerabilidades detectadas.

7. Conclusiones

Las APIs REST son el punto de entrada más expuesto en las aplicaciones modernas, y Burp Suite es la herramienta esencial para evaluar su seguridad. Los cuatro vectores que hemos cubierto —IDOR, falta de rate limiting, inyección JSON y mass assignment— representan la mayoría de vulnerabilidades reales encontradas en producción.

La defensa correcta combina: validación estricta de entrada (whitelist), ownership checks para IDOR, rate limiting configurable, autenticación robusta con JWT o OAuth2, y pruebas automatizadas continuas. En Jaymon Security ayudamos a las organizaciones a proteger sus APIs desde el diseño hasta la producción.

8. Referencias

¿Necesitas ayuda con Testing de APIs REST con Burp Suite?

En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.

Contacta con nosotros para una evaluación gratuita de tu infraestructura.

Salir de la versión móvil