Caché HTTP y multas: cuándo una optimización filtra datos
Una clave de caché incompleta puede entregar la respuesta de un tenant a otro. Las consultas sensibles exigen una política explícita, pruebas con identidades ficticias y purga.
Por Marco Ferreiro ·
Cachear una respuesta puede ahorrar segundos y costos. También puede convertir un error de configuración en una filtración: la empresa B solicita una URL y recibe el cuerpo que el proxy guardó para la empresa A. Cuando el contenido reúne infracciones, la optimización cruza un límite de privacidad.
El riesgo no se resuelve agregando un header de memoria. Hay que identificar qué cachés existen, qué forma su clave y cómo se prueba que una flota no reciba las actas de otra.
Caché privada y compartida
RFC 9111 distingue caché privada, dedicada a un usuario —por ejemplo, un navegador— y caché compartida, reutilizable por varios usuarios —como un proxy o CDN—. Esa diferencia es central.
Cache-Control: private impide que una caché compartida almacene la respuesta, pero permite almacenamiento privado sujeto a otras reglas. no-store ordena no guardar ninguna parte de solicitud o respuesta en cachés conformes.
Ninguna directiva cifra el listado de actas ni autentica al solicitante. La seguridad de transporte y la autorización siguen siendo independientes.
El error de clave incompleta
Una caché suele empezar por método y URL. Si /api/resultados/123 devuelve las actas de un tenant o de otro según Authorization, usar sólo la URL mezcla variantes.
RFC 9111 restringe el uso compartido de respuestas a solicitudes con Authorization, salvo directivas que lo habiliten explícitamente. Sin embargo, configuraciones personalizadas pueden ignorar la intención o retirar headers antes de llegar al proxy.
Una regla public o s-maxage aplicada por comodidad puede permitir almacenamiento compartido de un listado de infracciones que nunca debió salir del tenant.
Vary no es una lista mágica
Vary indica qué headers de la solicitud participan en la selección de una respuesta almacenada. Si el contenido cambia por Accept-Encoding, esa variación es normal. Si cambia por una identidad interna que el CDN no ve, Vary no puede inventarla.
Además, variar por Authorization puede producir muchas entradas y exponer tokens en claves o telemetría según el producto. No se recomienda sin entender la implementación.
Para resultados de multas, el diseño más sencillo suele ser desactivar caché compartida y optimizar datos públicos o cálculos internos por separado.
Capas que también almacenan
El camino de una consulta de patente puede incluir navegador, service worker, balanceador, CDN, reverse proxy, framework, cliente móvil y caché. Cambiar el header del origen no purga automáticamente copias previas ni evita que código de aplicación guarde el cuerpo.
Se hace un inventario por capa: responsable, clave, TTL, almacenamiento, cifrado, purga y logs. Una respuesta puede salir con no-store y aun así quedar en un log de depuración; eso no es caché HTTP, pero conserva el mismo dato.
La Ley 25.326 define tratamiento de forma amplia, incluyendo almacenamiento y comunicación. La evaluación debe abarcar el ciclo completo.
Prueba con dos tenants ficticios
Montamos un proxy local y un origen de prueba. Tenant Alfa solicita un fixture con una acta ficticia; Tenant Beta solicita la misma URL con otra credencial y espera otro cuerpo. Alternamos orden, repetimos solicitudes y vaciamos el origen para comprobar si el proxy responde.
La prueba registra Age, indicadores de hit, clave depurada y hash del cuerpo. Falla si una respuesta trae el acta marcada del otro tenant. También prueba usuarios con roles distintos dentro de una misma empresa.
No se usan patentes reales. Los fixtures se identifican con dominios imposibles y no salen del entorno de test.
Matriz de headers
Probamos al menos estas políticas:
private, no-storepara respuestas altamente sensibles;private, max-age=...sólo si existe un caso claro de caché del usuario;no-cachecuando se permite guardar pero debe revalidarse;public, s-maxageúnicamente para recursos verdaderamente públicos.
no-cache no significa “no guardar”: exige revalidación antes de reutilizar. Confundirlo con no-store deja copias donde no se esperaban.
Cada ruta documenta su política y tiene una prueba automatizada de headers.
Cookies y respuestas personalizadas
Una respuesta puede depender de cookie de sesión aunque la API use una URL pública. Si una página SSR incluye el titular, la patente buscada o sus actas, no debe entrar en el caché del HTML público.
La presencia de Set-Cookie tampoco garantiza que todos los intermediarios rechacen el cuerpo. La configuración del CDN y las directivas explícitas deben coincidir.
Cuando una respuesta contiene cookies, este proyecto evita caché compartida. Es una regla auditable, no una heurística.
Purga y cambio de políticas
Corregir headers afecta respuestas futuras. Las entradas ya almacenadas pueden seguir vigentes. Por eso un incidente o cambio de privacidad incluye purga por rutas y claves, rotación cuando corresponde y verificación desde una sesión nueva.
La purga se prueba: se precarga un fixture, se cambia política, se invalida y se confirma que no reaparece sin tocar el origen. Un botón de “purge all” sin evidencia no cierra el caso.
El historial registra qué regiones o capas fueron alcanzadas.
Observabilidad sin repetir la filtración
Las métricas pueden contar hits por ruta y política sin guardar cuerpo, patente o token. Los logs de clave usan un hash acotado o un identificador interno, nunca credenciales completas.
Una alerta detecta hits compartidos en las rutas de consulta de patentes, Age inesperado o ausencia de Cache-Control. La muestra de respuesta queda en un entorno restringido y sintético.
Qué sí conviene cachear
Hay superficies públicas seguras: catálogo de categorías, documentación, artículos publicados y assets con hash. Separarlas de los resultados de multas mejora rendimiento sin mezclar riesgos.
Dentro del backend también pueden cachearse metadatos no personales, como el catálogo de jurisdicciones, con claves bien definidas. La decisión se documenta por dato y no se extrapola a todo un endpoint.
Una optimización que debe probar aislamiento
La pregunta no es sólo “¿bajó la latencia?”, sino “¿puede una flota recibir las multas de otra?”. Si la respuesta no se prueba con tenants alternados y cada capa real, el ahorro no está listo.
En información vehicular, el valor seguro es explícito: nada de caché compartida por accidente, claves completas cuando se habilita y capacidad de purgar con evidencia.
Metodología
- Alcance
- Prueba local de aislamiento de caché para respuestas sensibles de dos tenants ficticios, con rutas y credenciales sin datos reales.
- Unidad de análisis
- Una solicitud autenticada, su clave efectiva de caché, headers, cuerpo sintético y tenant que recibe la respuesta.
- Cobertura
- Semántica de RFC 9110 y RFC 9111, contrastada con obligaciones generales de tratamiento de datos de la Ley 25.326 al 14 de agosto de 2026.
Limitaciones
- La nota no constituye asesoramiento legal ni audita la configuración de un CDN específico.
- Proxies, navegadores, service workers y cachés internos deben probarse por separado en cada arquitectura.
Fuentes
- RFC 9111 — HTTP Caching — RFC Editor (consultada el )
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
- Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el )
- Decreto 1558/2001 — reglamentación de la Ley 25.326 — Argentina.gob.ar (consultada el )
Preguntas frecuentes
¿`Cache-Control: private` cifra la respuesta?
No. Indica que una caché compartida no debe almacenarla; no aporta cifrado ni reemplaza TLS, autorización, aislamiento del navegador o controles del backend.
¿`no-store` garantiza que ningún sistema conservará datos?
RFC 9111 exige que las cachés conformes no almacenen, pero aclara que no es un mecanismo suficiente de privacidad. Logs, service workers o software comprometido requieren controles propios.
¿Alcanza con incluir el tenant en `Vary`?
Sólo si esa cabecera representa realmente toda la identidad y el intermediario la respeta. Tokens, roles, filtros y versión también pueden cambiar el contenido; para resultados sensibles suele ser más simple no usar caché compartido.
Notas relacionadas
Timeout no significa “sin multas”: cómo informar resultados parciales en una integración
Cuando una fuente no responde, el resultado es parcial o indeterminado, nunca cero. Un contrato explícito permite reintentar, alertar y decidir sin producir falsos negativos.
Polling de consultas de multas sin saturar la API: Retry-After y ETag
Consultar el estado cada segundo no hace que una búsqueda termine antes. Un contrato con Retry-After, ETag y una espera aleatoria reduce solicitudes repetidas, bytes y picos de clientes sincronizados.
Avisar antes de quedarse sin cuota de consultas de multas
Avisar que la cuota está por agotarse sirve sólo si queda tiempo para actuar. El nivel consumido no alcanza: hacen falta ritmo, fecha proyectada, un destinatario con nombre y una acción escrita.