Cómo corregir las flags de seguridad de cookies en WordPress

Si InspectWP informa de cookies sin las flags Secure, HttpOnly o SameSite, tu sitio puede ser vulnerable al secuestro de sesión, al robo de cookies basado en XSS o a ataques de falsificación de petición entre sitios (CSRF). Estas tres flags son los atributos de seguridad de cookies más importantes y trabajan en conjunto para proteger los datos de sesión de tus usuarios. Por suerte, corregirlas en WordPress es sencillo una vez entiendes lo que hace cada flag y dónde aplicarla.

Entender las flags de seguridad de cookies y su propósito

Antes de aplicar las correcciones, conviene entender de qué protege cada flag:

• Flag Secure: garantiza que la cookie solo se envía por conexiones HTTPS. Sin esta flag, una cookie puede transmitirse por HTTP sin cifrar, lo que permite a un atacante en la misma red (por ejemplo, una Wi-Fi pública) interceptarla con un simple sniffer de paquetes. Una vez tiene la cookie de sesión, puede suplantar al usuario. Este ataque se conoce como secuestro de sesión o sidejacking.
• Flag HttpOnly: evita que JavaScript acceda a la cookie a través de document.cookie. Es una protección crítica frente a ataques de cross-site scripting (XSS). Si un atacante consigue inyectar JavaScript malicioso en tu página (mediante un plugin vulnerable, un campo de comentarios o entrada de usuario), la flag HttpOnly impide que ese script lea las cookies de sesión y las envíe a un servidor externo.
• Flag SameSite: controla si la cookie se envía con peticiones entre sitios. Esto protege frente a ataques CSRF, en los que un sitio malicioso engaña al navegador del usuario para que haga peticiones autenticadas a tu sitio. El atributo SameSite tiene tres valores posibles:
  • Strict: la cookie nunca se envía con peticiones entre sitios. Ofrece la protección más fuerte, pero puede romper los flujos de inicio de sesión cuando los usuarios hacen clic en enlaces desde fuentes externas como correos u otros sitios web.
  • Lax: la cookie se envía con la navegación de nivel superior (al hacer clic en un enlace) pero no con peticiones embebidas (imágenes, iframes, AJAX). Es el valor por defecto recomendado para la mayoría de sitios WordPress.
  • None: la cookie se envía con todas las peticiones, incluidas las entre sitios. Debe combinarse con la flag Secure y solo es necesario para cookies que tienen que funcionar en contextos entre sitios, como integraciones de pasarelas de pago o widgets embebidos.

Reforzar las cookies de autenticación de WordPress

WordPress establece varias cookies para los usuarios con sesión iniciada, incluidas wordpress_logged_in_* y wordpress_sec_*. Son las cookies más sensibles desde el punto de vista de seguridad porque controlan el acceso al administrador. Para reforzarlas, añade las siguientes constantes a tu archivo wp-config.php, antes de la línea que dice "That's all, stop editing!":

// Forzar que las cookies se envíen solo por HTTPS
define('FORCE_SSL_ADMIN', true);

// Establecer dominio y ruta de la cookie
define('COOKIE_DOMAIN', 'example.com');
define('COOKIEPATH', '/');

// Reforzar las cookies de sesión de PHP
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');
@ini_set('session.cookie_samesite', 'Lax');

La constante FORCE_SSL_ADMIN es especialmente importante. Obliga a WordPress a usar HTTPS en el área de administración y en las páginas de inicio de sesión, lo que garantiza que las cookies de autenticación solo se establezcan por conexiones cifradas. Sin esto, un usuario que iniciara sesión por HTTP transmitiría sus credenciales y cookies en texto plano.

Ten en cuenta que @ini_set solo afecta a las cookies de sesión de PHP, no a las cookies específicas de WordPress. WordPress usa sus propias funciones para establecer cookies que no dependen de las sesiones de PHP. Para asegurar las cookies de WordPress en concreto, necesitas los enfoques a nivel de servidor descritos a continuación.

