Cabeceras de seguridad en WordPress con LiteSpeed (2026)

En pocas palabras: Configurá seis cabeceras de seguridad —X-Frame-Options, Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy y Permissions-Policy— en el .htaccess de tu servidor LiteSpeed y bloqueás clickjacking, XSS y MIME sniffing sin plugins pagos: la tarea toma menos de 15 minutos.

Si tu WordPress corre sobre LiteSpeed, configurar cabeceras de seguridad HTTP toma menos de quince minutos y no necesita plugins pagos: seis cabeceras (X-Frame-Options, Content-Security-Policy, HSTS, X-Content-Type-Options, Referrer-Policy y Permissions-Policy) bloquean clickjacking, XSS y MIME sniffing directo desde el .htaccess.

Las cabeceras de seguridad HTTP son instrucciones que tu servidor envía al navegador junto con cada respuesta, antes de renderizar cualquier contenido. Le indican al navegador cómo comportarse con tu sitio: si puede mostrar la página dentro de un iframe, qué scripts puede ejecutar, si debe exigir HTTPS. En WordPress se configuran a nivel servidor (Apache, NGINX o LiteSpeed) o desde el propio CMS, y complementan tu plugin de seguridad, no lo reemplazan.

¿Qué son las cabeceras de seguridad HTTP y por qué protegen WordPress?

Protegen WordPress porque actúan donde tu plugin de seguridad no llega: en el navegador del visitante, después de que tu página ya salió del servidor. Tu plugin escanea archivos, limita logins, bloquea IPs. Todo eso pasa dentro de WordPress. Pero hay toda una familia de ataques que arranca cuando el navegador ya recibió tu HTML: si no le das instrucciones claras, el navegador hace lo que el atacante quiere.

Ponele que alguien arma una réplica de tu tienda con un iframe invisible encima del botón «Comprar». El usuario cree que está comprando en tu sitio, pero el clic va a parar a otra acción que el atacante eligió. Eso es clickjacking, y se evita con una sola línea de configuración. Cada cabecera tapa un agujero concreto:

• Clickjacking: cargan tu sitio dentro de un iframe invisible para robar clics. Lo frenan X-Frame-Options y frame-ancestors.
• XSS (Cross-Site Scripting): inyección de JavaScript malicioso que roba sesiones o credenciales. La mitigación principal es Content-Security-Policy.
• MIME sniffing: el navegador «adivina» el tipo de un archivo y termina ejecutando algo que era un texto inofensivo. X-Content-Type-Options: nosniff lo corta.
• Filtración de datos y downgrade: Referrer-Policy evita filtrar URLs internas (a veces con tokens incluidos) y HSTS impide que te bajen de HTTPS a HTTP.
• CSRF: acá la pieza clave es el atributo SameSite de las cookies, que también viaja en una cabecera. Las cabeceras de esta guía ayudan, pero SameSite hace el trabajo pesado.

¿Cuáles son las cabeceras imprescindibles para hardening de WordPress?

Son seis. Ni una más, ni una menos para cubrir los ataques comunes de un WordPress típico. Te puede servir nuestra cobertura de cuándo un solo firewall no alcanza.

• X-Frame-Options está marcada como obsoleta y aun así conviene mandarla. La referencia de X-Frame-Options en MDN indica que la alternativa moderna es frame-ancestors dentro de CSP, pero enviar ambas cubre navegadores que no implementan CSP completa.
• HSTS es la única capaz de dejarte afuera de tu propio sitio. Le estás diciendo al navegador «por un año, entrá solo por HTTPS». Si tu certificado vence o nunca tuviste SSL bien configurado, el visitante ve un error y no puede pasar ni queriendo. Primero SSL impecable, después HSTS. Y ojo con includeSubDomains: solo si todos tus subdominios tienen HTTPS.
• CSP es la más potente y la más traicionera. Una política mal armada rompe sliders, formularios y chats embebidos. Por eso tiene sección propia más abajo.

¿Cómo agregar cabeceras de seguridad en el .htaccess con LiteSpeed?

LiteSpeed Web Server lee el archivo .htaccess y soporta las directivas Header de mod_headers de Apache, así que configurar cabeceras de seguridad en LiteSpeed es idéntico a hacerlo en cualquier hosting Apache, como confirma la documentación oficial de LiteSpeed. No hace falta reiniciar nada ni pedirle favores al soporte.

