Cómo agregar encabezados de seguridad HTTP en WordPress

Publicado: 2023-05-18

WordPress es el sistema de administración de contenido (CMS) más popular del mundo y ejecuta más del 43% de todos los sitios web en Internet.Sin embargo, su uso generalizado lo convierte en un objetivo común para los piratas informáticos.

Los ataques de fuerza bruta, las vulnerabilidades de carga de archivos y los ataques de secuencias de comandos entre sitios contribuyen a la amenaza continua.

Afortunadamente, existen varias formas de hacer que su sitio web sea más seguro y menos propenso a los ataques. Y ahí es donde entran en escena los encabezados HTTP.

Al implementar encabezados de seguridad HTTP, puede restringir las acciones que los navegadores y servidores pueden realizar en su sitio web y agregar una capa adicional de seguridad. Estos encabezados hacen que sea mucho más difícil para los atacantes explotar las vulnerabilidades del lado del cliente.

En este artículo, discutiremos qué son los encabezados de seguridad HTTP y cómo puede implementarlos de manera efectiva en su sitio web.

¿Qué son exactamente los encabezados de seguridad HTTP?

Los encabezados de seguridad HTTP son un grupo de directivas utilizadas por las aplicaciones web para implementar defensas de seguridad en los navegadores web. Estos encabezados se intercambian entre el navegador web (el cliente) y el servidor para identificar los parámetros de seguridad de la comunicación HTTP. Este intercambio de información le dice al navegador cómo comportarse a lo largo de sus interacciones con su sitio y gobierna procesos como mostrar errores y administrar el caché.

Por supuesto, esta seguridad y eficiencia adicionales dependen en gran medida del navegador. Los navegadores web más antiguos no tendrán el mismo nivel de seguridad o compatibilidad y es posible que no procesen los encabezados de seguridad HTTP correctamente, en su totalidad o incluso en absoluto. Potencialmente, esto puede significar que, a pesar de todos sus esfuerzos para ayudar al visitante a mantenerse seguro, su navegador desactualizado aún lo deja vulnerable. Como desarrolladores de sitios web, debemos hacer todo lo posible, pero aceptar que, por parte del visitante, es su responsabilidad asegurarse de que esté utilizando un software actualizado en su computadora. Siempre que usen un navegador web moderno y actualizado, nuestro uso de encabezados de seguridad HTTP funcionará con el software de su navegador para mantenerlos seguros.

Sin embargo, nuestra principal preocupación es que los encabezados de seguridad HTTP eviten que su sitio web sufra ataques comunes, como secuencias de comandos entre sitios y ataques de fuerza bruta.Las formas más efectivas de implementar estos encabezados son establecerlos en su cuenta de alojamiento de WordPress (nivel de servidor) y usar un firewall de aplicaciones de sitio web a nivel de DNS como Cloudflare.

Pero debe recordar que si bien agregar encabezados de seguridad HTTP puede ayudar a mejorar la seguridad de su sitio, es solo un aspecto de la seguridad del sitio web y debe usarse junto con otras medidas de seguridad. Esto incluye mantener sus aplicaciones y complementos actualizados, cifrar sus datos confidenciales y hacer una copia de seguridad de los datos del sitio y los archivos de configuración.

Antes de analizar los diferentes métodos para agregar encabezados de seguridad, echemos un vistazo a cada encabezado en detalle y comprendamos por qué es importante.Si ya está familiarizado con los encabezados de seguridad, puede pasar a la siguiente sección.

Los tipos de encabezados de seguridad HTTP de WordPress

Hay varios encabezados de seguridad HTTP que se pueden usar con su sitio web de WordPress para mejorar la protección. Echemos un vistazo a algunos de los más importantes.

1. Encabezado de seguridad de protección X-XSS

Este encabezado de seguridad se usa para configurar secuencias de comandos entre sitios (XSS), una vulnerabilidad de seguridad que permite que terceros no autenticados ejecuten código en nombre de otro sitio web en el navegador.

Previene muchos ataques XSS en su sitio web al impedir que el sitio se muestre si se detecta un ataque. X-XSS emplea la opción más segura de no cargar el sitio por completo en lugar de intentar desinfectar la página reemplazando elementos potencialmente dañinos.