Establecer flags de cookies mediante la configuración de PHP

En PHP 7.3 y versiones posteriores, puedes establecer atributos de cookie predeterminados que se aplican a todas las cookies creadas por la función setcookie() de PHP. Añade lo siguiente a tu archivo php.ini si tienes acceso:

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Si no tienes acceso a php.ini (lo habitual en hosting compartido), puedes establecer estos valores en tu archivo .htaccess:

# Establecer valores seguros por defecto para las cookies de sesión de PHP
php_value session.cookie_secure 1
php_value session.cookie_httponly 1
php_value session.cookie_samesite "Lax"

Ten presente que estos ajustes solo se aplican a las cookies creadas mediante el manejo nativo de sesiones de PHP. El núcleo de WordPress y la mayoría de plugins usan setcookie() o wp_set_auth_cookie() directamente, que no heredan automáticamente estos ajustes de ini. Para una cobertura completa, el enfoque de cabeceras a nivel de servidor es más fiable.

Corregir todas las cookies mediante .htaccess en Apache

La forma más fiable de añadir flags de seguridad a cada cookie en un servidor Apache es modificar la cabecera Set-Cookie a nivel de servidor. Esto captura todas las cookies, incluidas las establecidas por el núcleo de WordPress, los plugins y los scripts de terceros:

# Añadir flags de seguridad a todas las cookies
<IfModule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Lax"
</IfModule>

Coloca esto en el archivo .htaccess de la raíz de tu sitio. La directiva Header always edit usa una expresión regular para coincidir con todas las cabeceras Set-Cookie y añade las flags de seguridad a cada una.

Hay una salvedad importante con este enfoque. Si una cookie ya tiene una de estas flags establecidas (por ejemplo, un plugin establece Secure por su cuenta), podrías acabar con flags duplicadas como Secure; Secure. La mayoría de los navegadores manejan los duplicados sin problemas, pero un enfoque más limpio usa una búsqueda negativa hacia adelante para evitar añadir flags que ya estén presentes:

<IfModule mod_headers.c>
    # Añadir la flag Secure si aún no está presente
    Header always edit Set-Cookie "^((?!.*Secure).*)$" "$1; Secure"

    # Añadir la flag HttpOnly si aún no está presente
    Header always edit Set-Cookie "^((?!.*HttpOnly).*)$" "$1; HttpOnly"

    # Añadir SameSite=Lax si no hay atributo SameSite presente
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"
</IfModule>

Esta versión comprueba cada cookie individualmente y solo añade la flag si aún no está. Es más extensa, pero evita posibles problemas con atributos duplicados.

Corregir todas las cookies mediante la configuración de Nginx

Para servidores Nginx, el enfoque depende de tu versión de Nginx:

Nginx 1.19.3 y posteriores admiten la directiva proxy_cookie_flags de forma nativa:

# En tu bloque server o location
proxy_cookie_flags ~ secure httponly samesite=lax;

El símbolo ~ coincide con todas las cookies. También puedes apuntar a cookies concretas por nombre:

# Aplicar solo a las cookies de sesión de WordPress
proxy_cookie_flags wordpress_logged_in_* secure httponly samesite=lax;
proxy_cookie_flags wordpress_sec_* secure httponly samesite=lax;

Las versiones más antiguas de Nginx (anteriores a 1.19.3) pueden usar la directiva proxy_cookie_path como solución alternativa:

# Solución alternativa para versiones antiguas de Nginx
proxy_cookie_path / "/; Secure; HttpOnly; SameSite=Lax";

Si usas Nginx como proxy inverso delante de Apache o PHP-FPM, puede que también necesites añadir cabeceras usando el módulo more_set_headers o la directiva add_header. Sin embargo, add_header no modifica las cabeceras Set-Cookie, por lo que proxy_cookie_flags es el enfoque correcto.

