Escáner de .env Expuesto Gratis — Revisa 13 Rutas en Un Clic

El escáner env expuesto online de Data Hogo verifica si tu archivo .env — o cualquiera de 12 variantes comunes — es accesible públicamente en tu URL de producción. Pegas tu URL, das clic en verificar, y ves el código HTTP de cada ruta en segundos. Sin cuenta. Sin instalar nada.

Este post explica qué revisa la herramienta, cómo interpretar los resultados, y qué hacer si recibes un 200.

Verifica tu URL ahora — Escáner de .env gratis →

Qué revisa el escáner de .env expuesto

El escáner envía una petición HEAD a cada ruta y registra el código HTTP de respuesta. No lee el contenido del archivo — solo verifica si el servidor responde a la petición. Una petición HEAD es suficiente: si el servidor devuelve 200, el archivo también es accesible con un GET normal.

Estas son las 13 rutas que revisa:

Ruta	Por qué importa
`/.env`	El archivo principal de entorno. Contiene todo.
`/.env.local`	Común en proyectos Next.js y React. Frecuentemente tiene credenciales reales de desarrollo.
`/.env.production`	Variables específicas de producción. Suele ser el archivo más sensible del proyecto.
`/.env.backup`	Lo crean los devs antes de editar. Se queda en los servidores constantemente.
`/.env.development`	Configuración del entorno de desarrollo. Puede tener credenciales de base de datos de staging.
`/.env.staging`	Secretos específicos de staging. Con frecuencia comparte credenciales con producción.
`/.env.old`	Renombrado por devs que hacen limpieza manual. Se olvida con facilidad.
`/.env.bak`	Otro patrón común de backup. Misma historia.
`/.env.save`	Menos común pero real. Lo hemos visto en proyectos deployados.
`/.env.copy`	Se crea cuando los devs duplican archivos de entorno como referencia.
`/.env.orig`	Otra convención de backup. Pasa al parchear o hacer merge de configuraciones.
`/.env.test`	Config del entorno de pruebas. A veces contiene API keys reales de terceros.
`/.git/HEAD`	No es un archivo `.env`, pero si `/.git/` es accesible públicamente, un atacante puede reconstruir todo tu código fuente — incluyendo cada `.env` que hayas hecho commit.

El check de /.git/HEAD merece mención aparte. Un 200 ahí no significa que un archivo específico esté expuesto — significa que todo tu historial de Git puede ser reconstruible. Esa es una categoría diferente de problema, y es grave.

Por qué este riesgo es más común de lo que crees

La mayoría de los devs asumen que su .env está seguro. Están en Vercel, o nunca subieron el archivo manualmente, o alguien les habría dicho algo. Ahí está el problema.

Las causas reales son menos dramáticas de lo que suenan:

Defaults del servidor web. Nginx y Apache sirven archivos desde el document root a menos que se les indique explícitamente que no lo hagan. Si tu .env está ahí — porque se hizo commit en git y se deployó, porque un paso del build lo creó, o porque lo copiaste manualmente — el servidor lo servirá como texto plano. Sin configuración extra. Sin advertencia. Simplemente funciona, en silencio.

Archivos de backup de ediciones manuales. Alguien se conecta por SSH al servidor para hacer un cambio rápido. Antes de editar .env, corre cp .env .env.backup. Hace el cambio, reinicia el servicio y sigue con su día. El archivo backup se queda en el servidor indefinidamente. No llega al .gitignore porque nunca estuvo en git. Vive en el filesystem hasta que alguien lo note.

Proyectos generados con IA. Los riesgos de seguridad del vibe coding incluyen este patrón de forma consistente. Las herramientas de IA scaffoldean proyectos rápido, pero no siempre configuran los server blocks correctamente para deployments auto-hospedados. La config de Nginx se genera, el proyecto se deploya, y la regla de denegación para dotfiles nunca llega. El reporte State of Software Security de Veracode encontró que el 45% del código generado por IA tiene al menos una vulnerabilidad. La configuración incorrecta del servidor de archivos estáticos es una categoría recurrente.

El problema específico de .env.backup. Hemos escaneado URLs de proyectos que no tenían exposición en /.env y aun así encontramos /.env.backup devolviendo 200. El archivo principal estaba correctamente excluido. El backup no. Por eso importa revisar 13 rutas — revisar una no es suficiente.

Esto cae directamente bajo OWASP A02:2021 Fallos Criptográficos — guardar secretos de forma que queden accesibles para personas no autorizadas. Según la metodología Twelve-Factor App, la configuración pertenece al entorno, no a archivos deployados en un servidor. El patrón .env es una comodidad de desarrollo que se rompe cuando el archivo llega a un servidor público.

Qué significa cada resultado del escáner de .env

El escáner devuelve uno de tres códigos de estado para cada ruta. Así se interpretan:

200 OK — Expuesto

El archivo se está sirviendo. Cualquiera que conozca la URL puede descargarlo ahora mismo. Este es el estado que requiere acción inmediata.

Un 200 en /.env.backup tiene la misma severidad que un 200 en /.env. El contenido puede ser ligeramente diferente, pero los dos le dan a un atacante tus secretos.

403 Forbidden — Parcialmente mitigado, no seguro

El servidor sabe que el archivo existe pero está denegando el acceso en este momento. Esto no es un certificado de salud limpio.

