Una lista de requisitos de seguridad para aplicaciones web convierte la seguridad en parte del alcance contractual: cada requisito tiene un responsable, una comprobación con resultado de apto o no apto, las pruebas exigidas y un plazo de corrección. Incluya este anexo junto a la lista de funciones antes de que empiece el desarrollo.
El control de acceso defectuoso sigue ocupando el primer puesto del OWASP Top 10:2025. Un análisis automatizado puede pasar por alto la regla de negocio que decide si un cliente puede abrir la factura de otro.
Quien compra el software suele saber qué datos necesita proteger, pero el contrato puede describir las pantallas con mucho más detalle que las pruebas de seguridad. Esta guía ofrece un anexo listo para el contrato, basado en OWASP ASVS 5.0, e indica las pruebas necesarias para la aceptación. También asigna las obligaciones que continúan tras la entrega.
- Cite OWASP ASVS 5.0 con su versión y nivel. El OWASP Top 10 explica el riesgo, mientras que ASVS aporta requisitos que producen un resultado de apto o no apto.
- Asigne cuatro campos a cada requisito: responsable, prueba de aceptación, evidencias y plazo de corrección.
- Compruebe la autorización con dos usuarios o tenants. Un inicio de sesión correcto no demuestra nada sobre el acceso a los registros, exportaciones, archivos o acciones administrativas de otro cliente.
- Incluya las pruebas en la entrega. El comprador debe recibir la matriz de requisitos, los resultados de las pruebas, las excepciones conocidas, las notas de despliegue y la prueba de recuperación.
- Mantenga el mantenimiento dentro del alcance. Los parches de dependencias, la asistencia ante incidentes, la transferencia de credenciales y los tiempos de respuesta empiezan cuando la aplicación entra en producción.
Una promesa de seguridad necesita una prueba de aceptación
OWASP describe su Top 10 como un documento de concienciación y recomienda el Application Security Verification Standard para establecer requisitos verificables de seguridad de aplicaciones. ASVS 5.0 contiene unos 350 requisitos distribuidos en 17 capítulos, cada uno diseñado para producir una decisión de apto o no apto.
ASVS también sirve para contratar software a medida. El comprador puede indicar un nivel, seleccionar los requisitos pertinentes y pedir al proveedor que demuestre su cumplimiento con referencias versionadas como `v5.0.0-1.2.5`. Este lenguaje funciona en un contrato porque la referencia se mantiene aunque cambien el proveedor o la empresa que realiza las pruebas.
Un desarrollo de webvise realizado en seis semanas para un servicio inmobiliario alemán combinó un proceso financiero de admisión de 10 pasos, la generación automatizada de PDF y un panel de administración, con un objetivo de respuesta inferior a 24 horas. Ese flujo plantea preguntas de seguridad concretas: ¿quién puede leer una solicitud, cambiar su estado, generar el PDF, descargarlo y consultar el historial de auditoría? Una línea que diga `autenticación incluida` deja abiertas todas esas decisiones.
Si su aplicación contiene un flujo privado de este tipo, el servicio de aplicaciones a medida de webvise incluye autenticación, autorización, diseño de API, CI/CD, supervisión y pruebas de los flujos críticos acordados. El anexo de seguridad define qué riesgos deben cubrir esos entregables.
Elija un nivel ASVS antes del presupuesto
ASVS tiene tres niveles con una profundidad creciente. OWASP señala un producto en fase inicial con pocos datos sensibles como posible caso de Level 1, mientras que un banco en línea difícilmente podría justificar un nivel inferior a Level 3. El comprador y el proveedor eligen el nivel a partir de los datos, los usuarios, el impacto empresarial y los atacantes probables de la aplicación.
| Nivel ASVS | Adecuación práctica para el comprador | Instrucción contractual |
|---|---|---|
| Level 1 | Producto en fase inicial con pocos datos sensibles y un modelo de amenazas acotado | Aplicar todos los requisitos L1 pertinentes y documentar los capítulos excluidos |
| Level 2 | B2B SaaS, portales de clientes, facturación, registros privados o una interrupción empresarial importante | Aplicar los requisitos L2 pertinentes, identificar los flujos sensibles y exigir pruebas trazables |
| Level 3 | Banca, sanidad, administración crítica o sistemas en los que una brecha pueda causar daños graves | Acordar el alcance L3 con un especialista en seguridad y definir una verificación independiente |
La tabla sirve como guía de riesgos para el comprador, ya que OWASP deja la elección final del nivel en manos de cada organización. Adapte también los capítulos. Una aplicación sin OAuth, WebSockets, GraphQL o frontend de navegador puede excluir esas secciones, siempre que las exclusiones figuren en el anexo contractual.
Indique en el acuerdo la versión exacta de ASVS. `ASVS Level 2` puede cambiar tras una versión mayor, mientras que `OWASP ASVS v5.0.0, requisitos L2 seleccionados en el Apéndice A` ofrece a ambas partes un objetivo de prueba estable.
Copie el anexo de seguridad con 12 requisitos
Use el siguiente anexo como apéndice de seguridad de un briefing o alcance de trabajo. Cada fila necesita un responsable identificado, la prueba final, las evidencias entregadas al comprador y el plazo para corregir una prueba fallida.
| Área | Requisito contractual | Evidencias de aceptación |
|---|---|---|
| 1. Mapa de riesgos y datos | Enumerar los datos sensibles, actores, sistemas, límites de confianza, conservación y usos prohibidos | Nota aprobada sobre el flujo de datos y registro de riesgos |
| 2. Autenticación y sesiones | Definir las reglas de inicio de sesión, restablecimiento, cierre de sesión, caducidad de sesión, MFA y recuperación de cuentas | Pruebas automatizadas de los flujos y registro de configuración |
| 3. Autorización | Definir cada rol, recurso protegido, acción permitida y límite entre tenants | Matriz de acceso y pruebas horizontales, verticales y entre tenants |
| 4. Tratamiento de entradas y archivos | Validar en el servidor todas las entradas del cliente, API, webhook, consulta y carga de archivos | Pruebas de tipos no válidos, límites de tamaño, entradas malformadas y archivos inseguros |
| 5. Secretos y criptografía | Mantener los secretos fuera del código fuente y definir reglas de cifrado, rotación y acceso | Inventario de secretos, configuración de almacenamiento y procedimiento de rotación |
| 6. Dependencias y cadena de suministro | Registrar las dependencias directas y transitivas, analizarlas y fijar tiempos de respuesta para los parches | Lockfile, inventario de dependencias, informe de análisis y registro de excepciones |
| 7. Servicios externos | Definir la autenticación, los scopes, tiempos de espera, reintentos, validación y comportamiento ante fallos para cada integración | Pruebas de integración y lista de titulares de las credenciales |
| 8. Registros y alertas | Registrar los eventos de seguridad sin cargas útiles sensibles y dirigir las alertas que exigen intervención a un responsable identificado | Catálogo de eventos, configuración de conservación y prueba de activación de alertas |
| 9. Comportamiento ante errores | Definir un comportamiento seguro para solicitudes fallidas, escrituras parciales, servicios no disponibles y estados imprevistos | Pruebas de las rutas de fallo que demuestren la reversión o una finalización segura |
| 10. Copias de seguridad, restauración y eliminación | Fijar la frecuencia de las copias de seguridad, el objetivo de restauración, la conservación, la exportación y las reglas de eliminación verificada | Resultado de la prueba de restauración y prueba de eliminación |
| 11. Pipeline de compilación y publicación | Proteger las ramas, restringir el acceso a producción, analizar los cambios y registrar los despliegues | Configuración de CI/CD, lista de accesos e historial de versiones |
| 12. Entrega y corrección | Transferir el código fuente, la infraestructura, las credenciales, los problemas conocidos, los objetivos de respuesta y las obligaciones de mantenimiento | Lista de entrega firmada y tabla de corrección basada en la gravedad |
La fila sobre dependencias tiene consecuencias reales. El 14 de septiembre de 2025, el gusano Shai-Hulud entró en npm mediante cuentas de mantenedores comprometidas y scripts maliciosos de post-install. OWASP registra más de 500 versiones de paquetes afectadas antes de que npm interrumpiera el gusano.
Un proveedor no puede garantizar todos los paquetes para siempre. El contrato puede exigir un inventario en la entrega, comprobaciones automatizadas durante el desarrollo, excepciones por escrito y un plazo de respuesta definido para nuevos hallazgos críticos. Estos elementos asignan un responsable al riesgo del código de terceros y evitan que quede como una suposición invisible.
Añada este anexo a la sección técnica del briefing para una agencia web antes de solicitar un presupuesto. Así, el proveedor podrá calcular el coste de las pruebas exigidas e indicar los controles que requieren un especialista en seguridad independiente.
Reescriba cada línea como apto o no apto
ASVS limita sus requisitos a resultados que pueden verificarse. Aplique la misma regla al contrato: otra persona cualificada debe llegar al mismo resultado después de leer el criterio y ejecutar la prueba indicada.
| Requisito impreciso | Criterio de aceptación apto/no apto | Evidencia |
|---|---|---|
| Usar un inicio de sesión seguro | Las sesiones caducadas, revocadas o ausentes reciben 401; cinco intentos fallidos activan el control acordado | Resultados de las pruebas automatizadas de autenticación |
| Mantener la privacidad de los datos del cliente | El usuario B no puede leer, cambiar, eliminar ni exportar registros creados en el tenant del usuario A | Pruebas de solicitudes con dos tenants que devuelven 403 o 404 |
| Proteger las funciones de administración | Cada ruta de administración rechaza en el servidor las solicitudes anónimas y las de usuarios estándar | Matriz de roles y resultados de pruebas en cada ruta |
| Validar las cargas de archivos | El servidor rechaza tipos no permitidos, datos MIME incoherentes, archivos que superan el tamaño máximo y nombres de archivo inseguros | Conjunto de pruebas de carga e inspección de archivos almacenados |
| Supervisar los ataques | Una ráfaga de prueba con inicios de sesión fallidos crea una alerta para el responsable identificado dentro del plazo acordado | Registro con marca de tiempo del evento, la alerta y su recepción |
| Mantener seguras las dependencias | La entrega no contiene ningún hallazgo crítico sin resolver fuera del registro de excepciones firmado | Informe de dependencias fechado y excepciones aprobadas |
Next.js concreta este principio. Su guía de seguridad de datos, actualizada el 27 de febrero de 2026, indica que cada Server Action exportada crea un endpoint HTTP público y necesita las mismas comprobaciones de autorización que una API. Use una prueba automatizada de solicitudes como evidencia. Ocultar un botón solo demuestra el estado de la interfaz.
La autorización merece varias pruebas porque comprobar el inicio de sesión solo cubre la identidad. Repita las acciones protegidas como otro usuario con el mismo rol, un rol inferior, otro tenant, una sesión caducada y sin sesión. Aplique esa matriz a lecturas, escrituras, exportaciones, archivos, tareas en segundo plano y herramientas de administración.
Exija las evidencias antes de la aceptación
El OWASP Secure Software Contract Annex denomina paquete de certificación al conjunto final de evidencias. Según OWASP, en algunos proyectos pueden bastar una breve evaluación de riesgos, unas páginas de requisitos, una nota de diseño de seguridad, un plan de pruebas y sus resultados.
- Nota sobre riesgos y flujo de datos: actores, campos sensibles, sistemas, límites de confianza, conservación y la persona responsable que aprobó cada decisión.
- Matriz de requisitos versionada: identificadores seleccionados de ASVS 5.0, aplicabilidad, responsable, estado, referencia de la prueba y cualquier excepción.
- Matriz de autorización: actor, recurso, acción, resultado esperado y resultado de la prueba automatizada para los flujos protegidos.
- Registro de dependencias: inventario directo y transitivo, análisis fechado, hallazgos sin resolver y excepciones firmadas.
- Nota de despliegue: acceso a producción, ubicaciones de secretos, ajustes de seguridad, dominios, servicios externos y procedimiento de reversión.
- Prueba de recuperación: una prueba de restauración completada, con fecha, duración, resultado y cualquier carencia detectada.
- Prueba de supervisión: un evento de seguridad activado, la alerta que generó, la persona destinataria y la hora de recepción.
Los analizadores automatizados solo cubren una parte de este paquete. OWASP advierte que el Top 10 no puede representar la cobertura completa de una herramienta, pues el diseño inseguro, la autorización de negocio y la eficacia de las alertas requieren una revisión o verificación en vivo. Recurra a un especialista para las pruebas independientes cuando la aplicación gestione datos regulados, movimientos de dinero, historiales médicos o tareas administrativas de gran impacto.
La cláusula de aceptación debe indicar quién revisa el paquete y qué hallazgos bloquean la entrega. Una regla viable bloquea la aceptación si quedan hallazgos críticos o de gravedad alta sin resolver, mientras que una excepción firmada puede aplazar un hallazgo de menor gravedad con un responsable y una fecha límite. Un abogado cualificado debe revisar el texto final del contrato conforme a la jurisdicción aplicable.
Defina las obligaciones de seguridad tras la entrega
La entrega cierra la fase de desarrollo e inicia la fase de operación. Los nuevos hallazgos en dependencias, los certificados caducados, las credenciales filtradas, los cambios de personal, los patrones de abuso y las integraciones fallidas surgen según su propio calendario. El acuerdo debe asignar un responsable a cada caso.
| Condición posterior a la entrega | Decisión que debe registrarse |
|---|---|
| Canal de comunicación | Dónde se envían los informes de seguridad, quién los recibe y cómo se confirma su recepción |
| Gravedad y respuesta | Cómo se establece la gravedad y el objetivo de respuesta o corrección para cada categoría |
| Mantenimiento de dependencias | Quién revisa las alertas, aplica actualizaciones, comprueba la compatibilidad y despliega parches |
| Asistencia ante incidentes | Disponibilidad, tarifas, conservación de pruebas, comunicación y autoridad para tomar decisiones |
| Titularidad de credenciales | Qué cuentas pertenecen al comprador y cuándo se rotan las claves, los dominios y los tokens |
| Fin del servicio | Exportación del código fuente, transferencia de infraestructura, devolución de datos, eliminación verificada y retirada de accesos |
La titularidad del código fuente solo sirve cuando el comprador también puede ejecutar la aplicación. Exija el repositorio, la configuración de CI/CD, los ajustes de infraestructura, el inventario de entornos, el historial de migraciones de la base de datos, el acceso a la supervisión y una ruta de despliegue probada. webvise incluye la titularidad del código fuente, los flujos críticos documentados, CI/CD, la supervisión y la infraestructura en funcionamiento en sus entregas de aplicaciones a medida.
webvise puede convertir esta lista en un anexo de seguridad acotado para una nueva aplicación a medida, con el nivel ASVS pertinente, las evidencias y las condiciones de entrega vinculadas al desarrollo. Envíe a webvise el flujo de trabajo y los tipos de datos antes de cerrar el presupuesto.
Las prácticas de webvise están alineadas con las normas ISO 27001 e ISO 42001.