El encabezado puede tener uno de estos varios valores:

  • X-XSS-Protection: 0 Desactiva el filtrado XSS (no recomendado)
  • Protección X-XSS: 1 Habilita el filtrado XSS, que suele ser el predeterminado en la mayoría de los navegadores. Si se detecta un ataque XSS, el navegador eliminará las partes no seguras de la página (desinfección).
  • Protección X-XSS: 1; mode=block Habilita el filtrado XSS, pero en lugar de desinfectar la página, el navegador evitará la representación de la página (recomendado)
  • Protección X-XSS: 1; report=<reporting-uri> Habilita el filtrado XSS. El navegador desinfectará la página e informará de la infracción si se detecta un ataque de secuencias de comandos entre sitios.

2. Encabezado de seguridad de opciones de X-Frame

El encabezado de seguridad X-Frame-Options se puede usar para prevenir diferentes ataques de fuerza bruta y ataques DDOS , pero su uso más efectivo es contra el cross-jacking de iframes y el click-jacking en su sitio web de WordPress.Este encabezado le permite decidir si una página en su sitio web se puede incrustar o no usando elementos iframe en el navegador.

La opción X-Frame protege su sitio web del robo de clics al evitar que los iframes se llenen con su sitio. Tiene dos directivas diferentes entre las que puede elegir:DENY y SAMEORIGIN. Funciona con todos los navegadores web populares, como Chrome, Safari, Firefox y Opera.

 Opciones de X-Frame: DENEGAR
 Opciones de X-Frame: SAMEORIGIN

Cuando se especifica con DENY, el encabezado X-Frame-Options provocará un error si algún navegador intenta cargar la página dentro de un marco cuando se carga desde otros sitios. Los intentos de hacer esto también fallarán cuando se carguen en un iframe desde el sitio original. Por otro lado, si especificamos SAMEORIGIN , aún podemos usar la página dentro de un marco, siempre que el sitio que la incluye en un marco sea el mismo que sirve la página.

Este encabezado es especialmente importante para las páginas web que contienen información confidencial y las páginas que incorporan información, como pasarelas de pago y formularios.

3. Encabezado de Seguridad estricta de transporte HTTP (HSTS)

HTTP Strict-Transport-Security es un encabezado de respuesta de seguridad enviado desde un servidor web al navegador web de un usuario para informarle que solo se debe acceder al sitio mediante HTTP y nunca a través de HTTP sin cifrar.

Este encabezado proporciona un mecanismo para hacer cumplir el uso de HTTPS por parte del navegador , incluso si el usuario escribe "http://" en la barra de direcciones o sigue un enlace HTTP.También puede evitar que los usuarios ignoren los certificados SSL/TLS caducados o no válidos y otras advertencias del navegador. El valor HSTS se establece por navegador que visita el sitio web. No se establece por máquina.

El encabezado HSTS proporciona una opción para incluir cualquier subdominio: puede usar la directiva "includeSubDomains" para adoptar el mismo nivel de seguridad del dominio raíz. Esto significa que cualquier desarrollo local con el dominio (o subdominios) ya no será accesible a través de HTTP, ya que el navegador solo permitirá el tráfico HTTPS.

Por ejemplo, si tiene encabezados HSTS en example.com con la directiva "includeSubdomains " necesaria, no podrá acceder a los subdominios de example.com a través de conexiones no seguras una vez que haya visitado example.com. Por lo tanto, tenga cuidado si elige usar "includeSubdomains" , ya que podría tener implicaciones para sus otros dominios.

Una vez que un navegador recibe un encabezado HSTS de un sitio, recordará la política HSTS durante la duración especificada y actualizará automáticamente todas las solicitudes futuras al sitio a HTTPS. Esto ayuda a evitar ataques de intermediarios, escuchas ilegales y otras formas de manipulación al garantizar que toda la comunicación entre el navegador y el servidor esté encriptada.

La sintaxis de este encabezado es:

 # Sin directiva includeSubDomains
<IfModule mod_headers.c>
Encabezado establecido Strict-Transport-Security: “max-age=63072000;”
</IfModule>
# Con la directiva includeSubDomains
<IfModule mod_headers.c>
Encabezado establecido Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" 
</IfModule>

