Restricción de acceso a archivos confidenciales mediante reglas en .htaccess

En hosting compartido el control sobre el servidor es limitado, por eso el archivo .htaccess es una herramienta crítica para proteger archivos confidenciales. En esta guía práctica verás reglas concretas, variantes para Apache 2.4 y 2.2, ejemplos para WordPress (.htaccess y wp-config.php), prevención de ejecución en uploads, pruebas y consideraciones SEO y operativas.

Por qué usar .htaccess en hosting compartido

En entornos compartidos no siempre puedes editar la configuración global de Apache o instalar módulos adicionales. .htaccess permite aplicar restricciones a nivel de directorio sin acceso root. Bien configurado, protege datos sensibles (credenciales, backups, archivos de config) y reduce la superficie de ataque.

Principios básicos de seguridad con .htaccess

• Bloquear acceso directo a archivos de configuración (.env, .ini, .sql, .bak).
• Denegar ejecución de código en carpetas de carga (uploads).
• Proteger archivos ocultos (.htaccess, .git, .env).
• Permitir acceso sólo a IPs o usuarios autorizados cuando sea necesario.
• Registrar cambios y probar en entorno de staging antes de producción.

Reglas prácticas y ejemplos

A continuación encontrarás snippets listos para usar. Antes de aplicarlos, haz copia del .htaccess actual y prueba en un subdominio o directorio de staging.

Bloquear archivos por extensión

Evita la exposición de archivos que no deberían servirse públicamente (backups, logs, configuraciones):

<FilesMatch "\.(env|ini|log|conf|sql|bak|old)$">
  Require all denied
</FilesMatch>

Nota: para Apache 2.2 usar Order allow,deny
Deny from all. Consulta la guía oficial de Apache sobre .htaccess para compatibilidad.

Proteger archivos específicos (wp-config.php, .env)

<Files wp-config.php>
  Require all denied
</Files>

<FilesMatch "^\.env$">
  Require all denied
</FilesMatch>

Esto impide que el servidor entregue esos archivos como texto. Es una línea de defensa esencial para WordPress y aplicaciones PHP.

Bloquear acceso a archivos ocultos y .htaccess

<FilesMatch "^\.(htaccess|htpasswd|git|env)">
  Require all denied
</FilesMatch>

Denegar ejecución de scripts en carpetas de uploads

Evitar que un atacante suba un archivo PHP y lo ejecute desde /wp-content/uploads o /uploads:

# Método 1: deshabilitar handlers para PHP (puede variar según proveedor)
<FilesMatch "\.(php|php5|phtml)$">
  Require all denied
</FilesMatch>

# Método 2: forzar descarga (si no requiere ejecución)
<FilesMatch "\.(php|phtml|phps)$">
  ForceType application/octet-stream
  Header set Content-Disposition attachment
</FilesMatch>

En algunos entornos compartidos no está permitido cambiar handlers; si recibes errores, consulta con el proveedor. Para mitigar riesgos adicionales, revisa la guía de OWASP sobre uploads seguros.

Restringir por IP o permitir sólo IPs internas

<RequireAny>
  Require ip 203.0.113.0/24
  Require ip 198.51.100.10
</RequireAny>

Útil para proteger interfaces administrativas o áreas de prueba. Evita dejar reglas IP que bloqueen bots de monitorización o integraciones externas.

Autenticación básica para directorios sensibles

Protege directorios con usuario/contraseña usando .htpasswd:

AuthType Basic
AuthName "Zona privada"
AuthUserFile /home/usuario/.htpasswd
Require valid-user

En hosting compartido suele ser la opción más viable para áreas de staging o administración sin acceso a otras capas de seguridad.

Uso de mod_rewrite para reglas avanzadas

mod_rewrite permite reglas condicionales. Ejemplo: bloquear acceso excepto desde una IP y permitir a Googlebot:

RewriteEngine On
# Denegar acceso a archivos .sql o .bak
RewriteRule \.(sql|bak)$ - [F,L]

# Permitir sólo a Googlebot y a una IP concreta para un archivo sensible
RewriteCond %{REQUEST_URI} /informes/privado\.pdf$
RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.10$
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|Googlebot-Mobile) [NC]
RewriteRule .* - [F]

Precaución: filtrar por user-agent no es seguro contra spoofing; úsalo sólo como capa adicional y no como única defensa.

Pruebas, validación y efectos secundarios

• Probar con herramientas: curl y navegador en modo incógnito para comprobar cabeceras y códigos HTTP.
• Logs: revisa error_log y access_log para confirmar bloqueos y evitar falsos positivos.
• Robots y SEO: no uses reglas que bloqueen el acceso de bots legítimos (Googlebot), salvo en staging. Bloquear recursos críticos puede afectar la indexación; revisa las Directrices de Google.
• Compatibilidad: en Apache 2.2 usa directivas Order/Deny; en 2.4 usa Require. Consulta la documentación de Apache mod_authz_core Require para detalles.

Buenas prácticas operativas

• Versiona tu .htaccess y documenta cambios.
• Aplica principio de mínima exposición: sólo lo estrictamente necesario.
• Combina .htaccess con otras capas: firewalls de aplicaciones (WAF), HTTPS obligatorio y políticas de backup cifradas.
• Revísalo después de actualizaciones de CMS o cambios en rutas y plugins.

Recursos y referencias

La implementación correcta depende de la versión de Apache y de las restricciones del proveedor de hosting. Para profundizar en sintaxis y directivas consulta la documentación oficial de Apache, las recomendaciones de seguridad para uploads de OWASP y la especificación de cabeceras HTTP como Content-Disposition en MDN: MDN Web Docs.

Checklist rápida antes de desplegar

• Hacer copia del .htaccess actual.
• Probar en staging con curl y navegador.
• Verificar logs y comportamiento de la app (403/500).
• Asegurar backups y notificar al equipo de operaciones.
• Documentar reglas y razones para auditoría futura.

Conclusión

En hosting compartido, .htaccess es la primera línea de defensa para restringir el acceso a archivos confidenciales. Con reglas sencillas (bloqueo por extensión, protección de archivos específicos, denegación de ejecución en uploads y control por IP o autenticación) puedes mitigar riesgos importantes. Aplica cambios gradual y metódicamente, prueba en entorno controlado y combina estas reglas con otras capas de seguridad como WAF, HTTPS y prácticas seguras de desarrollo. La seguridad efectiva es la suma de controles: .htaccess aporta flexibilidad y eficacia cuando se usa correctamente.