Codificación Segura y Herramientas
La Mentalidad del Secure Coding
A lo largo del curso hemos visto vulnerabilidad por vulnerabilidad. Esta última lección reúne las defensas en un conjunto coherente de prácticas y herramientas. El secure coding no es una lista de trucos, sino una mentalidad: asumir que toda entrada es potencialmente maliciosa, que toda confianza debe justificarse y que la seguridad es una propiedad que se diseña, no que se añade al final.
Esta mentalidad se concreta en un puñado de principios que se repiten en casi todas las defensas que hemos estudiado: validar la entrada, codificar la salida, denegar por defecto, aplicar mínimo privilegio, defensa en profundidad y fallar de forma segura. Si internalizas estos principios, podrás razonar sobre vulnerabilidades que aún no conoces, no solo sobre las del OWASP Top 10 actual. La seguridad cambia, pero los principios fundamentales se mantienen.
Validación de Entrada y Codificación de Salida
Las dos defensas más transversales merecen una mirada conjunta. La validación de entrada consiste en comprobar que los datos que entran a la aplicación cumplen lo esperado: tipo, formato, longitud y rango. La validación más robusta usa listas de permitidos (definir qué es válido y rechazar todo lo demás) en lugar de listas de denegados (intentar enumerar lo malo, que siempre deja huecos). La validación debe ocurrir en el servidor, recordando que la validación del cliente es solo cosmética.
La codificación de salida es la otra cara: tratar los datos correctamente cuando salen de la aplicación hacia un intérprete, ya sea el navegador, una base de datos o un shell. Es clave entender que validación y codificación resuelven problemas distintos y se complementan: la validación rechaza datos con formato incorrecto, mientras que la codificación neutraliza los datos peligrosos en el contexto donde se usan. La inyección SQL se previene con parametrización (una forma de separación de código y datos en la salida hacia la base de datos), y el XSS con codificación contextual en la salida hacia el HTML.
Burp Suite y OWASP ZAP
Para encontrar vulnerabilidades necesitas herramientas que te dejen ver y manipular el tráfico. Burp Suite es el proxy de interceptación estándar de la industria para pruebas de seguridad web. Se sitúa entre el navegador y el servidor y te permite inspeccionar cada request y response, modificarlas al vuelo, repetir peticiones con variaciones (Repeater), automatizar ataques sobre parámetros (Intruder) y mapear toda la superficie de la aplicación. Su versión profesional incluye además un escáner automatizado.
OWASP ZAP (Zed Attack Proxy) es la alternativa libre y de código abierto, mantenida por la fundación OWASP. Ofrece funcionalidad similar de proxy, spider para descubrir contenido y escaneo activo y pasivo de vulnerabilidades. Es excelente tanto para aprender como para integrarse en pipelines automatizados. Ambas herramientas son fundamentales para el testing manual dirigido, especialmente para vulnerabilidades de lógica como el control de acceso roto y las IDOR, que los escáneres automáticos difícilmente detectan por sí solos.
SAST, DAST y Análisis Automatizado
El análisis automatizado de seguridad se divide en dos grandes enfoques complementarios. El SAST (Static Application Security Testing) analiza el código fuente sin ejecutarlo, buscando patrones inseguros como concatenación de SQL, uso de funciones peligrosas o secretos incrustados. Su ventaja es que se ejecuta temprano, incluso antes de desplegar, y señala la línea exacta del problema; su limitación es que genera falsos positivos y no ve fallos que dependen del entorno de ejecución.
El DAST (Dynamic Application Security Testing) prueba la aplicación en ejecución, enviándole peticiones como lo haría un atacante y observando las respuestas; OWASP ZAP y el escáner de Burp son herramientas DAST. Ve la aplicación tal como funciona realmente, pero no señala la línea de código y puede no cubrir todos los caminos. Existe además el SCA para dependencias, que vimos en la lección anterior. Lo ideal es combinar los tres: SAST y SCA integrados en el pipeline de CI/CD para retroalimentación temprana, y DAST sobre entornos desplegados. Ninguna herramienta sustituye a las demás ni al criterio humano.
Integrando la Seguridad en el Ciclo de Vida
La seguridad eficaz no es una fase final ni una auditoría puntual, sino una práctica continua integrada en todo el ciclo de vida del desarrollo, lo que se conoce como DevSecOps o "shift left": desplazar la seguridad hacia las etapas tempranas, donde corregir es más barato. En la práctica, esto significa formar a los desarrolladores, modelar amenazas durante el diseño, integrar SAST/SCA en cada commit, ejecutar DAST en pruebas y realizar revisiones de código con foco en seguridad.
Apóyate en recursos de referencia: el OWASP Top 10 como mapa de riesgos prioritarios, las guías de OWASP (ASVS, cheat sheets, WSTG) como detalle práctico, y el catálogo CWE para clasificar debilidades. Complementa las herramientas automatizadas con pruebas de penetración manuales periódicas y, cuando el alcance lo justifique, programas de divulgación responsable o bug bounty. La meta no es alcanzar una seguridad perfecta (que no existe) sino elevar continuamente el costo para el atacante mientras reduces tu superficie y tu tiempo de respuesta. Con los fundamentos de este curso, tienes el marco para construir aplicaciones web defendibles.