Cuando tu tienda envía un pedido al sistema de despacho o una aplicación consulta el estado de una solicitud, probablemente utiliza una API: una conexión que permite a dos sistemas intercambiar información y ejecutar acciones. El usuario no suele verla, pero puede sostener una parte central de la experiencia.

Para revisar su seguridad, conviene dejar de hablar de “la integración” como si fuera una sola pieza. Identifica quién envía datos, quién los recibe, qué permiso utiliza y qué operación puede ordenar. Este mapa permite que negocio y tecnología conversen sobre consecuencias concretas en vez de limitarse a comprobar si la conexión responde.

Haz visible lo que está conectado

Prepara una lista de integraciones con responsable interno, proveedor, propósito y datos involucrados. Incluye conexiones antiguas que todavía se utilizan y ambientes de prueba que quedaron disponibles. Pregunta cómo se enterará tu empresa si el proveedor cambia una función o retira una versión.

El OWASP API Security Top 10 de 2023 reúne riesgos como permisos incorrectos, consumo de recursos sin límites, inventarios incompletos y confianza excesiva en APIs externas. Esta clasificación sirve para orientar preguntas; no reemplaza una evaluación de las conexiones y procesos que efectivamente tiene tu empresa.

Distingue consultar información de poder modificarla

Una integración puede requerir leer el estado de un pedido sin necesitar cancelar pedidos ni cambiar datos de clientes. Pide que el alcance del acceso se describa por acciones. Si el permiso disponible es más amplio de lo necesario, el equipo debe evaluar alternativas y documentar qué riesgo permanece.

Incluye la separación entre clientes. Que un sistema se identifique correctamente no responde si puede solicitar información de cualquier organización. Para el negocio, la pregunta es sencilla: cuál es el conjunto de registros que esa conexión está autorizada a ver. La prueba técnica debe verificar esa regla en las funciones acordadas.

Define qué ocurre cuando la conexión se equivoca

La revisión también debe considerar respuestas incompletas, operaciones repetidas y demoras. Antes de hablar de soluciones, acuerda el comportamiento esperado: si un proveedor no responde, ¿el pedido queda pendiente, se cancela o se reintenta? ¿Quién puede distinguir una operación no ejecutada de una que se ejecutó pero no confirmó?

Estas decisiones ayudan a evitar respuestas improvisadas durante una interrupción. Un estado visible para atención al cliente puede ser más útil que un mensaje genérico de error. Pide que el equipo registre la información necesaria para seguir una operación entre sistemas, sin copiar datos privados que no sean relevantes para investigar.

Piensa en volumen y costo, además de disponibilidad

Algunas conexiones disparan tareas que tienen costo: mensajes, procesamiento de documentos o consultas a servicios pagados. Establece con negocio qué volumen es razonable y qué variación amerita revisar. La capacidad técnica y el gasto tolerable son decisiones relacionadas, pero no equivalentes.

Puedes pedir una ficha por operación importante con su propósito, costo asociado, límite esperado y persona que recibe un aviso. El equipo técnico determinará cómo aplicar controles adecuados. Las pruebas de volumen requieren planificación específica: no deben poner en riesgo el servicio real ni consumir sin coordinación recursos facturados por terceros.

Pide una entrega que sirva para mantener la integración

  • Qué versiones y funciones se revisaron.
  • Qué credenciales se usan y quién administra su reemplazo.
  • Qué reglas de acceso se comprobaron y qué quedó pendiente.
  • Cómo se detectan errores y quién coordina con el proveedor.
  • Qué cambio obliga a revisar nuevamente la conexión.

En BlackDoor podemos incluir APIs dentro de una evaluación de ethical hacking o examinar su implementación mediante una auditoría de código. Al solicitar una propuesta, explica qué sistemas conectan y qué operaciones dependen de ellas. Eso permite definir una revisión útil para la continuidad y la seguridad de tu negocio.

Qué pedir en una propuesta de pentest de API

Describe la conexión por su función: consultar pedidos, actualizar contratos o enviar documentos. Después identifica quién la usa y qué límites debería respetar. Esta información permite convertir referencias como el OWASP API Security Top 10 en pruebas de tu operación, en vez de recibir una lista genérica de riesgos.

  • ¿Qué funciones y versiones estarán disponibles para evaluar?
  • ¿Con qué perfiles se comprobará la separación entre clientes y permisos?
  • ¿Qué sistemas externos requieren autorización o un ambiente de prueba?
  • ¿Qué comprobaciones podrían interrumpir una operación o generar un cargo?

El equipo técnico puede entregar documentación y accesos por un canal acordado. En la solicitud inicial basta describirlos; no es necesario copiar credenciales ni datos reales de clientes.

Una entrega que permita corregir la integración

Pide que los resultados relacionen cada problema con una función, una condición de acceso y una consecuencia para el proceso. Desarrollo necesita evidencia útil para corregir; negocio necesita saber qué información u operación podría verse afectada. Ambas lecturas deben referirse a la misma versión evaluada.

Si hace falta examinar cómo se implementó una regla, acuerda una revisión de código adicional. Si la prioridad es comprobar el comportamiento accesible de la API, delimita las pruebas autorizadas. La propuesta debe dejar claro qué incluye cada trabajo y si contempla verificar las correcciones.