Un 403 significa que el archivo está en el filesystem del servidor. Un cambio de configuración, un reinicio del servidor con una config ligeramente diferente, o un patrón de petición distinto podría exponerlo. La solución correcta es remover el archivo del servidor, no solo bloquearlo. Un 403 significa que todavía no te mordió. No significa que estés seguro.

404 Not Found — Seguro para esta ruta

El servidor no está sirviendo ese archivo en esta ruta. Para el vector de exposición por servidor web, estás limpio.

Nota el alcance: la herramienta solo revisa accesibilidad HTTP. Un 404 en las 13 rutas significa que tu servidor no está sirviendo estos archivos. No te dice si el archivo está en tu historial de git, si estuvo en un commit anterior que sigue accesible, o si hay secretos hardcodeados en otro lugar del código. Para esa revisión más amplia, escanea tu repo completo con Data Hogo.

Qué plataformas te protegen automáticamente

No todas las plataformas de deployment se comportan igual.

Plataforma	¿`.env` protegido?	Notas
Vercel	Sí	El runtime de Vercel excluye dotfiles del servidor. Si recibes un `200` en una URL de Vercel, el archivo está expuesto por git — no por el file server.
Railway	Sí	Las variables se inyectan en runtime desde el dashboard de Railway. Los archivos `.env` deployados no se sirven.
Render	Sí	Igual que Railway — las variables de entorno se inyectan, no se deploya el archivo.
Nginx (auto-hospedado)	No — requiere config	Nginx sirve todo lo que está en el document root por defecto. Necesitas un bloque explícito `location ~ /\.env { deny all; return 404; }`.
Apache (auto-hospedado)	No — requiere config	Apache requiere una directiva `FilesMatch` para bloquear el acceso a dotfiles. No viene configurado por defecto.
Docker + Nginx	Depende	Si `.env` se mete en la imagen con `COPY` y Nginx sirve desde ese directorio, queda expuesto. Usa `.dockerignore` para excluir `.env` del build.

Si estás en Vercel, Railway o Render, el riesgo por file server está en gran medida controlado. El riesgo que queda es la exposición por git — un .env hecho commit en tu repo que alguien con acceso podría leer directamente. Para eso, revisa cómo arreglar un .env expuesto en el historial de git.

Si tu deployment es auto-hospedado, los resultados del escáner son tu primera mirada real a si tu config del servidor está bloqueando estas rutas.

Qué hacer si el escáner encuentra una exposición

Si cualquier ruta devuelve 200, trátalo como un incidente activo. No un riesgo futuro. Un incidente activo.

Primero: para el sangrado. Bloquea o elimina el archivo expuesto de tu servidor. Para Nginx, el one-liner es location ~ /\.env { deny all; return 404; } agregado a tu server block, seguido de un reload. Para Apache, una directiva FilesMatch en tu config. Para Docker, verifica si el archivo fue metido en la imagen con COPY.

Segundo: rota cada secreto del archivo. No solo los que crees que importan. Una contraseña SMTP filtrada habilita phishing desde tu dominio. Un secreto JWT filtrado compromete cada sesión activa de tus usuarios. Cuando todo el archivo está expuesto, rotas todo. Para el checklist completo de rotación con URLs de revocación por proveedor, revisa nuestra guía sobre cómo arreglar un .env expuesto en producción.

Tercero: verifica el fix. Corre el escáner de nuevo después de hacer los cambios. Confirma que todas las rutas devuelven 404. Un 403 no es suficiente — el archivo sigue en el servidor.

Nota de alcance: Esta herramienta verifica si tus secretos están expuestos por HTTP ahora mismo. No escanea el historial de git, no busca credenciales hardcodeadas en el código, ni analiza tus políticas de RLS en Supabase. Para una revisión completa de seguridad, la herramienta gratuita de security score corre checks más amplios en tu URL deployada.

Preguntas frecuentes

¿Cómo verifico si mi archivo .env está accesible públicamente?

Pega tu URL en el Escáner de .env gratuito de Data Hogo. Revisa 13 rutas comunes y devuelve el código HTTP de cada una. Un 200 en cualquier ruta significa que ese archivo se está sirviendo públicamente.

¿Qué rutas revisan los atacantes para encontrar archivos .env?

No solo /.env — también .env.local, .env.production, .env.backup, .env.old, .env.bak, .env.staging y más. Los scanners automatizados prueban todas estas rutas. La herramienta de Data Hogo revisa las 13 en un solo paso.

¿Vercel protege mi archivo .env automáticamente?

Sí. Vercel, Railway y Render excluyen los archivos .env del servidor. Si estás en alguna de estas plataformas y el escáner devuelve 404 en todas las rutas, el riesgo por file server está controlado. Los deployments auto-hospedados en Nginx o Apache requieren reglas explícitas de denegación en la configuración del servidor.

¿Qué pasa si mi archivo .env está expuesto?

Cada secreto del archivo queda accesible para cualquiera que lo solicite. Contraseñas de base de datos, keys de Stripe, secretos JWT, credenciales de email — cada uno habilita un tipo diferente de ataque. Trata cualquier exposición de .env como un incidente activo: bloquea el archivo, rota cada secreto, verifica el fix. Para el proceso completo de respuesta, revisa cómo arreglar un .env expuesto en producción.

El escáner es gratis, tarda unos 10 segundos, y no requiere cuenta.

Revisa 13 rutas comunes de .env en tu URL ahora →

Si quieres ir más lejos — revisar tus headers de seguridad HTTP, ver tu security score general, o escanear tu codebase completo en busca de secretos hardcodeados — esas herramientas también son gratis: