Comprobar fugas de contenido para usuarios conectados

Trata cualquier sospecha de que contenido privado o personalizado haya entrado en una caché compartida como un incidente de seguridad. Contén primero la entrega; conserva únicamente la evidencia saneada necesaria para entender el alcance.

Contención inmediata

1. Desactiva o elimina las reglas opcionales de caché directa de Apache para las rutas HTML y JSON afectadas.
2. Desactiva los interruptores de ejecución relevantes de POM Cache.
3. Limpia tanto el HTML del sitio actual como el JSON progresivo.
4. Invalida los objetos CDN afectados o el alcance de ruta de emergencia aprobado.
5. Desactiva cualquier otro proxy inverso o caché de aplicación que pueda retener la respuesta.
6. Mantén la funcionalidad personalizada afectada no disponible hasta que se verifique el comportamiento anónimo y autenticado.

Cambiar únicamente un interruptor de WordPress puede no detener una regla de Apache copiada, porque esa regla puede servir un archivo antes de que PHP lea el ajuste.

Si la salida en caché incluyó nonces activos, enlaces de restablecimiento, tokens, URLs de archivos privados o material de sesión, sigue tu procedimiento de incidentes y rota o revoca las credenciales afectadas cuando corresponda.

Conserva evidencia segura

Antes de que la evidencia desaparezca, registra:

• la marca de tiempo y la ruta pública exacta saneada;
• el sitio y el nombre de host;
• si fue el HTML o el JSON el que contenía el valor privado;
• el estado de la respuesta y las cabeceras no sensibles de caché/CDN;
• la reproducción anónima frente a la autenticada;
• el estado relevante de los interruptores de POM Cache;
• si la entrega de Apache y del CDN estaban activas;
• una descripción redactada del campo expuesto.

No pegues el cuerpo privado en un ticket público. Nunca compartas cookies, cabeceras de autorización, claves de licencia, registros personales, nonces, credenciales ni rutas privadas absolutas del servidor.

Prueba la separación de sesiones

Después de la contención:

1. crea dos perfiles de navegador privados separados sin cookies compartidas;
2. mantén uno anónimo e inicia sesión en el otro con una cuenta de prueba de bajo privilegio;
3. solicita la misma URL en ambos;
4. repite con sesiones de comercio/carrito, protegidas por contraseña, de suscripción o de membresía que utilice el sitio;
5. inspecciona tanto el HTML inicial como las solicitudes JSON/de red posteriores;
6. confirma que una respuesta personalizada nunca se reutilice en el perfil anónimo.

Usa datos de prueba sintéticos, no la información de un cliente real.

Encuentra la causa

Comprueba si la salida privada variaba por una propiedad ausente de la clave de caché:

• identidad o capacidad del usuario;
• autorización o suscripción;
• carrito o sesión;
• cookie no cubierta por una omisión;
• nonce o URL de un solo uso;
• parámetro de consulta significativo;
• geografía, moneda, idioma o dispositivo;
• solicitud tardía del lado del cliente que se cacheó de forma independiente.

Luego revisa cuándo declara la funcionalidad DONOTCACHEPAGE, si un filtro de lectura tardío puede pasar por alto la fase temprana y si el archivo existía antes de que la funcionalidad se volviera privada.

Recuperación segura

Antes de volver a activar:

• evita escrituras futuras de la representación personalizada;
• asegúrate de que las cookies de omisión cubran todas las sesiones relevantes;
• limpia de nuevo los archivos antiguos después de desplegar la corrección;
• verifica el comportamiento del origen PHP;
• verifica las reglas de Apache por separado;
• verifica el CDN con un objeto nuevo;
• repite la matriz de dos sesiones;
• prueba la invalidación después de cambios de cuenta y de contenido.

Un filtro normal de plugin no puede ser la única salvaguarda si un archivo existente puede servirse durante advanced-cache.php o por Apache. La arquitectura y el diseño de rutas deben hacer que la representación compartida sea pública por construcción.