Corregir cookies en sitios detrás de Cloudflare o un CDN

Si tu sitio WordPress está detrás de Cloudflare u otro proxy CDN, el manejo de cookies implica una capa adicional. Cloudflare establece sus propias cookies (como __cf_bm para la gestión de bots) y estas cookies las controla Cloudflare, no la configuración de tu servidor. No puedes añadir flags de seguridad a las cookies de Cloudflare a través de .htaccess o de la configuración de Nginx.

Las cookies de Cloudflare ya incluyen las flags Secure y HttpOnly por defecto. Si InspectWP marca una cookie de Cloudflare como falta de una flag, probablemente sea un problema de visualización o una cookie de una funcionalidad de Cloudflare que omite ciertas flags intencionadamente (por ejemplo, las cookies de analítica que necesitan acceso desde JavaScript pueden carecer de HttpOnly).

Para las cookies establecidas por tu servidor de origen, las correcciones de .htaccess o Nginx descritas arriba siguen funcionando correctamente incluso con Cloudflare delante. Cloudflare pasa las cabeceras Set-Cookie de tu servidor al cliente sin modificarlas.

Gestionar cookies de plugins que carecen de flags de seguridad

Muchos plugins de WordPress establecen sus propias cookies y no todas incluyen las flags de seguridad adecuadas. Los infractores habituales son:

• Plugins de consentimiento de cookies: plugins como CookieYes, Complianz o GDPR Cookie Consent establecen cookies para recordar la elección de consentimiento del usuario. Comprueba en los ajustes de cada plugin si hay una opción "Cookies seguras" o "Seguridad de cookies". Algunos plugins han añadido estas opciones en versiones recientes.
• Plugins de analítica y seguimiento: Google Analytics, Matomo y plugins similares pueden establecer cookies de seguimiento sin flags de seguridad. El enfoque de cabeceras a nivel de servidor (Apache/Nginx) es la mejor solución para estas, ya que los plugins rara vez ofrecen configuración de flags de cookie.
• Plugins de caché: WP Rocket, LiteSpeed Cache y otros establecen cookies identificadoras de caché que pueden carecer de flags. De nuevo, el enfoque a nivel de servidor las gestiona automáticamente.
• WooCommerce: WooCommerce establece varias cookies para datos del carrito y gestión de sesión. Las versiones recientes de WooCommerce (5.0+) establecen la flag Secure cuando el sitio usa HTTPS, pero las versiones antiguas pueden no hacerlo. Actualiza WooCommerce a la última versión y aplica la corrección de cabeceras a nivel de servidor como red de seguridad.
• Plugins de inicio de sesión y membresías: plugins como MemberPress, Restrict Content Pro o WP-Members pueden establecer sus propias cookies de sesión. Comprueba si hay actualizaciones de plugin, ya que muchos han añadido soporte para flags de seguridad en respuesta a los cambios en los navegadores en torno a la aplicación de SameSite.

El enfoque a nivel de servidor (Header edit en Apache o proxy_cookie_flags en Nginx) es la solución más fiable porque captura todas las cookies independientemente de qué plugin o script las establezca. Aunque una actualización de plugin elimine las flags, tu configuración de servidor las vuelve a añadir.

Consideraciones especiales para cookies SameSite=None

Algunas funcionalidades requieren que las cookies se envíen en contextos entre sitios. Ejemplos comunes:

• Devoluciones de pasarelas de pago: servicios como PayPal, Stripe o Mollie pueden redirigir a los usuarios de vuelta a tu sitio tras el pago. Si tu cookie de sesión usa SameSite=Strict, el usuario quedará desconectado tras la redirección porque el navegador no envía la cookie con la navegación entre sitios.
• Contenido embebido (iframes): si tu sitio WordPress está embebido en un iframe en otro dominio, las cookies necesitan SameSite=None; Secure para funcionar. Esto es relevante para configuraciones de WordPress headless o sitios que ofrecen widgets embebibles.
• Flujos OAuth y SSO: las implementaciones de inicio de sesión único que redirigen a través de proveedores de identidad de terceros pueden requerir SameSite=None para la cookie de sesión durante el flujo de autenticación.

