Generador .htaccess: seguridad & HSTS

¿Qué hace el generador .htaccess?

El generador es un editor para reglas de configuración Apache. Se elige entre 15 tipos de reglas (redirecciones, rewrites, cabeceras de seguridad, forzar HTTPS, Cache-Control, bloqueo IP, protección anti-hotlink, HTTP Basic Auth, bloqueo de ficheros sensibles y más), se ajusta cada regla campo por campo y se obtiene un .htaccess limpiamente estructurado, incluyendo guards <IfModule> por regla, salida dual opcional <IfVersion> para hostings compartidos antiguos, y exportación Cloudflare Pages para _headers y _redirects. Todo ocurre en el navegador. Sin subida, sin cuenta, sin banner de cookies.

Los cuatro presets cubren las configuraciones de stack más frecuentes:

• Cabeceras de seguridad modernas: starter CSP, HSTS preload-ready, Permissions-Policy, COOP, X-Content-Type-Options, Referrer-Policy.
• Rendimiento de sitio estático: Cache-Control + Expires para JS/CSS/imágenes/fuentes, compresión Deflate para MIME texto.
• Pipeline HSTS Preload, preparación completa para la submission de hstspreload.org.
• Hardening WordPress: bloquea wp-config.php, xmlrpc.php y los ficheros PHP directamente en wp-includes, además de .env, .git, copias del editor y ficheros de log. Al cargarlo aparece el aviso de que las líneas deben añadirse al .htaccess existente: subir la descarga tal cual borra el bloque de enlaces permanentes y cada entrada responde 404.

¿Qué tipos de reglas hay integrados?

Catorce tipos de reglas, agrupados por función:

• Routing: redirect (301/302/303/307/308), patrón rewrite, www ↔ non-www, forzar HTTPS, añadir o eliminar slash final.
• Header, bloque de cabeceras de seguridad con CSP, Permissions-Policy, HSTS, COOP, Referrer-Policy.
• Acceso, allowlist IP (sitio entero o solo zona admin), blocklist IP, HTTP Basic Auth con realm y ruta .htpasswd.
• Contenido: documentos de error personalizados (401/403/404/500), Directory Listing on/off, Cache-Control con max-age e immutable, compresión con lista de MIME types.
• Protección, hotlink protection con allowlist Referer.

Cada regla muestra bajo su cabecera los módulos Apache necesarios como insignia. Se ve de un vistazo si su hosting proporciona mod_rewrite, mod_headers, mod_deflate y compañía.

¿Cómo funciona el modo dual Apache 2.4 vs 2.2?

La mayoría de los hostings compartidos corren Apache 2.4 en 2026. Las directivas de acceso han cambiado, sin embargo, fundamentalmente entre 2.2 y 2.4: en vez de Order Allow,Deny más Allow from, la 2.4 usa la nueva directiva Require. Quien despliega en un hosting legacy activa el modo dual 2.4+2.2 del generador, emitirá entonces ambas variantes sintácticas envueltas en bloques <IfVersion>. Apache lee solo el bloque que corresponde, y no hay que mantener dos .htaccess separados.

El trade-off: <IfVersion> necesita mod_version, presente en la mayoría de los 2.4 pero no en todos los 2.2. El generador envuelve por eso adicionalmente los bloques duales en un guard <IfModule mod_version.c>.

¿Qué hace la lista de verificación HSTS Preload?

Al activar el flag HSTS en una regla de cabecera de seguridad, aparece sobre la lista de reglas una lista de verificación. Revisa las demás reglas y avisa de lo que el envío hstspreload.org rechazaría si no:

• ¿Falta una redirección HTTPS? → se avisa.
• ¿includeSubDomains está en la cabecera HSTS? → se comprueba.
• ¿preload está en la cabecera HSTS? → se comprueba.

Cuando todo está verde, el enlace abre directamente el formulario de envío de hstspreload.org. Así se evita el caso clásico del dominio rechazado porque el flujo de envío no se entendió.

¿Qué cabeceras de seguridad merecen realmente la pena?

Las Mozilla Web Security Guidelines y el OWASP Secure Headers Project listan las siguientes cabeceras como set obligatorio para aplicaciones web modernas. El generador las cubre todas:

• Strict-Transport-Security, fuerza HTTPS en navegadores durante el período siguiente (max-age 1 año por defecto, preload-ready). Obligatorio para todo sitio que en algún momento haya sido accesible vía HTTP.
• Content-Security-Policy: allowlist para scripts, estilos, imágenes, fuentes. Impide cross-site-scripting y mixed-content. Compleja de ajustar, de ahí el aviso del validator.
• Permissions-Policy: bloquea API de navegador (cámara, micrófono, geolocalización, Payment Request, sensores) que su sitio no necesita. Por defecto: todo desactivado.
• Cross-Origin-Opener-Policy, same-origin aísla la ventana contra manipulaciones window.opener y desbloquea SharedArrayBuffer (relevante para herramientas WebAssembly).
• Referrer-Policy, strict-origin-when-cross-origin envía el Referer completo solo al propio dominio, a terceros solo el origen. Equilibrio entre necesidad analítica y privacidad.
• X-Content-Type-Options, nosniff impide ataques MIME-sniffing sobre ficheros con Content-Type sin definir.

