Los archivos de entorno existen para mantener secretos como claves de API, contraseñas de bases de datos y tokens fuera de tu código fuente. Eso solo funciona si el archivo nunca llega al repositorio. Una clave filtrada en un repositorio público suele ser encontrada por escáneres automáticos en cuestión de minutos.
Cómo prevenirlo
- Agrega
.enva.gitignoreantes del primer commit. Incluye variantes como.env.localy.env.production. - Sube un archivo de ejemplo. Un
.env.examplecon los nombres de las variables y valores falsos documenta lo que necesita la app sin exponer nada. - Usa el almacén de secretos de tu plataforma en producción, como los ajustes de entorno de tu hosting o proveedor de CI, en vez de copiar un archivo a un servidor.
- Da credenciales distintas a cada entorno, para que una clave de desarrollo filtrada no pueda tocar producción.
Cuidado con los conversores
Cuando conviertes un archivo .env a JSON para inspeccionarlo, el contenido se muestra en pantalla. Esta herramienta funciona en tu navegador y no envía el texto a ninguna parte, pero aun así evita pegar secretos de producción en páginas que no controlas, y evita guardar el JSON de salida en un lugar que se suba al repositorio.
Si un secreto ya se subió
Borrar el archivo en un commit nuevo no basta, porque el commit anterior todavía lo contiene. Sigue este orden:
- Revoca o rota la credencial de inmediato. Este es el paso que realmente te protege.
- Elimínala del historial si hace falta, con una herramienta como
git filter-repo, y haz force-push, sabiendo que los clones y forks existentes pueden conservarla. - Revisa los registros por si hubo uso inesperado de la clave.
Hábitos útiles
- Ejecuta un escáner de secretos en CI o como hook previo al commit.
- Usa valores de corta duración cuando sea posible.
- Nunca imprimas variables en los registros.
Preguntas frecuentes
¿Un repositorio privado es seguro? Reduce la exposición, pero no es una caja fuerte. Los cambios de acceso, los forks y las copias de seguridad esparcen copias.