Si necesitas SameSite=None para cookies concretas mientras mantienes SameSite=Lax como valor por defecto, necesitarás una configuración más específica. En Apache:

<IfModule mod_headers.c>
    # Por defecto: añadir SameSite=Lax a todas las cookies
    Header always edit Set-Cookie "^((?!.*SameSite).*)$" "$1; SameSite=Lax"

    # Sobrescribir para cookies concretas que necesitan acceso entre sitios
    Header always edit Set-Cookie "(payment_session=.*)" "$1; SameSite=None; Secure"
</IfModule>

Añadir seguridad de cookies mediante un plugin de WordPress

Si no tienes acceso a los archivos de configuración del servidor (algo común en el hosting WordPress gestionado), puedes usar un plugin de WordPress para añadir las flags de seguridad de cookies. El enfoque de plugin funciona enganchándose al filtro wp_headers o usando la función header() de PHP para modificar las cabeceras Set-Cookie antes de que se envíen al navegador:

function add_cookie_security_flags($headers) {
    // Esto afecta a las cabeceras enviadas por WordPress
    if (is_ssl()) {
        $headers['Set-Cookie'] = 'Secure; HttpOnly; SameSite=Lax';
    }
    return $headers;
}
add_filter('wp_headers', 'add_cookie_security_flags');

// Para seguridad de cookies a nivel de PHP
function enforce_cookie_security() {
    if (is_ssl() && PHP_VERSION_ID >= 70300) {
        ini_set('session.cookie_secure', '1');
        ini_set('session.cookie_httponly', '1');
        ini_set('session.cookie_samesite', 'Lax');
    }
}
add_action('init', 'enforce_cookie_security', 1);

Este enfoque tiene limitaciones. Solo afecta a las cookies establecidas después de que se dispare el hook init de WordPress y no puede modificar las cookies establecidas por JavaScript o por scripts externos. El enfoque a nivel de servidor siempre es más completo.

Verificar las flags de seguridad de cookies tras aplicar las correcciones

Después de implementar tus correcciones, las pruebas exhaustivas son esenciales para confirmar que todo funciona correctamente:

1. Borra todas las cookies del navegador: abre las herramientas de desarrollo de tu navegador, ve a la pestaña Aplicación (Chrome) o Almacenamiento (Firefox) y elimina todas las cookies de tu dominio. Así te aseguras de probar cookies nuevas con las flags actualizadas.
2. Visita tu sitio e inicia sesión: tras iniciar sesión, vuelve a las herramientas de desarrollo e inspecciona cada cookie. En Chrome, el panel Aplicación > Cookies muestra columnas para Secure, HttpOnly y SameSite. Cada cookie de autenticación debería mostrar una marca para Secure y HttpOnly, y mostrar "Lax" en SameSite.
3. Prueba los flujos de usuario críticos: navega por la funcionalidad clave de tu sitio: añade artículos a un carrito (si usas WooCommerce), envía formularios, completa el proceso de pago y usa cualquier funcionalidad de membresía. Los cambios de SameSite pueden romper ocasionalmente los flujos entre sitios, así que prueba todo lo que implique redirecciones desde servicios externos.
4. Prueba el inicio de sesión desde enlaces externos: envíate a ti mismo un correo de restablecimiento de contraseña y haz clic en el enlace. Si has usado SameSite=Strict (no recomendado), este flujo puede romperse porque la cookie no se enviará con la navegación entre sitios desde el cliente de correo.
5. Vuelve a ejecutar InspectWP: realiza un nuevo escaneo de tu sitio con InspectWP para confirmar que todas las advertencias de seguridad de cookies están resueltas. InspectWP comprueba cada cookie individualmente, así que puedes ver exactamente qué cookies tienen ahora las flags correctas.