La directiva max-age=<expire-time> designa el tiempo (en segundos) que el navegador debe recordar que solo se puede acceder a un sitio mediante HTTPS. Por ejemplo, en el ejemplo anterior, la edad máxima se establece en dos años. Si ha elegido tener Servebolt CDN o dominios acelerados de Servbolt, automáticamente tendrá 1 año de duración de HSTS.

4. Encabezado de política de referencia

Este encabezado HTTP controla la cantidad de información de referencia enviada a través del encabezado de referencia que se debe incluir con las solicitudes. Limita la cantidad de información que se envía cuando un visitante del sitio hace clic en un enlace. Esto ayuda a evitar la fuga de información sensible a otros sitios web , como la URL de una página con información privada.

Puede tener varios valores. He aquí un resumen rápido:

  • no-referrer: En ningún caso se enviará la cabecera Referer.
  • No-referrer-when-downgrade: el encabezado de referencia no se enviará al navegar desde un sitio HTTPS a un sitio HTTP.
  • Origen: el encabezado de referencia solo incluirá el origen (esquema, host y puerto) de la página de referencia.
  • Origin-when-cross-origin: el encabezado de referencia incluirá la URL completa de la página de referencia cuando navegue entre páginas dentro del mismo origen y solo el origen cuando navegue a un origen diferente.
  • Origen estricto: el encabezado de referencia solo incluirá el origen de la página de referencia y no se enviará para solicitudes de origen cruzado.
  • Strict-origin-when-cross-origin: el encabezado de referencia incluirá el origen de la página de referencia y no se enviará para solicitudes de origen cruzado, excepto para orígenes del mismo sitio. Recomendamos usar esta configuración ya que conserva la utilidad del encabezado mientras mitiga el riesgo de fuga de datos.
  • Unsafe-url: el encabezado Referer enviará el origen, la ruta y la cadena de consulta al realizar cualquier solicitud, independientemente de la seguridad.

Para obtener una discusión detallada sobre el encabezado de la política de referencia, lea el artículo de Google web.dev sobre las mejores prácticas para la política de referencia .

5. Encabezado X-Content-Type-Options

El servidor envía el encabezado X-Content-Type-Options en una respuesta HTTP para indicar a los navegadores sobre los tipos MIME. El propósito de este encabezado es evitar que los navegadores interpreten los archivos como un tipo MIME diferente al especificado en el encabezado.

Este encabezado puede tener un solo valor de "nosniff". La sintaxis es la siguiente:

 Opciones de tipo de contenido X: nosniff

Es muy eficaz contra los ataques de confusión MIME: el uso de este encabezado de seguridad puede evitar que el navegador interprete los archivos de formas inesperadas que podrían generar vulnerabilidades de seguridad. Por ejemplo, si un atacante carga un archivo con una extensión .jpg pero que no contiene contenido porque en realidad es una secuencia de comandos, establecer el encabezado X-Content-Type-Options en "nosniff" no permitirá que el navegador ejecute la secuencia de comandos. protegiendo así a los usuarios de posibles infracciones.

6. Encabezado de la política de seguridad de contenido(CSP)

Content-Security-Policy es un encabezado de seguridad que se utiliza para especificar el origen del contenido y proporciona un mecanismo para que el contenido pueda cargarse y ejecutarse en un sitio web o una aplicación web. Al especificar un conjunto de políticas, este encabezado puede restringir los tipos de contenido que se permiten en una página web y mitigar varios tipos de amenazas de seguridad. Es una capa adicional de seguridad contra Cross-Site Scripting (XSS) y ataques de inyección de datos que se utilizan para delitos como el robo de datos, la desfiguración de sitios y la distribución de malware.

Además de controlar los tipos de recursos que se pueden cargar, el encabezado Content-Security-Policy también proporciona una forma de indicarle al navegador cómo debe manejar cualquier violación de las políticas especificadas en el encabezado. Por ejemplo, una política puede especificar que si un recurso infringe la política, el navegador debe publicar una advertencia o bloquear la carga del recurso.

El servidor debe configurarse para devolver el encabezado Content-Security-Policy para que las políticas funcionen. Puede usar el encabezado HTTP de CSP para especificar su política de esta manera:

 Política de seguridad de contenido: política

