Archivos expuestos en tu web: .env, .git, copias de seguridad y logs

Qué archivos se quedan a la vista

Cómo comprobar tu web

Escribe en el navegador tu dominio seguido de cada ruta: https://tu-web.com/.env, https://tu-web.com/.git/config, https://tu-web.com/wp-content/debug.log o https://tu-web.com/var/logs/. La respuesta correcta es un error 403 (prohibido) o 404 (no encontrado). Si se descarga un archivo o ves su contenido, está expuesto.

Con curl ves solo el código de respuesta, sin descargar nada:

for p in .env .git/config wp-config.php.bak wp-content/debug.log var/logs/ backup.zip; do
  printf "%-28s %s\n" "$p" "$(curl -s -o /dev/null -w "%{http_code}" "https://tu-web.com/$p")"
done

Cuidado con los falsos negativos: algunas webs responden 200 con una página normal («no encontrado» con diseño) para cualquier dirección. Si te sale 200, abre la ruta en el navegador y mira qué devuelve. Revisa también la carpeta pública con el gestor de archivos del hosting: busca .zip, .sql, .tar.gz, .bak y carpetas con nombres como backup, old o copia.

El análisis gratuito prueba estas rutas y otras frecuentes (copias de configuración, volcados de base de datos, .git, .env, registros de WordPress y PrestaShop, listados de carpetas) y te dice cuáles están abiertas.

Cómo arreglarlo

1. Borra o saca de la carpeta pública lo que no debe estar

Las copias de seguridad no se guardan en public_html ni en ninguna carpeta que se sirva por web: van fuera del servidor o, como mínimo, en una carpeta por encima de la raíz pública. Los phpinfo.php y los archivos .bak de pruebas, fuera. Si despliegas con Git, la carpeta .git no debería estar en el servidor; si tiene que estar, bloquéala.

2. Apaga lo que genera registros públicos

En WordPress, el modo de depuración no se usa en una web en producción. En wp-config.php, WP_DEBUG y WP_DEBUG_LOG deben estar en false. Si necesitas el registro un tiempo, WP_DEBUG_LOG admite una ruta fuera de la carpeta pública en lugar de true. En PrestaShop, revisa que el modo depuración esté desactivado (Parámetros avanzados → Rendimiento) y que var/logs/ no se sirva por web.

3. Bloquéalos en el servidor

Aunque borres lo de hoy, alguien puede volver a dejar una copia mañana. Una regla en el servidor lo evita. En Apache (y LiteSpeed), en el .htaccess de la raíz:

# Sin listados de carpetas
Options -Indexes

# Archivos ocultos (.env, .git, .htpasswd...) excepto .well-known
RewriteEngine On
RewriteRule "(^|/)\.(?!well-known/)" - [F]

# Copias, volcados y registros
<FilesMatch "\.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$">
  Require all denied
</FilesMatch>

En Nginx, dentro del bloque server:

autoindex off;

location ~ /\.(?!well-known) {
  deny all;
}

location ~* \.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$ {
  deny all;
}

# PrestaShop: registros y caché
location ~ ^/var/ {
  deny all;
}

Las reglas de .htaccess solo funcionan en Apache y LiteSpeed. Si tu servidor es Nginx, que es habitual en algunos hostings y en servidores propios, hay que ponerlas en su configuración: pídeselo a tu proveedor si no tienes acceso.

Si ya estaba expuesto

Borrar el archivo cierra la puerta, pero no sabes si alguien lo descargó antes. Trátalo como una filtración:

1. Cambia todo lo que contenía: contraseña de la base de datos (y actualízala en la configuración de la web), claves de API, de pago y de correo. En WordPress, regenera también las claves de seguridad de wp-config.php.
2. Mira los registros de acceso buscando esa ruta con respuesta 200: te dice si alguien la descargó y cuándo (grep "/.env" access.log | grep " 200 ").
3. Si era una copia de la base de datos con datos de clientes, puede ser una brecha de datos personales con 72 horas para notificarla a la AEPD. Lo explico en brecha de datos en tu tienda online.
4. Revisa si la web está comprometida: con las contraseñas de la base de datos o del panel, alguien pudo entrar. Las señales, en cómo saber si tu web está hackeada.

Si prefieres que lo haga yo

El análisis gratuito te dice en unos minutos qué archivos tienes abiertos. Si quieres que lo corrija, la puesta a punto (299 €, IVA no incluido) incluye el informe de seguridad y hasta tres horas para cerrar lo urgente: borrar o mover los archivos, poner las reglas del servidor y cambiar las claves afectadas. En el mantenimiento web, el análisis periódico avisa si vuelve a aparecer alguno.

Fuentes

• OWASP WSTG: revisar copias antiguas y archivos no referenciados (copias con otra extensión que se descargan como texto, archivos comprimidos y copias de editores).
• WordPress: depuración (WP_DEBUG_LOG guarda debug.log en la carpeta de contenido y no se recomienda usar la depuración en webs en producción).
• Apache: control de acceso y directiva Options (-Indexes).
• nginx: módulo de acceso y autoindex.
• RFC 8615: la carpeta /.well-known/ (rutas reservadas que deben seguir accesibles).
• AEPD: notificación de brechas de datos personales (plazo de 72 horas).