Solución de problemas habituales tras habilitar las flags de seguridad de cookies

• Los usuarios quedan desconectados al hacer clic en enlaces de correo: esto ocurre cuando se establece SameSite=Strict. Cambia a SameSite=Lax, que permite cookies en navegaciones de nivel superior desde sitios externos pero sigue bloqueando peticiones embebidas entre sitios.
• La integración de la pasarela de pago se rompe: algunos procesadores de pago redirigen a los usuarios a través de su propio dominio durante el pago. Si la cookie de sesión no se envía tras la redirección, el usuario pierde su carrito o el estado de inicio de sesión. Establece la cookie de sesión de pago a SameSite=None; Secure específicamente, manteniendo las demás cookies en SameSite=Lax.
• El banner de consentimiento de cookies vuelve a aparecer: si la cookie del plugin de consentimiento se establece sin la flag Secure y tu sitio redirige de HTTP a HTTPS, la cookie establecida en HTTP no se envía por HTTPS, lo que hace que el banner aparezca de nuevo. Asegúrate de que tu sitio funciona íntegramente sobre HTTPS y que la cookie de consentimiento incluye la flag Secure.
• Conflictos de caché: algunos plugins de caché cachean las cabeceras Set-Cookie junto con el contenido de la página. Tras aplicar cambios de flags de cookie a nivel de servidor, purga toda tu caché (tanto la caché de página como la caché de objetos) para asegurar que las nuevas cabeceras surten efecto.
• Flags de cookie duplicadas: si ves atributos como Secure; Secure o SameSite=Lax; SameSite=Lax en tus cookies, hay varias capas añadiendo las mismas flags. Revisa tu .htaccess, wp-config.php, los ajustes de PHP ini y cualquier plugin de seguridad para detectar configuraciones solapadas. Usa el enfoque de regex con búsqueda negativa hacia adelante en .htaccess para evitar duplicados.

Buenas prácticas de seguridad de cookies para WordPress

• Usa siempre HTTPS: la flag Secure no tiene sentido sin HTTPS. Asegúrate de que todo tu sitio se carga sobre HTTPS, incluidos todos los recursos (imágenes, scripts, hojas de estilo). Usa la constante FORCE_SSL_ADMIN y considera una cabecera HSTS para evitar cualquier acceso por HTTP.
• Usa SameSite=Lax por defecto: ofrece una sólida protección frente a CSRF sin romper la navegación normal. Usa SameSite=None solo para cookies concretas que realmente necesiten acceso entre sitios, y usa SameSite=Strict únicamente si tienes la certeza de que ninguna navegación externa hacia tu sitio necesita mantener sesiones.
• Aplica las flags a nivel de servidor: la configuración a nivel de servidor (.htaccess en Apache o configuración de Nginx) captura todas las cookies independientemente de su origen. Es más fiable que los enfoques a nivel de plugin o de PHP.
• Mantén WordPress y los plugins actualizados: las versiones modernas del núcleo de WordPress y la mayoría de plugins populares establecen flags de cookie adecuadas cuando HTTPS está activo. Mantenerlo todo actualizado reduce la cantidad de cookies inseguras que tienes que corregir a nivel de servidor.
• Audita las cookies con regularidad: ejecuta escaneos periódicos con InspectWP para detectar cookies nuevas introducidas por actualizaciones de plugins o nuevas integraciones. La seguridad de cookies no es una corrección puntual; requiere atención continua a medida que tu sitio evoluciona.
• Prueba en varios navegadores: Chrome, Firefox, Safari y Edge gestionan los atributos de cookie de forma ligeramente distinta. Chrome es el que aplica las políticas de SameSite con más rigor, mientras que Safari tiene su propia Intelligent Tracking Prevention que afecta al comportamiento de las cookies. Prueba tu sitio en todos los navegadores principales tras hacer cambios.