Esta política es una cadena que contiene las directivas de política que describen su Política de seguridad de contenido. Por ejemplo, puede agregar las siguientes líneas a su archivo .htaccess para implementar CSP.

 <IfModule mod_headers.c>
Conjunto de encabezado Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
</IfModule>

Si está aplicando CSP en un sitio web de WordPress, debe tener en cuenta que WordPress necesita 'unsafe-inline' y 'unsafe-eval' para funcionar correctamente. La configuración anterior es un buen punto de partida para la mayoría de los sitios web de WordPress. Sin embargo, existen riesgos asociados con el uso de la configuración anterior sin una comprensión clara de lo que significa cada sección. Aquí hay un desglose de cada directiva:

  • default-src : esta directiva establece la política predeterminada para todos los tipos de recursos a menos que sean anulados por otras directivas.En este caso, permite cargar recursos desde el mismo origen ('self'), así como desde fuentes HTTPS y desde scripts que usan 'unsafe-eval' o 'unsafe-inline'.
  • object-src : esta directiva restringe los tipos de objetos que se pueden incrustar en una página, como Flash o applets de Java.Aquí, permite que los objetos se carguen solo desde el mismo origen ('self').
  • font-src : esta directiva restringe las fuentes desde las que se pueden cargar las fuentes.Aquí, permite que las fuentes se carguen desde fuentes HTTPS, el esquema de URI de datos y desde el mismo origen ("auto") o desde fuentes HTTP de Google Fonts y Google User Content.
  • connect-src : esta directiva restringe las fuentes que se pueden usar para solicitudes de red, como solicitudes AJAX o WebSockets.Aquí, permite que las conexiones se realicen solo sobre HTTPS o WebSockets y desde el mismo origen ('self').
  • img-src : esta directiva restringe las fuentes desde las que se pueden cargar las imágenes.Aquí, permite que las imágenes se carguen desde fuentes HTTPS, el esquema de URI de datos y desde el mismo origen ("yo mismo") o desde fuentes HTTP de Gravatar.
  • worker-src : esta directiva restringe las fuentes desde las que se pueden cargar los trabajadores web.Aquí, permite que los trabajadores se carguen solo desde el esquema URI de blob, fuentes HTTPS y desde scripts que usan 'unsafe-eval' o 'unsafe-inline'.
  • media-src : esta directiva restringe las fuentes desde las que se pueden cargar recursos multimedia, como audio o video.Aquí, permite que los medios se carguen solo desde fuentes HTTPS, el esquema de URI de blob y desde el mismo origen ("uno mismo").
  • style-src : esta directiva restringe las fuentes desde las que se pueden cargar las hojas de estilo.Aquí, permite cargar estilos desde fuentes HTTPS y desde scripts que usan 'unsafe-eval' o 'unsafe-inline', así como desde el mismo origen ("self") y desde fuentes HTTP de Google Fonts.

Al usar el encabezado CSP con su instancia de WordPress, es importante tener en cuenta que laaplicación incorrecta de los encabezados CSP dañará el Panel de administración de WordPress porque ciertos complementos y servicios pueden depender de JavaScript de terceros.

Para solucionar esto, deberá agregar cada regla de seguridad a su archivo de encabezados manualmente. Una forma alternativa, pero menos segura, es deshabilitar el encabezado CSP en su panel de administración. Por ejemplo, esto es lo que hacemos en servebolt.com :

 Conjunto de encabezado X-Frame-Opciones SAMEORIGIN
