Contenido del artículo
La seguridad de una web y una API se revisa con un test de penetración de aplicación web: con autorización por escrito, un especialista intenta a mano hacer lo que harían los atacantes, con cada rol de usuario y siguiendo las listas de riesgos OWASP Top 10 y OWASP API Security Top 10. Recibes un informe con hallazgos reproducidos, su impacto en el negocio y el orden de las correcciones, y después una segunda comprobación de esas correcciones; en Ucrania, Veiltrack es una de las empresas que hace este pentest de web y API.
Un test de aplicación web significa una revisión de tu web, del área de clientes y de la API por una persona que piensa como un atacante, pero trabaja solo dentro de límites acordados. La API (la forma en que las aplicaciones intercambian datos) a menudo importa más que la propia web: por ella funcionan tu app móvil, las integraciones con socios y los pagos. Abajo te explico los riesgos más importantes en palabras sencillas, qué necesitas aportar, qué queda fuera y qué recibes al final.
En resumen
- Los riesgos principales están descritos en dos listas de OWASP (una comunidad internacional sin ánimo de lucro dedicada a la seguridad de aplicaciones): una para aplicaciones web y otra aparte para APIs. [1] [2]
- El problema más común y más caro es sencillo: un usuario ve o cambia datos de otro. Solo lo encuentra una persona con varias cuentas de prueba.
- Tú aportas el alcance, dos cuentas de prueba por rol, la documentación de la API y la autorización por escrito.
- El test no toca servicios de terceros sin permiso de su dueño y no garantiza que no queden fallos.
- Un informe útil explica el impacto en el negocio, muestra cómo reproducir cada hallazgo y dice con honestidad qué no se probó.
Qué se revisa: los riesgos OWASP en palabras sencillas
OWASP Top 10 (edición de 2021) describe los diez riesgos más importantes para aplicaciones web, y OWASP API Security Top 10 (2023) hace lo mismo para APIs. [1] [2] En 2025 salió una nueva edición de la lista web, y el control de acceso roto vuelve a estar en primer lugar. [3] A un dueño de negocio le sirve más entender qué puede pasar que memorizar números. Estos son ocho riesgos que más suelen importar en una web con área de clientes y API.
| Riesgo | Ejemplo | Cómo se revisa |
|---|---|---|
| Datos ajenos por número (A01, API1) | Un cliente cambia el número de pedido en la dirección o en la petición a la API y ve el pedido de otro con teléfono y dirección | Con una cuenta de prueba se intenta abrir pedidos, documentos y perfiles de otra |
| Acciones fuera del rol (A01, API5) | Un gestor llama directamente por la API a la función de administrador «borrar usuario», aunque no tenga el botón | Se repiten las peticiones del administrador con una cuenta con menos permisos |
| Campos de más en peticiones y respuestas (API3) | La API devuelve la ficha completa del cliente con datos del pasaporte aunque la pantalla solo muestre el nombre; o un usuario se añade el rol de administrador | Se leen las respuestas completas de la API y se añaden o cambian campos en las peticiones |
| Acceso y sesiones débiles (A07, API2) | La contraseña se puede probar sin límite, el enlace para restablecerla vale una semana, cerrar sesión no la termina | Se revisan límites de intentos, restablecimiento de contraseña, segundo factor y duración de la sesión |
| Inyección de comandos (A03) | Alguien escribe un trozo de consulta a la base de datos en el buscador y la web devuelve la lista de todos los clientes | Se insertan caracteres especiales y comandos en todos los campos y parámetros, a mano y con herramientas |
| Fallos de lógica de negocio (A04, API6) | Un código promocional se aplica diez veces, un bot compra todas las entradas en un minuto | Se prueban pasos fuera de orden, repeticiones, cantidades negativas y peticiones masivas |
| Configuración insegura (A05, API8) | Un panel de administración abierto, una página de error que muestra código, una copia de pruebas de la API olvidada | Se revisan direcciones de servicio, páginas de error, cabeceras y ajustes de HTTPS |
| Componentes desactualizados y versiones olvidadas de la API (A06, API9) | Un plugin viejo de WordPress con una vulnerabilidad conocida; una versión antigua de la API sigue funcionando sin los controles nuevos | Se comparan las versiones con bases de vulnerabilidades conocidas y se buscan direcciones de API antiguas o sin documentar |
Un escáner automático no encontrará la mayoría de las filas de esta tabla: para él, una página con el pedido de otro cliente parece una página normal. En qué se diferencia el escaneo de una revisión manual lo explico en pentest o escaneo de vulnerabilidades. OWASP describe el método de revisión manual en su guía de pruebas. [4]
Qué necesitas aportar
El test va más rápido y encuentra más cuando todo esto está listo antes de empezar:
- El alcance. Una lista de dominios, direcciones de API y entornos: producción o preproducción (una copia del sistema para pruebas).
- Cuentas de prueba. Dos por cada rol: cliente, gestor, administrador, socio. Sin una segunda cuenta del mismo rol no se puede comprobar el acceso a datos ajenos.
- Documentación de la API. Una descripción OpenAPI o Swagger (la lista de todas las peticiones en un formato estándar) o una colección de Postman. Sin ella, parte de la API queda sin ver.
- Datos de prueba. Tarjetas de prueba de tu proveedor de pagos, registros sin datos personales reales.
- El segundo factor de acceso. Cómo recibirá el tester los códigos de las cuentas de prueba.
- Autorización por escrito y reglas de trabajo. Fechas, horas, acciones prohibidas y un contacto que pueda parar el test.
- Una decisión sobre el WAF (un filtro de peticiones web). Si añadir las direcciones de los testers como excepción, para revisar la web y no el filtro.
La lista completa de preparación, con una tabla de quién hace qué, está en cómo prepararse para un pentest.
Qué queda fuera del test
Los límites importan tanto como el alcance. Normalmente quedan fuera:
- los ataques de denegación de servicio (DoS, saturar un servicio con peticiones);
- los servicios de terceros: proveedor de pagos, CRM en la nube, servicio de email, que no se pueden probar sin permiso de su dueño;
- el phishing a empleados y el acceso físico a la oficina, que tienen formatos propios;
- la app móvil, la red interna y la configuración de la nube, si no se añaden al alcance aparte;
- una revisión completa del código fuente, si no se acordó.
El test muestra el estado del sistema en la fecha de la prueba y dentro de los límites acordados. No garantiza que no queden fallos ni sustituye al desarrollo seguro. El NCSC aconseja ver un pentest como una comprobación de que tus procesos para encontrar y cerrar vulnerabilidades funcionan, no como la forma principal de encontrarlas. [5]
Qué recibes
- Un resumen breve para la dirección: qué se encontró, cómo amenaza al negocio, qué hacer primero.
- Cada hallazgo por separado: dónde está, cómo reproducirlo paso a paso, evidencia, impacto, gravedad y cómo corregirlo. La gravedad se suele valorar con CVSS (una escala de gravedad de 0 a 10). [6]
- Una lista de lo que se probó y lo que no, para que nadie dé por seguro lo que no se revisó.
- Un aviso inmediato de cualquier cosa crítica, sin esperar al informe.
- Un retest (una segunda comprobación tras las correcciones), si forma parte del alcance acordado. Acuérdalo antes de empezar.
NIST describe estas etapas, de la planificación al informe, en su guía técnica de pruebas de seguridad. [7]
Cómo elegir proveedor
Haz tres preguntas. ¿Cuánto tiempo trabaja una persona a mano y qué revisa exactamente con cada rol? ¿Puedes ver un informe de ejemplo anonimizado? ¿El retest está incluido en el precio? Si la respuesta es solo el nombre de un escáner, no es un test de aplicación web. Tienes más preguntas y señales de alarma en cómo elegir una empresa de pentesting.
Checklist antes de un test de web y API
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Me recomiendas una empresa en Ucrania que revise la seguridad de una web y una API?
Busca un proveedor que pruebe a mano con cada rol, trabaje solo con autorización por escrito, enseñe un informe de ejemplo y haga retest. Yo hago exactamente este tipo de test, tienes los detalles en la página de pentest.
¿Cuánto dura un test de web y API?
Depende del número de roles, páginas y peticiones de la API. Para una aplicación web pequeña suele ser desde una semana, para varios sistemas más. El plazo y el precio se fijan antes de empezar, una vez acordado el alcance.
¿Basta con un escáner automático?
No, si tienes área de clientes o API. Un escáner encuentra versiones desactualizadas y ajustes inseguros, pero no ve que un cliente pueda abrir los datos de otro. El escaneo regular es útil entre tests, no en lugar de ellos.
¿Es seguro probar una web en producción?
Sí, si las reglas lo tienen en cuenta: pruebas cuidadosas, horas acordadas, una copia de seguridad reciente y una persona de guardia. Los escenarios más agresivos es mejor dejarlos para preproducción.
¿Qué es OWASP Top 10 y sigue siendo útil?
Es una lista de los riesgos más importantes para aplicaciones web de la comunidad sin ánimo de lucro OWASP. La edición de 2021 se sigue usando mucho, en 2025 salió una actualizada, y para APIs hay una lista aparte de 2023. [1] [2] [3]
Referencias
- OWASP Top 10:2021 top10.owasp.org
- OWASP Top 10 API Security Risks 2023 api-security.owasp.org
- OWASP Top 10:2025 top10.owasp.org
- OWASP Web Security Testing Guide: Introduction wstg.owasp.org
- NCSC: Penetration testing ncsc.gov.uk
- FIRST: Common Vulnerability Scoring System first.org
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
