Archivos de configuración: JSON, YAML y variables .env

JSON (JavaScript Object Notation) utiliza llaves { }, corchetes [ ] y comillas dobles estrictas para delimitar pares clave-valor ("db_port": 5432), siendo el formato preferido para transferir datos por APIs web. YAML (YAML Ain't Markup Language) elimina las llaves y basa toda su jerarquía en la sangría de espacios (identación), siendo el formato dominante para herramientas de infraestructura (Kubernetes, GitHub Actions, Docker Compose). En YAML, un tabulador accidental invalida el archivo por completo.

Siguiendo la metodología de las 'Doce Capas' (Twelve-Factor App), la configuración que varía entre entornos (desarrollo, pruebas, producción) se inyecta mediante Variables de Entorno del sistema operativo. En los servidores locales, estas variables se agrupan en un archivo de texto simple llamado .env con formato CLAVE=VALOR (por ejemplo: DB_PASSWORD=secreto_seguro_2026). El código de la aplicación lee estas variables en memoria sin almacenar contraseñas en sus repositorios.

El mayor riesgo de un archivo .env en un servidor compartido de Linux es que conserve los permisos por defecto 644 (-rw-r--r--). Esto significa que cualquier usuario local del sistema (un becario, una cuenta de mantenimiento o un servicio web secundario comprometido) puede leer el archivo y robar las contraseñas de producción. El administrador debe blindarlo inmediatamente con: chmod 600 .env (lectura y escritura exclusiva para el propietario) y chown appuser:appgroup .env.

Cuando una aplicación lee un archivo de configuración, utiliza un intérprete (parser). En lenguajes como Python (PyYAML) o Ruby, si se utiliza la función insegura yaml.load(data) en lugar de yaml.safe_load(data), el archivo YAML puede contener etiquetas especiales (!!python/object/apply:os.system) que fuerzan al intérprete a instanciar objetos y ejecutar comandos del sistema operativo en el servidor mientras lee el archivo. La regla de oro es procesar siempre los datos con funciones de análisis seguro.