Inspector .ENV — Herramienta Gratuita en Línea

¿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.

Seguridad de Variables de Entorno en el Desarrollo Moderno

Las variables de entorno son la forma estándar de configurar aplicaciones sin codificar valores sensibles. Sin embargo, gestionarlas incorrectamente es una de las causas más comunes de brechas de seguridad. Entender el manejo adecuado de archivos .env es crítico para todo equipo de desarrollo.

El Ciclo de Vida del Archivo .env: De Desarrollo a Producción

• Desarrollo: Usa un archivo .env con valores ficticios o locales. Commitea un archivo .env.example con todas las claves requeridas (pero sin valores reales) para que los nuevos miembros sepan qué configurar.
• CI/CD: Nunca almacenes secretos en tu repositorio. Usa la gestión de secretos de tu plataforma CI (GitHub Actions Secrets, GitLab CI Variables, o CircleCI Contexts) para inyectar variables de entorno en tiempo de build.
• Staging/Producción: Usa un gestor de secretos dedicado como AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, o Doppler. Estos proporcionan logs de auditoría, rotación automática y control de acceso.

Errores Comunes de Seguridad en .env

• Commitear .env a Git: Incluso si eliminas el archivo después, permanece en el historial de Git para siempre. Si esto sucede, rota inmediatamente todos los secretos expuestos y usa git filter-branch o BFG Repo-Cleaner para purgar el archivo del historial.
• Registrar Variables de Entorno: Nunca registres el entorno completo (console.log(process.env) o print(os.environ)). Esto vuelca todos los secretos en tu agregador de logs donde pueden ser accesibles para miembros no autorizados.
• Compartir vía Chat/Email: Nunca compartas secretos a través de Slack, email, o cualquier plataforma de mensajería. Usa la función de compartir de tu gestor de secretos, o herramientas de compartir secretos de un solo uso como Doppler o el compartir seguro de 1Password.
• Usar Secretos en Código Frontend: Las variables de entorno con prefijo NEXT_PUBLIC_, VITE_, o REACT_APP_ se incrustan en el bundle del lado del cliente y son visibles para cualquiera. Nunca pongas claves API, credenciales de base de datos, o secretos de autenticación en variables de entorno del frontend.

Detección y Prevención de Secretos

Automatiza la detección de secretos en tu flujo de trabajo de desarrollo para detectar fugas antes de que lleguen a producción. Herramientas como git-secrets, truffleHog, y detect-secrets pueden escanear commits en busca de patrones que coincidan con claves API, contraseñas y tokens. GitHub también proporciona escaneo de secretos integrado para repositorios públicos que te alerta cuando se detectan formatos de secretos conocidos en tu código.

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

• Contador de Tokens IA — cuente tokens para GPT-4o, Claude, Gemini
• Decodificador e Inspector JWT — decodifique JSON Web Tokens de forma segura en el navegador
• Generador de Docker Compose — genere docker-compose.yml con servicios
• Ver todas las herramientas gratuitas para desarrolladores