Sus secretos permanecen locales: Esta herramienta se ejecuta completamente en su navegador. No se realizan solicitudes de red — verificable mediante la pestaña Network de DevTools.
🔍

Pegue su archivo .env arriba

Detecta secretos, valida formato y genera .env.example

¿Qué verifica el Inspector .ENV?

El Inspector .ENV analiza su archivo de variables de entorno en busca de tres categorías de problemas: riesgo de exposición de secretos, problemas de formato y completitud. Analiza cada línea, clasifica las variables por sensibilidad y le ayuda a generar un archivo de plantilla seguro para su equipo.

Detección de patrones de secretos

El inspector marca las variables cuyos nombres coinciden con patrones comunes de credenciales sensibles. Las variables se clasifican como secretos cuando su clave contiene alguno de estos patrones:

  • Credenciales de API: API_KEY, API_SECRET, API_TOKEN, ACCESS_KEY, ACCESS_TOKEN
  • Autenticación: PASSWORD, PASSWD, PWD, AUTH, BEARER, OAUTH, SESSION_SECRET
  • Criptografía: PRIVATE_KEY, SECRET, HMAC, SALT, SIGNING_KEY, ENCRYPTION_KEY
  • Base de datos: DATABASE_URL, DB_URL, MONGO_URI, POSTGRES_URL, MYSQL_URL, CONNECTION_STRING, DSN
  • Infraestructura: WEBHOOK_SECRET, CERTIFICATE, CREDENTIAL, REDIS_PASSWORD

Problemas comunes de formato .env

  • Falta el signo igual: Cada variable debe seguir el patrón KEY=VALUE. Las líneas sin = son inválidas.
  • Nombres de clave inválidos: Las claves solo deben contener letras mayúsculas, números y guiones bajos. Las claves que comienzan con números o contienen espacios son inválidas en la mayoría de los entornos.
  • Valores sin comillas con espacios: Los valores que contienen espacios deben estar entre comillas: APP_NAME="Mi Aplicación"
  • Comentarios en línea: Algunos parsers no soportan comentarios en línea (PORT=3000 # puerto web). Coloque los comentarios en su propia línea.
  • Espacios finales: Los espacios en blanco al final de los valores pueden causar errores sutiles, especialmente con contraseñas y tokens.

Mejores prácticas de seguridad para .env

  • Siempre agregue .env a .gitignore: Ejecute echo ".env" >> .gitignore antes de su primer commit. Una vez que un secreto está en el historial de git, debe considerarse comprometido — la rotación es la única solución.
  • Haga commit de .env.example en su lugar: Documente qué variables se necesitan sin exponer valores reales. Los nuevos miembros del equipo copian este archivo y completan con sus propios secretos.
  • Use credenciales diferentes por entorno: Producción, staging y desarrollo deben tener API keys y credenciales de base de datos separadas. Nunca reutilice secretos de producción en desarrollo.
  • Rote secretos regularmente: Trate los secretos como contraseñas — rótelos periódicamente e inmediatamente cuando alguien con acceso deje el equipo.
  • Use un gestor de secretos en producción: Para cargas de trabajo en producción, prefiera soluciones dedicadas de gestión de secretos como AWS Secrets Manager, HashiCorp Vault o Doppler sobre archivos .env en disco.
  • Nunca registre variables de entorno en logs: Evite imprimir process.env en los logs, especialmente en producción. Configure filtrado de logs para redactar patrones sensibles.

Preguntas frecuentes sobre archivos .env

¿Es seguro pegar mi archivo .env en esta herramienta?

Sí — esta herramienta se ejecuta completamente en su navegador. No se transmiten datos a ningún servidor. Puede verificarlo abriendo DevTools de su navegador → pestaña Network mientras usa la herramienta. No verá solicitudes salientes. El análisis ocurre localmente en JavaScript y desaparece cuando cierra la pestaña.

¿Qué es un archivo .env y cómo funciona?

Un archivo .env (dotenv) es un archivo de texto plano que almacena variables de entorno para su aplicación. Las variables siguen el formato KEY=VALUE, una por línea. Librerías como dotenv (Node.js), python-decouple (Python) o godotenv (Go) cargan estos archivos al inicio, haciendo que las variables estén disponibles como variables de entorno en su proceso. Esto separa la configuración del código — la misma base de código se ejecuta en desarrollo, staging y producción con diferentes archivos .env.

¿Cuál es la diferencia entre .env, .env.local y .env.production?

Muchos frameworks (Next.js, Vite, Create React App) soportan múltiples variantes de archivos .env con diferentes prioridades de carga. .env es el archivo predeterminado que se carga en todos los entornos. .env.local sobrescribe .env y es ignorado por git. .env.production y .env.development son específicos del entorno. .env.local siempre tiene prioridad sobre los archivos específicos del entorno. Consulte la documentación de su framework para el orden exacto de carga.

Mi archivo .env fue subido accidentalmente a Git — ¿qué debo hacer?

Rote inmediatamente todas las credenciales expuestas — deben considerarse comprometidas porque el historial de git es permanente incluso después de la eliminación. Elimine el archivo con git rm --cached .env, agregue .env a .gitignore, y haga force-push para sobrescribir el historial con git filter-branch o BFG Repo Cleaner. Si el repositorio es público o ha sido clonado, asuma que todos los secretos están comprometidos independientemente de la reescritura del historial.

Herramientas relacionadas para desarrolladores