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

> Qué archivos de tu web puede descargar cualquiera (.env, .git, copias .sql, debug.log o var/logs de PrestaShop), cómo comprobarlo y cómo bloquearlos.

URL: https://webintacta.com/guias/archivos-expuestos-web
Última actualización: 2026-10-23

**En resumen:** Un archivo expuesto es uno que cualquiera puede descargar escribiendo su dirección, sin entrar en tu web: una copia .zip o .sql olvidada en la raíz, el .env o un wp-config.php.bak con las contraseñas, la carpeta .git o los registros de errores (debug.log de WordPress, var/logs de PrestaShop). Se comprueba pidiendo esas rutas en el navegador, que deben responder con un error 403 o 404. Se arregla borrándolos o bloqueándolos en el servidor y, si contenían contraseñas o claves, cambiándolas: borrar el archivo no deshace lo que ya se haya descargado.


Por Jose Soriano (WebIntacta) · publicada el 2026-10-23

De todo lo que encuentra el análisis externo, esto es lo que más sorprende a los dueños: no hace falta hackear una web para sacarle las contraseñas si alguien dejó una copia en la carpeta pública. Pasa con copias hechas a mano antes de una migración, con webs desplegadas con Git, con el modo de depuración olvidado o con plugins de copias que guardan el archivo donde no deben. Es fácil de comprobar y de arreglar, y aquí explico cómo.

## Qué archivos se quedan a la vista

| Archivo o carpeta | Qué contiene | Por qué importa |
| --- | --- | --- |
| `.env` | Contraseñas de la base de datos, claves de API, de pago y de correo | Con él se puede entrar en la base de datos o usar tus claves de Stripe o del correo |
| `wp-config.php.bak`, `.old`, `.save`, `~` | Copia de la configuración de WordPress | El `.php` original no se ve, pero la copia con otra extensión se descarga como texto, con las contraseñas |
| Copias `.zip`, `.tar.gz`, `.sql` | La web entera o la base de datos | Una copia de la base de datos de una tienda lleva los datos de los clientes |
| Carpeta `.git` | El código y su historial | El historial suele guardar contraseñas que alguien subió por error y luego «borró» |
| `wp-content/debug.log` | Errores de WordPress | Rutas del servidor, nombres de plugins y, a veces, datos de formularios |
| `var/logs/` (PrestaShop 1.7, 8 y 9) | Registros de la tienda | Errores con rutas internas y, a veces, datos de pedidos o de clientes |
| `phpinfo.php`, `info.php` | Toda la configuración de PHP | Versiones exactas y rutas: un mapa para buscar fallos conocidos |
| Listado de carpetas («Index of /») | La lista de archivos de una carpeta | Deja ver copias y archivos que nadie sabía que estaban ahí |

Los más habituales en webs de pymes y tiendas. El análisis gratuito comprueba estos y otros nombres frecuentes.

## 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](https://webintacta.com/analisis-seguridad-web-gratis) 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;
}
```

> Dos cuidados. La carpeta `.well-known` tiene que seguir abierta: la usan los certificados de Let's Encrypt y archivos como security.txt. Y si tu web ofrece descargas legítimas en `.zip` (un catálogo, productos descargables servidos directamente), ajusta la regla de extensiones para no bloquearlas. Prueba los cambios en una copia o justo después de aplicarlos.

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](https://webintacta.com/guias/brecha-datos-tienda-online-rgpd).
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](https://webintacta.com/guias/como-saber-si-mi-web-esta-hackeada).

## Si prefieres que lo haga yo

El [análisis gratuito](https://webintacta.com/analisis-seguridad-web-gratis) 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](https://webintacta.com/auditoria-seguridad-web) 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](https://webintacta.com/mantenimiento-web), el análisis periódico avisa si vuelve a aparecer alguno.

## Fuentes

- [OWASP WSTG: revisar copias antiguas y archivos no referenciados](https://wstg.owasp.org/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information) (copias con otra extensión que se descargan como texto, archivos comprimidos y copias de editores).
- [WordPress: depuración](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) (`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](https://httpd.apache.org/docs/2.4/howto/access.html) y [directiva Options](https://httpd.apache.org/docs/2.4/mod/core.html#options) (`-Indexes`).
- [nginx: módulo de acceso](https://nginx.org/en/docs/http/ngx_http_access_module.html) y [autoindex](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html).
- [RFC 8615: la carpeta /.well-known/](https://www.rfc-editor.org/rfc/rfc8615) (rutas reservadas que deben seguir accesibles).
- [AEPD: notificación de brechas de datos personales](https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion) (plazo de 72 horas).

## Preguntas frecuentes

### ¿Cómo sé si mi archivo .env está expuesto?

Abre en el navegador tu dominio seguido de /.env. Si ves texto con contraseñas o se descarga un archivo, está expuesto; lo correcto es un error 403 o 404. Si estaba abierto, además de bloquearlo cambia todas las claves que contenía.

### ¿Es peligroso tener la carpeta .git en el servidor?

Sí, si se puede descargar: permite reconstruir el código y su historial, que a menudo guarda contraseñas antiguas. Lo mejor es no desplegarla; si tiene que estar, bloquéala en el servidor.

### ¿Qué es el debug.log de WordPress y debo borrarlo?

Es el registro de errores que WordPress crea en wp-content cuando WP_DEBUG_LOG está activado. En una web en producción, desactiva la depuración, borra el archivo y bloquea los .log en el servidor.

### ¿Por qué se ven los logs de mi PrestaShop?

Porque la carpeta var/logs (o log/ en PrestaShop 1.6) depende de reglas del servidor para no ser pública. En Nginx, las reglas de .htaccess no se aplican y hay que bloquear la carpeta en la configuración del servidor.

### Tenía una copia de la base de datos a la vista, ¿qué hago?

Bórrala o muévela fuera de la carpeta pública, cambia la contraseña de la base de datos y mira en los registros si alguien la descargó. Si tenía datos de clientes, valora con tu asesor si hay que notificar una brecha a la AEPD en 72 horas.

## Sobre el autor

[Jose Soriano](https://webintacta.com/quien-soy): Desarrollador fullstack especializado en PrestaShop, WordPress y WooCommerce, con el curso y el examen oficiales de PrestaShop aprobados. Desarrolla tiendas online y módulos desde 2023 y es el fundador de WebIntacta, el servicio de seguridad web con el que analiza, limpia y mantiene él mismo webs de pymes y tiendas online, en remoto desde Ibi (Alicante). Datos de WebIntacta: https://webintacta.com/quien-soy#datos