Conjunto de encabezado Referrer-Policy origen estricto cuando origen cruzado
Conjunto de encabezado X-XSS-Protection "1; modo = bloque"
<Si "%{REQUEST_URI} !~ /wp-admin/">
# solo agregue encabezado si no es pantalla de administración
El encabezado siempre establece Content-Security-Policy "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' *.intercomcdn.com cdn.firstpromoter.com servebolt.containers .piwik.pro *.intercom.io cdn.getreplybox.com plataforma.twitter.com v0.wordpress.com cdn.jsdelivr.net servebolt.piwik.pro ;media-src 'self' *.intercomcdn.com datos: ;img -src 'self' 'unsafe-inline' *.intercom.io *.intercomcdn.com *.intercomassets.com data: raskesider.raskesider.no *.servebolt.com secure.gravatar.com servebolt.piwik.pro ; connect- src 'self' ws: nexus-websocket-a.intercom.io *.piwik.pro servebolt.piwik.pro *.intercom.io ;font-src 'self' *.intercomcdn.com data: ;frame-src 'self ' app.getreplybox.com plataforma.twitter.com player.vimeo.com wordpress.org www.youtube.com caniuse.bitsofco.de video.wordpress.com *.intercom.io; frame-ancestors 'self' *.servebolt. com;manifest-src 'self' ;"
</si>

Al aplicar CSP en su sitio, debe tener en cuenta que podría dañar su entorno de desarrollo si no está utilizando HTTPS. Si no está seguro de cómo generar una política para su sitio, debe usar una herramienta gráfica como ValidBot – CSP Wizard o Report URI: generador de CSP .

7. Encabezado de política de permisos

La política de permisos proporciona mecanismos para que los desarrolladores declaren explícitamente qué funcionalidad se puede y no se puede implementar en un sitio web .Gestiona el conjunto de permisos que requiere el sitio web. Este encabezado se usa para restringir las capacidades de un sitio web para evitar ciertos riesgos de seguridad y privacidad, como el abuso de las API de Javascript, el seguimiento de usuarios y la ejecución de código infectado.

La política de permisos permite que un servidor establezca si una característica se puede usar en un documento en particular. Utilizalistas de permitidos , una lista de orígenes que toma valores predefinidos específicos.El valor del encabezado Permission-Policy consta de una lista separada por comas de nombres de directivas y sus valores que describen los diversos permisos que requiere un sitio web.

La sintaxis general para el encabezado Permissions-Policy es:

 Permisos-Política: <directiva>=<lista permitida>

Por ejemplo, si necesitamos bloquear todos los accesos a la geolocalización, haríamos esto:

 Permisos-Política: geolocalización=()

Aquí, el símbolo () significa una lista blanca vacía. Para permitir el acceso a un subconjunto de orígenes, haríamos esto:

 <IfModule mod_headers.c>
El encabezado siempre establece Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), acelerómetro=( ), giroscopio=(), magnetómetro=(), cámara=(), micrófono=(), pantalla completa=(uno mismo)"
</IfModule>

Tomemos otro ejemplo. El siguiente valor de encabezado restringe un sitio web solo para ejecutar scripts si se sirven desde el mismo origen que el documento principal:

 Política de permisos: script-src 'self'

El encabezado Permissions-Policy se puede usar para reemplazar o complementar el encabezado tradicional Content-Security-Policy, que proporciona una funcionalidad similar pero con una sintaxis diferente y menos cobertura en términos de permisos.Este encabezado es actualmente una tecnología experimental que solo es compatible con Google Chrome y otros navegadores basados ​​en Chromium.Proporciona un mecanismo más potente y flexible para controlar los permisos y se espera que su adopción crezca en el futuro. Si desea probarlo usted mismo, puede utilizar el Generador de encabezados de políticas de permisos para generar políticas de permisos fácilmente.

Adición de encabezados de seguridad HTTP mediante el archivo .htaccess

La forma en que recomendamos agregar encabezados de seguridad HTTP es editando el archivo.htaccess directamente. Este es un archivo de configuración del servidor más utilizado por los servidores web Apache. Al editar este archivo, se asegura de que los encabezados de seguridad HTTP en WordPress estén configurados a nivel de servidor.

Necesitará acceso al archivo.htaccessde su sitio web para usar este método. Se puede acceder a él en servidores Apache utilizando un cliente FTP.Antes de realizar cualquier cambio, se recomienda encarecidamente que haga una copia de seguridad de su archivo .htaccessactual.

Primero, simplemente inicie sesión en su sitio usando un cliente FTP o la herramienta de administración de archivos en su panel de control de alojamiento. En la carpeta raíz de su sitio web, localice el archivo.htaccessy haga clic derecho en la opción 'Editar'. Esto abrirá el archivo con un editor de texto. Para agregar encabezados de seguridad HTTPS a su sitio, puede agregar el código correspondiente en la parte inferior del archivo .htaccess.