El generador envuelve las seis en un único bloque <IfModule mod_headers.c> y emite el bloque como unidad coherente. Quien no necesite una cabecera desactiva la casilla correspondiente o borra el valor en el campo de texto, la línea cae automáticamente de la salida.

¿Cómo funciona la exportación Cloudflare Pages?

Cloudflare Pages no lee .htaccess. La plataforma espera, en cambio, dos ficheros en la raíz web:

• _headers, patrón de ruta más cabeceras de respuesta HTTP. Formato: línea de ruta + líneas Clave: Valor indentadas.
• _redirects, ruta origen, ruta destino, código de estado por línea.

El generador emite ambos ficheros desde la misma lista de reglas. Cabeceras de seguridad y Cache-Control van a _headers, redirecciones de ruta concretas a _redirects. Basta con cambiar la pestaña de salida. Lo que apunta al nombre de host, es decir forzar HTTPS y canonical www, no se puede expresar en _redirects, porque el fichero solo compara rutas. La exportación escribe ahí un comentario con el motivo, en vez de una línea que Cloudflare descarta sin avisar.

Un problema frecuente queda así resuelto: quien migra de hosting compartido a una plataforma Edge debería, de otro modo, traducir manualmente su .htaccess en otros dos ficheros. El generador lo hace automáticamente, misma lista de reglas, tres formatos de salida.

¿Qué errores aparecen con más frecuencia?

Tres clásicos que asoman una y otra vez en los despliegues de producción de un nuevo .htaccess, y el generador intenta evitar cada uno:

1. 500 Internal Server Error tras la subida, es casi siempre una directiva sin módulo cargado. Clásico: Header set … en un hosting sin mod_headers. El generador envuelve por eso cada regla en un guard <IfModule>. Si aun así aparece un 500, compruebe primero el error.log de su hosting.
2. Bucle de redirección infinito al forzar HTTPS detrás de un proxy inverso, Cloudflare y CDN similares pasan la petición ya HTTPS-terminada; Apache ve sin embargo %{HTTPS} como off, porque la conexión Proxy → Origin es HTTP. Solución: en vez de %{HTTPS} compruebe %{HTTP:X-Forwarded-Proto}. El interruptor «Detrás de CDN o proxy inverso» de la regla HTTPS añade esa segunda condición.
3. CSP bloquea sus propios scripts inline, sucede cuando la CSP estándar se sirve sin 'unsafe-inline' y el sitio contiene aún scripts inline. Dos vías: sacar los scripts inline a ficheros separados (vía limpia, a largo plazo), o permitir explícitamente los inlines restantes vía lista de permitidos por nonce / hash. El evaluador CSP externo indica exactamente qué inlines la política bloquea actualmente.

Estos tres puntos débiles están enlazados en las respuestas FAQ; el generador mismo no puede impedirlos, pero los comunica honestamente.

¿Cómo se gestiona la privacidad?

Pure-client. El generador corre íntegramente en el navegador. Sin endpoint de servidor para validación de reglas, sin llamada de telemetría, sin cookie, sin cuenta. Al cerrar la pestaña, la lista de reglas desaparece, el generador no persiste nada. Quien necesite un histórico descarga el .htaccess tras cada edición y lo versiona en el repositorio, donde tiene su sitio de todas formas.

¿Qué se ha dejado fuera deliberadamente?

• Sin convertidor nginx, htaccess-a-nginx es una herramienta separada de la lista pendiente, porque las correspondencias de directivas son demasiado voluminosas para una pestaña inline.
• Sin generador .htpasswd inline, el generador de fichero de contraseñas es la herramienta hermana htpasswd-generator (próximamente). La regla HTTP Basic Auth remite en la salida al fichero necesario.
• Sin mega-lista anti-bots, la detección por User-Agent es en 2026 ampliamente ineficaz como protección y produce falsos positivos. Quien quiera bloquear bots usa un WAF a nivel Edge.
• Sin validación del lado del servidor, exigiría una ida y vuelta al servidor, rompería la promesa pure-client. Lo que sí se puede comprobar sin servidor, es decir sintaxis, dependencias de módulo, orden de reglas y cadenas de redirección, lo hace el comprobador de .htaccess.
• Sin editor de reglas mod_security, demasiado especializado para una herramienta generadora. Quien ajuste mod_security trabaja directamente con la configuración OWASP-CRS.

¿Dónde encuentro más detalles?

• Documentación Apache HTTP Server 2.4, referencia oficial de directivas
• .htaccess en Wikipedia: historia, funcionamiento, ejemplos
• hstspreload.org, lista de envío para dominios HSTS-Preload
• CSP Evaluator, validador externo para valores Content-Security-Policy
• Documentación Cloudflare Pages Headers, referencia de sintaxis _headers
• Documentación Cloudflare Pages Redirects, referencia de sintaxis _redirects