Seguridad de aplicaciones

Una autorización rota rara vez aparece porque faltara un escáner al final del proyecto. Suele nacer antes, cuando el diseño no definió quién podía actuar sobre cada recurso y la implementación repartió esa decisión entre el cliente, una API y varios servicios. La seguridad de aplicaciones reduce el riesgo introducido por el software, sus dependencias y el entorno que lo ejecuta desde los requisitos hasta la retirada.

Este ciclo importa porque cada fase puede prevenir una clase de fallo distinta. Un requisito aclara la propiedad de un dato. El diseño sitúa la frontera de confianza. La revisión detecta que una función omitió la comprobación. La telemetría posterior muestra intentos que las pruebas no anticiparon.

1. Preparar: asignar responsabilidades, formar al equipo y proteger entornos y artefactos.
2. Definir requisitos: identificar activos, límites de confianza, abuso esperado y nivel de verificación.
3. Diseñar: modelar amenazas y escoger controles que reduzcan el riesgo desde la arquitectura.
4. Construir: aplicar prácticas de codificación segura, revisar cambios y controlar dependencias.
5. Verificar: combinar revisión manual, pruebas automatizadas y validación de controles.
6. Operar y responder: observar la aplicación, gestionar vulnerabilidades y publicar correcciones.

El Secure Software Development Framework de NIST (SSDF) agrupa estas prácticas en preparar la organización, proteger el software, producir software bien protegido y responder a vulnerabilidades.

OWASP mantiene dos recursos que cumplen funciones distintas. OWASP Top 10 es un documento de concienciación que resume categorías de riesgo relevantes para aplicaciones web. OWASP ASVS es un estándar de requisitos verificables que permite definir qué controles debe cumplir una aplicación y con qué profundidad se revisan. Top 10 ayuda a reconocer áreas importantes, mientras que ASVS permite preparar una verificación con cobertura explícita.

La seguridad no termina en el código propio. También incluye:

• autenticación, sesiones y autorización
• validación de entradas y codificación de salidas
• lógica de negocio y flujos sensibles
• API, componentes cliente y servicios backend
• secretos, configuración, dependencias y pipeline de entrega
• bases de datos, servidores, cloud e identidades de servicio
• registros, errores y respuesta ante vulnerabilidades.

Por ejemplo, una API puede validar correctamente cada entrada y seguir exponiendo datos si confía en un identificador elegido por el cliente. La causa pertenece al modelo de autorización, no a la codificación del parámetro. A la inversa, una autorización correcta puede quedar anulada por una identidad de servicio con permisos globales o por un pipeline que publica secretos.

El análisis estático (SAST) revisa código o artefactos sin ejecutar la aplicación. El análisis dinámico (DAST) prueba la aplicación en funcionamiento. Estas técnicas, el análisis de dependencias, el fuzzing y otros escáneres cubren clases distintas de problemas. Ninguna demuestra por sí sola que una aplicación sea segura. La revisión manual sigue siendo necesaria para autorización, lógica de negocio, encadenamiento de fallos y condiciones que dependen del contexto.

Una prueba útil parte de requisitos y amenazas, documenta cobertura y distingue entre una señal automática y una vulnerabilidad reproducida con impacto.

También debe reconocer sus límites. Una revisión sin código no observa ciertas rutas internas. Un análisis estático desconoce parte de la configuración efectiva. Un entorno de pruebas puede omitir integraciones de producción. La conclusión indica qué se examinó, con qué identidad y qué incertidumbre permanece.

• ¿Por qué un pentest al final no sustituye un ciclo de desarrollo seguro?
• ¿Qué diferencia práctica existe entre OWASP Top 10 y OWASP ASVS?
• ¿Qué problemas importantes suelen requerir revisión manual?

• NIST Secure Software Development Framework
• NIST SP 800-218: Secure Software Development Framework
• OWASP Application Security Verification Standard
• OWASP Top 10