El siguiente código de ejemplo se puede utilizar como punto de partida.Establece los encabezados de seguridad HTTP más utilizados con la configuración recomendada.

 <IfModule mod_headers.c>
Encabezado establecido Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Conjunto de encabezado X-XSS-Protection "1; modo = bloque"
Conjunto de encabezado X-Content-Type-Options "nosniff"
Conjunto de encabezado X-Frame-Options DENY
Conjunto de encabezado Referrer-Policy "no-referrer-when-downgrade"
Conjunto de encabezado Content-Security-Policy "default-src https: 'unsafe-eval' 'unsafe-inline' 'self'; object-src 'self'; font-src https: data: 'self' http: fonts.googleapis. com themes.googleusercontent.com; connect-src https: wss: 'self'; img-src https: data: 'self' http: *.gravatar.com; worker-src blob: https: 'self' 'unsafe-inline ' 'unsafe-eval'; media-src https: blob: 'self'; style-src https: 'unsafe-eval' 'unsafe-inline' 'self' http: fonts.googleapis.com"
El encabezado siempre establece Permissions-Policy "geolocation=(self 'https://abc.example.com' 'https://pqr.example.com'), midi=(), sync-xhr=(), acelerómetro=( ), giroscopio=(), magnetómetro=(), cámara=(), micrófono=(), pantalla completa=(uno mismo)"
</IfModule>

Una vez que agregue la configuración anterior a su archivo .htaccess, los encabezados relevantes se aplicarán a todas las solicitudes web.

Puede verificar si los encabezados se están utilizando abriendo la pestaña "Red" en Chrome DevTools e inspeccionando los encabezados de respuesta de su solicitud.

Pestaña Red Chrome DevTools

Después de agregar el código, guarde los cambios y vuelva a visitar su sitio web para asegurarse de que funcionan como se esperaba. También debe tener cuidado al editar su archivo .htaccess porque los encabezados de código incorrectos o los errores tipográficos pueden desencadenar errores como el Error interno del servidor 500 .

Agregar encabezados de seguridad HTTP en WordPress usando una red de distribución de contenido (CDN)

Una red de entrega de contenido (CDN) es un grupo de servidores distribuidos geográficamente que proporcionan contenido de Internet en caché desde una ubicación de red más cercana a un usuario para mejorar el rendimiento web. Los CDN populares como Cloudflaretambién le permiten agregar encabezados HTTP a su sitio web.

Tomemos Cloudflare como ejemplo y veamos cómo podemos agregar encabezados HTTP usando un CDN. Cloudflare ofrece un firewall de sitio web gratuito rudimentario junto con el servicio CDN, pero las funciones de seguridad más avanzadas están bloqueadas detrás de un muro de pago.

Configurar Cloudflare en su sitio web de WordPress es bastante fácil. Puede registrarse manualmente en el sitio web de Cloudflare y seguir los pasos en la pantalla para habilitarlo. Una vez que Cloudflare se haya activado en su sitio web, diríjase a la página SSL/TLS en el tablero de su cuenta de Cloudflare.

Luego deberá cambiar a la pestaña 'Certificados de borde' y ubicar la sección Seguridad de transporte estricta de HTTP (HSTS), y hacer clic en la opción 'Habilitar HSTS'. Después de activar el botón 'Habilitar HSTS', aparecerá una ventana con instrucciones para ayudarlo a habilitar esta función en su sitio. Haga clic en el botón 'Siguiente' para continuar con el proceso y verá la opción de agregar encabezados de seguridad HTTP.

Desde aquí, puede habilitar HSTS en su sitio y también optar por aplicar HSTS a los subdominios que usan HTTPS. El uso de este método proporcionará a su sitio una protección básica mediante encabezados de seguridad HTTP, pero la desventaja es que Cloudflare no le permite agregar X-Frame-Options actualmente.

Vale la pena señalar que para servebolt.com y cualquier otro dominio dentro de Cloudflare, HSTS está habilitado de manera predeterminada.

Agregar encabezados de seguridad HTTP usando un complemento de WordPress

