Pentest de aplicaciones web y API para banca en línea, billeteras y fintech en Centroamérica

Un escáner encuentra versiones viejas y cabeceras mal puestas. Lo que no ve es si un cliente puede consultar la cuenta de otro cambiando un número en la solicitud, o si un operador puede aprobar su propia transferencia. Esos fallos de autorización y de lógica de negocio son los que más pesan en una aplicación financiera, y solo aparecen cuando una persona usa la aplicación con cada rol y compara lo que cada uno debería poder hacer.

La prueba cubre autenticación y manejo de sesiones, control de acceso entre usuarios y entre roles, validación de datos de entrada, manejo de errores, configuración del servidor y de la API, y los flujos de negocio sensibles: transferencias, cambios de datos de contacto, alta de beneficiarios, recuperación de contraseña.

OWASP es una fundación abierta que publica las referencias más usadas para seguridad de aplicaciones. Sus listas no son una norma que alguien certifique. Sirven para que usted, el proveedor y su auditor hablen de las mismas categorías y para comprobar que la prueba no dejó fuera un tipo de falla.

Para aplicaciones web usamos el OWASP Top 10 en su edición 2025, que incluye entre otras el control de acceso roto, la configuración insegura, las fallas de la cadena de suministro de software, la inyección y las fallas de autenticación. Para APIs usamos el OWASP API Security Top 10 de 2023, donde los tres primeros riesgos son de autorización a nivel de objeto, de autenticación y de autorización a nivel de propiedad. Como guía de método está la OWASP Web Security Testing Guide, versión estable 4.2.

Si su aplicación maneja datos de tarjetas, PCI DSS v4.0.1 pide en el Requisito 11.4.1 que la metodología de pentest incluya pruebas a nivel de aplicación que cubran, como mínimo, las vulnerabilidades del Requisito 6.2.4.

Las normas bancarias de la región hablan de plataforma o infraestructura tecnológica y no separan la aplicación de la red. En El Salvador, la NRP-23 va un poco más allá. Su Art. 21 pide definir controles sobre la implementación de aplicaciones antes del ingreso a producción, y contar con mecanismos de desarrollo seguro que permitan analizar y corregir las vulnerabilidades de las aplicaciones, también cuando ya están en producción. Su Art. 20 i) pide pruebas de vulnerabilidad e intrusión al menos una vez al año y cuando existan cambios.

En Honduras, el Art. 24 de la Circular CNBS 025/2022 deja el alcance a un análisis del perfil de riesgo de los procesos a revisar. Para la mayoría de las instituciones, la banca en línea es uno de los procesos de mayor riesgo, y el análisis debería decirlo. En Guatemala, la JM-98-2025 pide pentest interno y externo anual con informe técnico, y la aplicación publicada es parte de lo externo.

Los proveedores de bancos, como fintech, procesadores y empresas de software, reciben la pregunta por otro lado. Un banco guatemalteco debe obtener informes de auditorías independientes del último año de sus proveedores críticos de tecnología, según los Art. 40 y 45 de la JM-98-2025. En Honduras, la circular pide auditoría independiente periódica del procesamiento tercerizado (Art. 14).

El tiempo de prueba crece con los roles y con los endpoints o pantallas principales. Cada rol hay que probarlo contra los demás, y cada endpoint es una puerta que revisar. Por eso el paquete de Toukan se define así: una aplicación web o API, hasta 2 roles de usuario y hasta 20 endpoints, con 5 días de prueba manual, desde USD 3,000, con una verificación de correcciones dentro de 90 días.

Una banca en línea con cliente persona, cliente empresa, firmante y administrador tiene cuatro roles, y se cotiza según eso. Si además necesita la red externa, el paquete de auditoría une red externa y una aplicación web en 8 días, desde USD 5,500.

La preparación decide cuánto rinden los cinco días. Lo que más retrasa un pentest de aplicaciones es esperar credenciales o descubrir el primer día que el ambiente de pruebas no tiene datos.

• Un ambiente para la prueba. Si es de pruebas, que sea igual a producción en versión y configuración. Si es producción, acuerde qué operaciones se pueden ejecutar.
• Dos usuarios por rol, para probar si uno puede ver o tocar lo del otro.
• La documentación de la API, como una colección o una especificación, si existe.
• Datos de prueba suficientes: cuentas con saldo ficticio, beneficiarios, comercios.
• Un contacto técnico que responda durante la ventana de prueba.
• La autorización escrita del tercero si la aplicación corre en infraestructura de un proveedor.

De la firma al informe pasan entre 2 y 4 semanas. El informe ejecutivo explica a la gerencia qué riesgo encontramos, en términos de clientes y dinero. El informe técnico trae cada hallazgo con el endpoint, el rol usado, la evidencia, los pasos para reproducirlo, el impacto y la corrección sugerida, con su categoría OWASP. Ambos los firma la persona que acordó el alcance y dirigió la prueba.

Cada hallazgo se confirma a mano. Un ejemplo ilustrativo del tipo de hallazgo que buscamos: un cliente consulta los movimientos de otra cuenta cambiando el número de cuenta en la solicitud, y la corrección es validar en el servidor que la cuenta pedida pertenece a la sesión. Cuando su equipo corrija, volvemos a probar dentro de 90 días y marcamos cada hallazgo como corregido o pendiente.