Separar caché de aplicación y HTTP
Redis, Workers KV y cachés HTTP no comparten automáticamente garantías. Workers KV tiene consistencia eventual: una escritura no es visible inmediatamente en todas partes. Las directivas siguientes corresponden a HTTP; no configuran por sí solas la caché de aplicación.
| Directiva de respuesta HTTP | Significado principal | Límite |
|---|---|---|
| no-cache | Permite almacenar; exige validar antes de reutilizar. | No significa «no almacenar». |
| no-store | No almacenar esta respuesta en cachés. | No elimina automáticamente copias anteriores. |
| private | No almacenar en caché compartida. | No es una regla de autenticación. |
| max-age | Duración de frescura de una respuesta. | No garantiza coherencia de todos los datos. |
Probar la respuesta correcta para cada persona
- Defina variaciones de clave: recurso, parámetros, idioma y permisos. Compruebe que una cuenta nunca recibe la respuesta privada de otra.
- Especifique antigüedad máxima, invalidación y comportamiento tras cambios o borrado. Un TTL corto no garantiza lecturas inmediatamente coherentes.
- Pruebe caducidad simultánea, fallo de caché y fallo del origen. Agrupe actualizaciones cuando proceda y sirva respuestas caducadas solo si las reglas de negocio lo permiten.
Medir más que los aciertos de caché
Controle latencia, errores, carga del origen y respuestas incorrectas o antiguas. Saldos, inventario reservado y permisos pueden requerir garantías distintas de un catálogo público. Una caché rápida no debe convertirse en una fuente de verdad alternativa sin control.
Fuentes primarias
El almacenamiento en caché de la API debe preservar las decisiones de acceso.
Una caché de respuestas puede acelerar una consulta incorrecta cuando las claves ignoran los permisos del solicitante. El riesgo aumenta cuando un gráfico combina objetos públicos y privados.
- Clasifique los campos públicos, privados y dependientes del rol antes de almacenarlos en caché.
- Pruebe una respuesta con una cuenta y solicítela con otra.
- Invalide los resultados tras cambios en los permisos o los datos.
Fuente primaria: OWASP — GraphQL Cheat Sheet. Método relacionado: consultar la guía práctica.
Medir también la frescura de la caché
Ejemplo ficticio: estos datos no describen clientes ni resultados observados.
Dos lecturas son rápidas, pero una sigue mostrando disponibilidad antigua después de cambiar la fuente.
- Comparar valor, versión, lugar de lectura y tiempo desde el cambio. Probar invalidación, caducidad y consulta de origen según el contrato del sistema.
- Definir la frescura aceptable por uso y vigilar discrepancias. Una latencia menor no demuestra coherencia de los datos servidos.
Fuente primaria: IETF — RFC 9111, HTTP Caching. Método relacionado: consultar la guía práctica.
Subdominios abandonados: retirar un CNAME con control
Vincular cada nombre DNS a un recurso controlado y cerrar sus dependencias antes de liberar el servicio.
- Registra nombre público, cadena CNAME, recurso y responsable. Compara DNS con el inventario de la cuenta autorizada. Un error HTTP, NXDOMAIN o recurso ausente exige revisión; no demuestra que un tercero pueda reclamarlo. Las protecciones varían por proveedor.
- Elimina el enlace o dirígelo a un destino controlado antes de borrar el recurso. Considera los TTL anteriores y las cachés; comprueba DNS autoritativo y varios resolutores. Conserva las validaciones de propiedad aún necesarias, sin borrar todos los TXT.
- Revisa enlaces, redirecciones, callbacks OAuth, webhooks y dominios de cookies. Si el recurso ya fue liberado, corrige DNS e investiga posibles exposiciones según el proceso de incidentes. Reconcilia DNS e inventario tras cada eliminación.
Caso de aceptación reproducible
Ejemplo ficticio: estos datos no describen clientes ni resultados observados.
Ver datos del caso
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Decisión esperada
Ejemplo ficticio: portal.example apunta a un recurso eliminado. Retira el CNAME o usa un destino controlado; la ausencia del recurso no demuestra una toma de control por terceros.
¿Una página de error demuestra que el subdominio puede reclamarse?
No. Confirma el estado y las reservas o validaciones del proveedor. No reclames recursos para demostrar el riesgo.
Fuente primaria: Microsoft — Prevent dangling DNS entries. Método relacionado: consultar la guía práctica.
ETag, caché HTTP y actualizaciones concurrentes
Las notas detalladas de esta edición están disponibles en inglés.
Revalidation does not replace cache isolation
A matching If-None-Match can justify 304 for the selected representation after access checks. It does not by itself select the correct user variant.
- Separate variant selection, authorisation and validator comparison.
- Test weak and strong tags with If-None-Match: the comparison is weak.
- Read no-cache as validation before reuse, rather than no-store.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
GraphQL: errores, listas y datos parciales
Las notas detalladas de esta edición están disponibles en inglés.
GraphQL result: follow the error path
Aliases belong to the result; list indices start at zero. These details determine where a client should flag missing data.
- Compare absent data, partial data and data: null.
- Keep the original path even when a parent becomes null.
- Test permissions, quotas and interface states separately.
Explore GraphQL responses and nullability →
GraphQL Specification · September 2025 · Published edition · September 2025