Un tercer método para agregar y configurar encabezados HTTP es usar un complemento. Aunque esta es una de las formas más fáciles de agregar encabezados de seguridad HTTP a su sitio web de WordPress, generalmente es un poco menos efectivo que configurar manualmente los encabezados.

Es posible que ya haya leído en otro lugar que muchos complementos de seguridad incluyen la opción de agregar encabezados de seguridad. Sin embargo, recomendamos no usar un complemento de seguridad. Lea nuestro artículo sobre los complementos de seguridad de WordPress para comprender por qué y cuáles son las preocupaciones al usarlos.

Esta sección le permitirá habilitar o deshabilitar varios encabezados y establecer diferentes parámetros para ellos. Los encabezados exactos que puede habilitar variarán según el complemento que elija, pero los comunes como X-XSS-Protection, X-Content-Type-Options, X-Frame-Options y Strict-Transport-Security están cubiertos por la mayoría de los complementos.

Cómo verificar los encabezados de seguridad HTTP en su sitio web

Después de agregar los encabezados de seguridad HTTP en su sitio web de WordPress, debe asegurarse de que estén configurados correctamente y funcionen como se espera. Puede utilizar una de las muchas herramientas gratuitas disponibles en Internet para realizar una prueba. Recomendamos usar encabezados de seguridad o SSL Labs , los cuales le brindan una manera fácil de probar su configuración y verificar que todos los encabezados de seguridad funcionen correctamente.

Estas herramientas evaluarán los encabezados de seguridad de su sitio web y le proporcionarán un informe detallado. También le informan qué encabezados de seguridad HTTP está enviando su sitio web y cuáles no. Luego, su sitio recibirá una calificación de A+ a F, junto con una explicación de cómo se determinó esa calificación.

Por ejemplo, al probar el sitio web de Vogue , descubrimos que le faltan muchos encabezados HTTP importantes, por lo que solo obtuvo una calificación de C.

Prueba SSL de Vogue

Y, como es de esperar al probar nuestro propio sitio web, obtiene una calificación A+.

Prueba SSL de Servebolt

Conclusión

No hay duda de que implementar encabezados HTTP es un paso esencial para proteger su sitio web. Después de agregar con éxito encabezados HTTP a su sitio web, aquí hay algunos pasos adicionales que también debe considerar:

  1. Prueba de vulnerabilidades : es importante probar su sitio en busca de vulnerabilidades de seguridad comunes como Cross-Site-scripting (CSS) y Cross-site-request-Forgery (CSRF).Para ello, puedes utilizar herramientas como OWASP ZAP y Burp Suite .
  2. Supervise los cambios : debe supervisar periódicamente los encabezados en busca de cambios inesperados, ya que esto suele indicar que ha habido intentos de aprovechar una vulnerabilidad.
  3. Actualice los encabezados : a medida que surgen nuevas amenazas, es importante mantenerse actualizado con las últimas prácticas de seguridad y actualizar sus encabezados en consecuencia.

¿Está interesado en el alojamiento administrado que es empíricamente más rápido?

Pruebe nuestro enfoque para el alojamiento de WordPress: comenzar es gratis y los beneficios incluyen:

  • Escalabilidad: en las pruebas de carga de trabajo de usuarios reales, Servebolt entregó tiempos de respuesta promedio de 65 ms, tiempos de respuesta 4,9 veces más rápidos que el segundo mejor.
  • Los tiempos de carga globales más rápidos: los tiempos de carga de página promedio de 1,26 segundos nos colocan en la parte superior de la lista de resultados globales de WebPageTest.
  • La velocidad informática más rápida: los servidores Servebolt brindan velocidades de base de datos nunca antes vistas, procesando 2,44 veces más consultas por segundo que el promedio y ejecutando PHP 2,6 veces más rápido que el segundo mejor.
  • Seguridad y tiempo de actividad perfectos: con un tiempo de actividad del 100 % en todos los monitores y una calificación A+ en nuestra implementación de SSL, puede estar seguro de que su sitio está en línea y seguro.

En resumen, si nos permite eliminar el alojamiento de su plato, hará que mejorar la seguridad, la velocidad y el rendimiento de su sitio sea más fácil. Regístrese en Servebolt para ponernos a prueba.