Qué revisa un pentest de API y qué no

Una API es la puerta por la que tu aplicación móvil, tu portal web y tus integraciones hablan con tu servidor. Casi todos los datos de tus clientes pasan por ahí. Un pentest de API es una prueba de penetración enfocada en esa puerta: una persona intenta usarla de formas que el diseño no previó y documenta lo que consigue. Esto es lo que cubre, lo que no, y qué pedir en el reporte.

Qué revisa

Usamos como referencia el OWASP API Security Top 10 de 2023, que es la lista con la que la industria organiza estos hallazgos. En la práctica, un pentest de API revisa:

• Autorización por objeto (BOLA o IDOR). Cambiar un identificador en la petición y ver datos de otro cliente. Es el fallo más común en APIs y el que más datos expone.
• Autenticación y sesiones. Tokens que no expiran, contraseñas recuperables por fuerza bruta, tokens de un ambiente que sirven en otro, sesiones que sobreviven al cierre.
• Autorización por propiedad y por función. Modificar campos que el usuario no debería poder tocar, como el precio o el rol, y llamar funciones administrativas desde una cuenta normal.
• Límites de uso. Sin límites por cliente, una API se usa para enumerar usuarios, agotar códigos de un solo uso o tumbar el servicio con pocas peticiones.
• Flujos de negocio sensibles. Cupones, pagos, devoluciones, registro masivo. Aquí no hay firma de vulnerabilidad: hay que entender el negocio y probar el abuso.
• Falsificación de peticiones del lado del servidor (SSRF). Hacer que el servidor consulte direcciones internas que el atacante no alcanza directo.
• Configuración. CORS abierto, cabeceras de seguridad ausentes, mensajes de error con detalles internos, versiones viejas de la API todavía en línea, documentación expuesta.
• Inventario. Endpoints que nadie documentó y siguen respondiendo.
• Consumo de APIs de terceros. Confiar sin validar en lo que devuelve un proveedor externo.

Además de la lista, un buen pentest revisa la lógica propia de tu aplicación. Un 20 por ciento de descuento aplicado dos veces no está en ninguna lista y es dinero.

Qué no revisa

• Denegación de servicio real. Se identifican los puntos débiles, no se tumba tu servicio en producción.
• Ingeniería social. Nadie llama a tu personal para pedir contraseñas, salvo que se contrate por separado y con reglas claras.
• Infraestructura fuera del alcance. Si el alcance es la API, no se prueba la red interna ni los equipos del personal.
• Código que no se compartió. En caja negra se prueba lo que la API expone. Con código y credenciales por rol se encuentra más en menos tiempo.
• Cumplimiento normativo completo. Un pentest aporta evidencia para una revisión de la LFPDPPP o de una norma, pero no la sustituye.
• La ausencia de vulnerabilidades. Un reporte sin hallazgos críticos dice que no se encontraron en ese alcance y en ese tiempo. Nadie puede prometer más.

Si un proveedor promete que después del pentest tu API es segura, está vendiendo otra cosa.

Qué pedir en el reporte

• Cada hallazgo con evidencia reproducible: petición, respuesta y pasos.
• Severidad con criterio conocido, como CVSS, y el impacto explicado en términos de negocio.
• Remediación priorizada: qué arreglar primero y por qué.
• Un resumen de una página para dirección.
• Repetición de las pruebas sobre lo corregido, con reporte de cierre.

Cómo prepararte

• Un ambiente de pruebas parecido a producción, con datos ficticios.
• Credenciales por rol: cliente, administrador, socio, lo que exista.
• La documentación de la API, aunque esté desactualizada.
• Una ventana de pruebas y un contacto que responda si algo se cae.
• Autorización por escrito con el alcance exacto.

Así hacemos el pentest en Norte, con el mismo criterio con el que reportamos fallos a terceros. Qué incluye, qué se entrega y cómo trabajamos está en seguridad ofensiva. Los reportes aceptados por Shopify, Škoda Auto, Dstny y Suricata están enlazados en investigación.