• Hacé backup del .htaccess actual. Descargalo por FTP o desde el administrador de archivos del panel. Si algo falla, lo subís de vuelta y listo.
• Abrí el editor de archivos. El .htaccess vive en la raíz de tu instalación, al lado de wp-config.php. Suele estar oculto: activá «mostrar archivos ocultos» si no aparece.
• Pegá el bloque antes de «# BEGIN WordPress». Antes, no después: WordPress reescribe su bloque cuando cambiás los permalinks, y lo tuyo tiene que sobrevivir a eso.
• Guardá, purgá caché y probá. Recargá el sitio y verificá con DevTools o con securityheaders.com.

# Cabeceras de seguridad
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Ese «always» no es decoración: hace que la cabecera salga también en respuestas de error (404, 500), que es justo cuando algunos ataques aprovechan. Y esto aplica en cualquier hosting que corra LiteSpeed o Apache, que es la mayoría del mercado argentino; si tu sitio está en donweb.com, por ejemplo, el administrador de archivos del panel te deja editar el .htaccess sin abrir ni FTP.

¿Y si tu servidor es NGINX? Ahí no existe .htaccess: las cabeceras van en la configuración del bloque server y necesitás acceso root o un ticket al soporte. Otra razón para celebrar que LiteSpeed hable el idioma de Apache.

¿Cómo añadir cabeceras desde functions.php sin tocar el servidor?

El hook send_headers de WordPress te permite mandar cabeceras desde functions.php, útil cuando el hosting no te da acceso al .htaccess o cuando preferís mantener todo dentro del tema.

add_action('send_headers', 'agregar_cabeceras_seguridad');

function agregar_cabeceras_seguridad() {
 if (is_admin()) {
 return;
 }
 header('X-Frame-Options: SAMEORIGIN');
 header('X-Content-Type-Options: nosniff');
 header('Referrer-Policy: strict-origin-when-cross-origin');
}

• A favor: no tocás el servidor, funciona en cualquier hosting y sobrevive actualizaciones si lo ponés en un tema hijo o en un plugin de snippets.
• En contra: PHP procesa cada petición, así que pesa un poco más que la ruta .htaccess, y solo cubre respuestas generadas por WordPress: imágenes y CSS servidos directo quedan afuera.

Ojo con actualizar el tema padre: si pusiste el código ahí, se borra con la próxima actualización. Tema hijo o plugin de snippets, siempre.

¿Qué plugins gratuitos configuran cabeceras de seguridad en WordPress?

En el repositorio oficial hay varias opciones gratuitas con panel de control: Headers Security Advanced & HSTS WP, HTTP Headers y All In One WP Security & Firewall son los tres nombres que aparecen en todas las guías serias, incluida la de Patchstack. Instalás, activás, tildás cada cabecera desde el dashboard y guardamos. Sin tocar una línea de código.

La contracara: un plugin más que actualizar, y según cómo esté implementado, las cabeceras salen solo de páginas PHP. Para un blog chico zafa perfecto; para un sitio grande, prefiero la ruta del servidor.

¿Y LiteSpeed Cache? Acá va un matiz que pocas guías aclaran: ese plugin maneja cabeceras de caché (fijate en DevTools y vas a ver x-litespeed-cache y sus amigas), no un panel de security headers. Su papel en esta historia es otro: después de editar el .htaccess, botón de purgar caché, o vas a seguir viendo las cabeceras viejas media hora preguntándote por qué no cambió nada. En endurecer WordPress con Patchstack profundizamos sobre esto.

Plugin, código manual o CDN: ¿qué conviene para cabeceras de seguridad?

Las tres rutas llegan al mismo lugar. La diferencia está en dónde se aplica cada cabecera y cuánto control tenés.

Todas las opciones tienen camino gratis: el .htaccess y functions.php no cuestan nada, los plugins del repositorio son gratuitos y hasta algunos CDN permiten modificar cabeceras de respuesta en su plan free (Cloudflare lo hace con Transform Rules, por nombrar el caso más conocido). Pagar solo tiene sentido si querés que alguien más se ocupe.

¿Cómo verifico mis cabeceras y consigo A+ en SecurityHeaders.com?

securityheaders.com escanea tu sitio gratis en segundos y te da una nota de A+ a F, igual que un boletín escolar pero con menos drama. El flujo es simple:

