Algunos archivos de una aplicación web no deberían descargarse ni abrirse directamente desde el navegador. En un servidor Apache, .htaccess puede bloquear solicitudes HTTP hacia nombres o extensiones concretas. Es una protección complementaria: no sustituye permisos correctos, actualizaciones, contraseñas fuertes ni guardar secretos fuera de la raíz pública.
Antes de agregar reglas, identificá qué archivo querés proteger y confirmá que Apache procesa .htaccess en ese directorio. Una expresión demasiado amplia puede bloquear recursos legítimos, actualizaciones, formularios o integraciones.
Qué archivos conviene mantener fuera de public_html
La mejor defensa para un archivo que nunca debe ser público es no colocarlo dentro de la raíz web. Esto incluye:
- exportaciones de bases de datos;
- backups comprimidos del sitio;
- archivos con credenciales o claves privadas;
- copias antiguas de configuración;
- documentos internos que no se entregan desde la web.
Una regla de Apache puede reducir la exposición accidental, pero el archivo seguirá existiendo y podría ser accesible mediante SFTP, el Administrador de archivos, otra configuración del servidor o una aplicación vulnerable.
Antes de editar .htaccess
- Descargá una copia del archivo
.htaccessactual. - Confirmá la carpeta donde aplicarás la regla; puede afectar a sus subdirectorios.
- Anotá la URL exacta que usarás para probar el bloqueo.
- Si es posible, realizá primero el cambio en un entorno de prueba.
- Tené acceso al Administrador de archivos o SFTP para revertirlo si aparece un error 500.
En WordPress, colocá las reglas personalizadas fuera del bloque comprendido entre # BEGIN WordPress y # END WordPress. Guardar los enlaces permanentes puede regenerar ese bloque y eliminar cambios colocados dentro.
Bloquear un archivo concreto en Apache 2.4
Para impedir el acceso HTTP a un nombre exacto, utilizá:
<Files "archivo.conf">
Require all denied
</Files>Reemplazá archivo.conf por el nombre real. La directiva Require all denied corresponde al sistema de autorización de Apache 2.4. Después de guardar, solicitá la URL desde una ventana privada: debería devolver 403 Forbidden o una página equivalente de acceso denegado.
No uses un archivo sensible real para demostrar la regla en producción. Creá un archivo de prueba sin secretos, verificá el comportamiento y luego eliminá la prueba.
Bloquear extensiones de backup o exportación
Para proteger un conjunto controlado de extensiones se puede utilizar FilesMatch:
<FilesMatch "\.(bak|backup|old|sql)$">
Require all denied
</FilesMatch>La expresión busca nombres que terminen en esas extensiones. Revisá el sitio antes de aplicarla globalmente: una tienda, un área de descargas o una herramienta administrativa podría ofrecer legítimamente uno de esos formatos.
La coincidencia se realiza sobre nombres de archivo, no reemplaza una política de almacenamiento. Los backups deben guardarse fuera de public_html o en un destino remoto protegido.
Proteger archivos ocultos sin bloquear .well-known
Apache recomienda impedir el acceso a archivos cuyo nombre comienza con punto, pero suele ser necesario permitir .well-known para validaciones y servicios estandarizados. Un ejemplo documentado es:
<FilesMatch "^\.(?!well-known)">
Require all denied
</FilesMatch>Aplicá esta regla sólo después de revisar el funcionamiento del hosting. Bloquear indiscriminadamente .well-known puede interferir con validaciones de certificados u otros mecanismos.
Sobre wp-config.php y archivos de configuración
En una instalación normal, wp-config.php es procesado por PHP y no se entrega como texto. Aun así, proteger el nombre reduce el riesgo ante determinadas configuraciones erróneas. Más importante todavía es no dejar copias como wp-config.php.bak, wp-config.old o archivos comprimidos dentro de una carpeta pública.
No cambies permisos al azar. Un archivo demasiado permisivo aumenta el riesgo, pero uno excesivamente restrictivo puede impedir que la aplicación o el servidor lo lean. Usá los valores recomendados por tu plataforma y proveedor.
Cómo comprobar el resultado
- Abrí la URL bloqueada desde una sesión privada.
- Confirmá que la respuesta sea 403 y que el contenido no se muestre ni descargue.
- Probá inicio, acceso administrativo, formularios, imágenes, CSS y JavaScript.
- Si existe una tienda, verificá carrito, pago, webhooks y tareas automáticas.
- Revisá el registro de errores si aparece una respuesta 500 o un 403 inesperado.
Un 500 Internal Server Error inmediatamente después del cambio suele indicar sintaxis incorrecta o una directiva no permitida por la configuración AllowOverride. Restaurá la copia anterior y consultá al administrador del servidor.
Errores frecuentes
- Copiar sintaxis de Apache 2.2: tutoriales antiguos utilizan
Order,AllowyDeny. Para Apache 2.4 correspondeRequire. - Bloquear por extensión sin revisar: puede impedir descargas o funciones legítimas.
- Editar el bloque de WordPress: la aplicación puede sobrescribirlo.
- Confiar sólo en .htaccess: no protege frente a credenciales robadas, malware o accesos que no pasan por Apache.
- Dejar la copia del .htaccess en la carpeta pública: el backup también debe protegerse o retirarse.
Cuándo usar otras herramientas
Si querés proteger una carpeta completa con usuario y contraseña, utilizá la función de protección de directorios de cPanel. Si necesitás bloquear una dirección concreta, consultá cómo bloquear una IP desde .htaccess, teniendo en cuenta que las IP pueden cambiar y que un proxy puede alterar el origen visible.
Para restaurar las reglas normales de WordPress, revisá el archivo .htaccess predeterminado. Si encontraste archivos desconocidos o redirecciones, no te limites a bloquearlos: seguí el procedimiento para detectar y eliminar malware.
Resumen
<Files> sirve para un nombre concreto y <FilesMatch> para un patrón controlado. Probá cada cambio, mantené una vía de reversión y almacená secretos y backups fuera de la raíz pública. La regla correcta reduce exposición, pero la seguridad real depende de varias capas coordinadas.
