WordPress Seguridad de caché: mantenga privados los datos del cliente

Un cliente abre una página de cuenta y ve el nombre de otra persona. Es posible que el inicio de sesión esté funcionando según lo diseñado. Es posible que un caché compartido haya guardado la página equivocada y la haya enviado al siguiente visitante.

El almacenamiento en caché hace que WordPress sea más rápido al reutilizar el trabajo. Pero una página creada para una persona necesita reglas diferentes a las de una publicación de blog público. Esta guía muestra cómo verificar ese límite sin desactivar todas las funciones de velocidad.

Mapee los cachés que utiliza su sitio

Comience con el navegador, luego la CDN, la caché de alojamiento, el complemento de caché de páginas y la caché de objetos. Una CDN es una red que ofrece contenido cerca de los visitantes. Un caché de objetos almacena datos utilizados por la aplicación; no es lo mismo que una página completa guardada.

Anota quién es el propietario de cada capa. Dos herramientas pueden parecer correctas de forma aislada, mientras que una regla general anula a la otra. Una regla de "guardar todo en caché" merece una revisión minuciosa en una tienda o sitio de membresía.

Nuestro WordPress guía de velocidad cubre el lado del rendimiento. Agregue una verificación de privacidad al mismo trabajo para que las ganancias de velocidad no oculten una fuga de datos.

Decide qué respuestas deben permanecer privadas

Lista de páginas que muestran nombres, pedidos, direcciones, descargas privadas, detalles de cuentas o precios personalizados. Incluya las llamadas a la API que cargan estos datos después de que se abre la página.

Las páginas de carrito, pago y cuenta a menudo necesitan reglas de omisión de caché compartida. Lo mismo ocurre con las respuestas autenticadas y las páginas que dependen de una sesión privada. Verifique las rutas reales utilizadas por sus complementos; una página de cuenta personalizada puede tener una URL diferente.

Una página pública aún puede cargar un widget privado. Por ejemplo, es posible que sea seguro almacenar en caché el shell de la página, mientras que su resumen de orden no lo es. Inspeccione la respuesta que contiene los datos privados, no solo la barra de direcciones.

Utilice nuestro WooCommerce lista de verificación de seguridad para incluir flujos de cuenta y pago en la revisión.

Comprenda tres directivas de caché útiles

El encabezado Cache-Control le dice a los cachés compatibles cómo manejar una respuesta. "Privado" excluye los cachés compartidos, pero puede permitir un caché del navegador. "No-store" indica a los cachés que no retengan la respuesta. "Sin caché" permite el almacenamiento pero requiere validación antes de su reutilización. No significa "nunca guardes esto".

Estos significados y el comportamiento específico del proveedor están documentados en Guía de control de caché de Cloudflare. Verifique también las reglas de su host y de CDN. Un encabezado por sí solo no es una prueba de lo que hace toda la pila.

Para páginas confidenciales, utilice una política deliberada tanto para el navegador como para las cachés compartidas. Luego pruebe la respuesta. Mantenga controles de autenticación: los encabezados de la caché no pueden decidir quién puede ver un pedido.

Ejecute una prueba de dos cuentas

Cree dos clientes de prueba con datos ficticios claramente diferentes. Utilice perfiles de navegador separados para que las cookies permanezcan separadas. Un tercer perfil debería permanecer cerrado.

• Inicie sesión como cliente A y abra la página de la cuenta varias veces.
• Abra la misma ruta que el cliente B y compare el resultado.
• Solicita la ruta estando desconectado.
• Repita después de una purga de caché y nuevamente después de que el caché se haya calentado.
• Consulta tanto la página visible como las respuestas de la red que la llenan.

Ningún nombre, orden o dirección privada debe cruzarse entre estas sesiones. Repita con un carrito, un inicio de sesión caducado y una descarga protegida con contraseña. Utilice pedidos de prueba, no registros de clientes reales.

Nuestro guía de seguridad de sesión explica por qué las cookies y el comportamiento de cierre de sesión son importantes aquí.

Compruebe lo que realmente sirvió el caché

Pídale a su desarrollador que inspeccione los encabezados de respuesta y el estado de la caché. Es necesario investigar un acceso inesperado a la memoria caché de una respuesta privada. Un error de caché no es suficiente para demostrar la seguridad; la próxima solicitud puede ser un éxito.

Pruebe con la misma CDN y configuración de alojamiento que el sitio activo. Si la preparación no tiene CDN, sus resultados no cubrirán el almacenamiento en caché perimetral. Incluir salvaguardias de puesta en escena y un pequeño control en vivo controlado.

Mantener un registro de la ruta, estado del usuario, comportamiento esperado y resultado. Repita estas comprobaciones después de un cambio en el complemento de caché, una nueva función de membresía o un cambio de alojamiento.

Qué hacer si los datos están expuestos

Detenga el almacenamiento en caché compartido en las rutas afectadas y elimine las respuestas almacenadas en cada capa relevante. Conserve suficiente evidencia para comprender qué datos se entregaron y cuándo. Corrija la regla, vuelva a realizar la prueba y evalúe quiénes pueden haberse visto afectados.

Cambiar un encabezado no elimina de manera confiable las copias antiguas que ya están almacenadas en otro lugar. Siga los pasos en nuestro guía de respuesta a incidentes si el problema involucra datos del cliente.

Las publicaciones públicas y los activos estáticos aún pueden beneficiarse del almacenamiento en caché. Para obtener ayuda para verificar el límite, nuestro servicio de optimización de velocidad Puede revisar el rendimiento junto con el comportamiento de la página privada.

Preguntas frecuentes

¿Debo desactivar todo el almacenamiento en caché en una tienda WordPress?

Generalmente no. El contenido público y los activos estáticos aún se pueden almacenar en caché. Revise las páginas privadas, las sesiones y las respuestas de API por separado.

¿La falta de caché impide que se almacene una página?

No. Permite el almacenamiento pero requiere validación antes de su reutilización. No-store es la directiva utilizada para evitar el almacenamiento.

¿Es suficiente cerrar sesión en el navegador para probar la privacidad de la caché?

No. Pruebe dos cuentas de usuario independientes y una sesión cerrada. Verifique los estados de caché frío y caliente.

¿La limpieza del caché soluciona una mala regla?

No. Una purga elimina las copias almacenadas, pero la misma regla puede almacenar datos privados nuevamente. Corrija la política y vuelva a probarla.