• Escaneá tu dominio. Poné la URL, dale Scan y esperá unos segundos.
• Leé el reporte. Te lista cada cabecera que falta, con explicación de para qué sirve.
• Corregí y repetí. Aplicá los cambios, purgá caché y volvé a escanear hasta clavar la nota que buscás.

Sin salir del navegador también podés: apretás F12, vas a Network, recargás la página, hacés clic en el primer pedido (el documento HTML) y mirá Response Headers. Ahí están todas las cabeceras que tu servidor mandó, en vivo.

Para el A+ hace falta HSTS serio, con un max-age largo y la directiva preload si querés entrar al registro de HSTS Preload. Los criterios exactos los publica el propio servicio, así que tomá la nota como guía y no como dogma. Dos ayudas extra: HSTS Preload valida tu política de transporte estricto, y CSP Evaluator (herramienta de Google) revisa tu Content-Security-Policy antes de que la actives y rompas algo.

¿Cómo configurar Content-Security-Policy sin romper el sitio?

Todos conocemos la película: activás una CSP estricta un viernes a la tarde, guardás, recargás la home y de repente el slider no desliza, el formulario de contacto no envía, el widget de WhatsApp desapareció y el cliente te está llamando, porque cada plugin mete sus propios scripts inline y ninguno estaba en tu lista de permitidos. Sobre eso hablamos en implementar passkeys y doble factor.

Por eso existe Content-Security-Policy-Report-Only: le avisás al navegador que reporte violaciones en la consola sin bloquear nada. Vivís una o dos semanas leyendo la consola, anotás cada dominio que tu sitio realmente usa, y recién ahí activás la CSP en firme.

# Modo prueba: reporta sin bloquear
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"

# Modo firme, una vez validado
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; frame-ancestors 'self'"

Esa política de arranque acepta scripts y estilos inline (WordPress core y la mitad de los plugins los inyectan, es la cruda realidad) pero ya bloquea todo lo externo que no declaraste. De ahí en adelante vas cerrando: sacás unsafe-inline cuando identifiqués qué scripts podés mover a archivos, agregás dominios específicos por directiva. Las violaciones aparecen en la consola con formato claro: qué directiva falló, qué recurso fue bloqueado y en qué página. Con esa lista armás tu política real.

¿Las cabeceras de seguridad afectan la velocidad o el SEO de WordPress?

En la práctica, no. Hablamos de unos cientos de bytes extra por respuesta y de instrucciones que el navegador procesa igual que cualquier otra cabecera. No conozco caso documentado de caída de rendimiento atribuible a estas cabeceras.

Al SEO hasta le juega a favor: un sitio con HTTPS forzado por HSTS transmite confianza, y Google usa HTTPS como señal de ranking desde hace años, leve pero existe. Lo que sí te puede hundir el SEO es una CSP mal configurada que rompe el checkout o los embeds. De nuevo: Report-Only primero.

Velocidad intacta, SEO neutro o mejor. El riesgo está en configurar mal, no en configurar. Lo explicamos a fondo en asegurar la base de datos MySQL.

¿Con cabeceras de seguridad alcanza o necesito también un WAF?

No, no alcanza sola. Las cabeceras frenan ataques del lado del navegador, pero no parchean un plugin vulnerable, no detienen fuerza bruta en tu login y no limpian malware ya instalado.

La receta completa sigue siendo la de siempre: todo actualizado, un WAF (el de tu plugin de seguridad o uno a nivel DNS), backups automáticos y estas cabeceras como capa extra. Cada capa cubre lo que la anterior no ve.

Errores comunes al configurar cabeceras de seguridad (y cómo evitarlos)

Estos cinco tropiezos aparecen una y otra vez en los foros de soporte de WordPress. Todos tienen arreglo, y mejor todavía: todos tienen prevención.

