Introducción y contexto de Secure by Default
Introducción y contexto
Definición
“Secure-by-Default” significa que los productos son resistentes ante técnicas de explotación prevalentes sin necesidad de configuración adicional. El software debe iniciar en un estado seguro sin requerir configuración extensiva por parte del usuario, asegurando que las opciones por defecto sean siempre la opción más segura disponible.
Esta es la definición que usa el OWASP Developer Guide. La idea central es simple pero exigente: la seguridad no puede depender de que alguien recuerde activarla. Si un desarrollador clona el repositorio, corre docker compose up o despliega la infraestructura con Terraform sin tocar nada más, el resultado ya debería ser razonablemente seguro.
Por qué importa: los defaults inseguros como causa raíz
Un porcentaje enorme de incidentes de seguridad no vienen de una vulnerabilidad exótica de día cero, sino de un default que nadie cambió:
| Incidente típico | Default inseguro de origen |
|---|---|
| Bucket S3 con datos expuestos públicamente | ACL “público” por defecto en versiones antiguas, o política mal heredada |
| Panel de administración accesible desde internet | Binding a 0.0.0.0 en vez de 127.0.0.1, sin autenticación inicial |
| Base de datos comprometida por credenciales conocidas | Usuario/contraseña de instalación (admin/admin, root sin password) |
Exfiltración vía .git/ expuesto | Servidor web sirviendo el directorio del repositorio tal cual |
| Server-Side Request Forgery hacia metadata de la nube | Rol IAM de la instancia con permisos excesivos “por si acaso” |
| Endpoint interno de debug/documentación filtrando información | Swagger UI o /actuator habilitado en producción por defecto del framework |
En todos estos casos, el sistema funcionaba exactamente como fue configurado por defecto. El problema no fue un bug de código sino una decisión de diseño (o la ausencia de una).
Relación con Secure by Design y Secure by Deployment
Secure by Default no vive aislado. Es una de las tres facetas complementarias que promueven organismos como CISA, NSA y el propio OWASP:
flowchart LR
SD[Secure by Design] -->|decisiones de arquitectura| SBD[Secure by Default]
SBD -->|estado inicial seguro| SDep[Secure Deployment]
SDep -->|operación segura| SD- Secure by Design: las decisiones arquitectónicas eliminan clases enteras de vulnerabilidades (por ejemplo, usar consultas parametrizadas en vez de confiar en sanitización manual, o usar un framework que escapa HTML automáticamente).
- Secure by Default: dado ese diseño, la configuración inicial —sin que nadie la toque— ya es la más segura posible.
- Secure Deployment: el proceso de llevar el software a producción (pipelines, IaC, gestión de secretos) no reintroduce inseguridad que el diseño y los defaults ya habían resuelto.
Este tutorial se enfoca en la capa intermedia: qué defaults concretos revisar en la configuración del sistema, en la gestión de archivos y en la infraestructura cloud.
El Proactive Control C5 de OWASP
El checklist de Secure by Default del Developer Guide remite directamente al Proactive Control C5: Secure by Default Configurations del proyecto OWASP Top 10 Proactive Controls. Los Proactive Controls son una lista de 10 prácticas que los equipos de desarrollo deberían incluir en todo proyecto de software, en contraste con el OWASP Top 10 “normal”, que enumera los riesgos a evitar.
C5 resume la idea en tres frentes, que son exactamente las tres secciones en las que se organiza este tutorial:
- Configuración de sistema — mínimo privilegio, eliminación de funcionalidad innecesaria, control de cambios y exposición de metadata.
- Gestión de archivos — permisos, aislamiento de directorios de carga y control de acceso a recursos.
- Seguridad en la nube — acceso Just-In-Time, imágenes de contenedor confiables, Infrastructure as Code y Policy as Code.
También se referencia el Infrastructure as Code Security Cheat Sheet, porque en arquitecturas modernas la “configuración por defecto” ya no vive solo en un archivo .ini en el servidor: vive en el código Terraform, en los Helm charts, en los Dockerfiles y en las políticas de IAM versionadas junto al resto del código.
Cómo usar este checklist
El propio OWASP Developer Guide aclara que estas listas son sugerencias de punto de partida, no una certificación ni un estándar cerrado. La recomendación es:
- Tomar el checklist consolidado (capítulo 5 de este tutorial) como base.
- Adaptarlo al stack real del proyecto (no todos los ítems aplican igual a un monolito on-premise que a un sistema serverless multi-tenant).
- Incorporarlo a un checklist de “Definition of Done” o a la plantilla de Pull Request, para que se revise en cada cambio y no solo una vez al año.
En los próximos capítulos se desarrolla cada ítem del checklist original con ejemplos concretos de configuración, código y herramientas.