• Activar HSTS sin SSL funcionando. Síntoma: el sitio queda inaccesible incluso para vos, porque el navegador se niega a bajar a HTTP. Arreglo: esperá a que expire el max-age (por eso arrancá con valores cortos tipo max-age=300 mientras probás) o entrá desde otro navegador. Prevención: SSL verificado primero, HSTS después.
• CSP estricta de un saque. Síntoma: sliders muertos, formularios que no envían, embeds rotos. Arreglo: volvé a Report-Only y reconstruí la política con lo que la consola te muestra. Prevención: siempre Report-Only una o dos semanas.
• No purgar la caché después de editar. Síntoma: cambiaste todo y el escáner sigue mostrando lo mismo. Spoiler: casi siempre es la caché. Arreglo: purgá LiteSpeed Cache (o el que uses) y volvé a escanear.
• Olvidar Permissions-Policy. Síntoma: avisos en la consola sobre permisos denegados. No es un agujero de seguridad, pero ensucia la consola y complica debuggear. Arreglo: una línea con camera=(), microphone=(), geolocation=() y silencio.
• Copiar una configuración «universal» de internet. Síntoma: media funcionalidad rota porque tu stack carga servicios que la config del tutorial no contemplaba. Arreglo: partí de la base mínima y agregá según lo que tu sitio realmente use.

Qué está confirmado y qué no

• Confirmado: LiteSpeed Web Server soporta directivas Header de Apache en .htaccess, según su documentación oficial.
• Confirmado: securityheaders.com ofrece análisis gratuito con notas de A+ a F.
• Confirmado: MDN documenta X-Frame-Options como reemplazada por frame-ancestors de CSP.
• Confirmado: los tres métodos de esta guía (.htaccess, functions.php, plugins del repositorio) son gratuitos.

• No hay configuración única: la CSP depende de qué scripts carga cada sitio, así que ninguna receta copiada sirve tal cual.
• Los criterios de puntaje los define securityheaders.com y puede ajustarlos; consultá siempre su propia documentación.
• No existen cifras públicas confiables sobre qué porcentaje de sitios WordPress usa estas cabeceras. Desconfiá de quien te tire un número.

Preguntas Frecuentes

¿Qué son las cabeceras de seguridad HTTP y por qué importan en WordPress?

Son instrucciones que el servidor adjunta a cada respuesta y que el navegador cumple antes de mostrar la página: con quién puede enmarcar tu sitio, qué scripts ejecutar, si exigir HTTPS. Importan porque cubren ataques como clickjacking, XSS y MIME sniffing, que ocurren en el navegador, donde tu plugin de seguridad no llega.

¿Se pueden configurar cabeceras de seguridad gratis o hace falta pagar algo?

Gratis, todas las rutas: el .htaccess y functions.php no cuestan nada, los plugins especializados del repositorio oficial son gratuitos y securityheaders.com verifica sin cargo. Solo pagarías por un WAF o CDN premium, que es otra capa distinta.

¿Cuál es la diferencia entre X-Frame-Options y Content-Security-Policy?

X-Frame-Options hace una sola cosa: decidir si tu sitio puede mostrarse dentro de un iframe. CSP es un framework completo con decenas de directivas que controlan scripts, estilos, fuentes, frames y conexiones. La directiva frame-ancestors de CSP reemplaza a X-Frame-Options, aunque conviene enviar ambas por compatibilidad.

¿Cómo verifico si mis cabeceras están correctamente configuradas?

Escaneá tu dominio en securityheaders.com y obtenés una nota de A+ a F con el detalle de lo que falta. También podés abrir DevTools (F12), ir a Network, recargar la página y revisar Response Headers del documento principal.

¿Las cabeceras de seguridad reemplazan a un plugin de seguridad o a un firewall?

No. Las cabeceras protegen la interacción del navegador con tu sitio; un WAF filtra tráfico malicioso antes de que llegue y un plugin de seguridad cubre login y malware. Son capas complementarias, y un hardening serio usa las tres.

Conclusión

El hardening HTTP dejó de ser territorio de sysadmins: con acceso al .htaccess y quince minutos, cualquier administrador de WordPress puede subir su nota de F a A en securityheaders.com. El orden importa: SSL primero, cabeceras básicas después, CSP al final y en modo Report-Only. Si tu sitio corre sobre LiteSpeed, el camino es aún más directo, porque el servidor entiende las mismas directivas de Apache que ves en todos los tutoriales. Probalo en un entorno de pruebas, medí el resultado con el escáner y recién ahí llevalo a producción. Tu yo del futuro, el que no tenga que explicarle un clickjacking a un cliente, te lo va a agradecer.

Fuentes

• LiteSpeed Technologies – Documentación oficial de security headers en LiteSpeed Web Server
• MDN Web Docs – Referencia técnica de X-Frame-Options
• Security Headers – Analizador gratuito de cabeceras HTTP
• Patchstack – Guía de security headers para WordPress
• Ayuda WordPress – Cabeceras de seguridad HTTP en WordPress