Separare cache applicativa e HTTP
Redis, Workers KV e cache HTTP non condividono automaticamente garanzie. Workers KV ha coerenza eventuale: una scrittura non è subito visibile ovunque. Le direttive seguenti riguardano HTTP e non configurano da sole la cache applicativa.
| Direttiva di risposta HTTP | Significato principale | Limite |
|---|---|---|
| no-cache | Memorizzazione possibile, validazione prima del riuso. | Non significa «non memorizzare». |
| no-store | Non memorizzare questa risposta nelle cache. | Non elimina automaticamente copie precedenti. |
| private | Nessuna memorizzazione in cache condivisa. | Non è una regola di autenticazione. |
| max-age | Durata di freschezza della risposta. | Non garantisce coerenza di tutti i dati. |
Provare la risposta corretta per ogni persona
- Definite variazioni della chiave: risorsa, parametri, lingua e ambito dei permessi. Verificate che un account non riceva risposte private di un altro.
- Specificate età massima, invalidazione e comportamento dopo modifica o cancellazione. Un TTL breve non garantisce letture immediatamente coerenti.
- Testate scadenze simultanee, guasto della cache e dell’origine. Raggruppate aggiornamenti se necessario e servite risposte scadute solo quando le regole applicative lo permettono.
Misurare oltre il tasso di risposte in cache
Seguite latenza, errori, carico all’origine e risposte errate o obsolete. Saldi, scorte riservate e permessi possono richiedere garanzie diverse da un catalogo pubblico. Una cache rapida non deve diventare una fonte alternativa incontrollata.
Fonti primarie
La cache delle API deve preservare le decisioni di accesso.
Una cache di risposta può rendere veloce una query errata quando le chiavi ignorano le autorizzazioni del richiedente. Il rischio aumenta quando un grafo combina oggetti pubblici e privati.
- Classificare i campi pubblici, privati e dipendenti dal ruolo prima di memorizzarli nella cache.
- Testare una risposta con un account e richiederla con un altro.
- Invalidare i risultati dopo modifiche alle autorizzazioni o ai dati.
Fonte primaria: OWASP — GraphQL Cheat Sheet. Metodo correlato: consultare la guida pratica.
Misurare anche l’aggiornamento della cache
Esempio fittizio: questi dati non descrivono clienti o risultati osservati.
Due letture sono veloci, ma una mostra ancora una disponibilità precedente dopo una modifica alla fonte.
- Confrontare valore, versione, punto di lettura e tempo dalla modifica. Provare invalidazione, scadenza e accesso alla fonte secondo il contratto del sistema.
- Definire l’anzianità accettabile dei dati per ogni uso e sorvegliare le divergenze. Minore latenza non dimostra coerenza dei dati serviti.
Fonte primaria: IETF — RFC 9111, HTTP Caching. Metodo correlato: consultare la guida pratica.
Sottodomini abbandonati: rimuovere un CNAME con controllo
Collegare i nomi DNS a risorse controllate e chiudere le dipendenze prima del rilascio.
- Registra nome, catena CNAME, risorsa del fornitore e responsabile. Confronta DNS e inventario dell’account autorizzato. Errori HTTP, NXDOMAIN o risorse assenti richiedono verifica, ma non provano la possibilità di acquisizione; le protezioni variano.
- Elimina il riferimento o usa una destinazione controllata prima di rilasciare la risorsa. Considera TTL precedenti e cache; verifica DNS autoritativo e più resolver. Conserva le validazioni di proprietà ancora necessarie, senza cancellare tutti i TXT.
- Verifica link, redirect, callback OAuth, webhook e domini dei cookie. Se la risorsa è già stata liberata, correggi DNS e indaga eventuali esposizioni tramite la procedura d’incidente. Riconcilia DNS e risorse dopo ogni eliminazione.
Caso di accettazione riproducibile
Esempio fittizio: questi dati non descrivono clienti o risultati osservati.
Vedi dati 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"
}Decisione attesa
Esempio fittizio: portal.example punta a una risorsa eliminata. Rimuovi il CNAME o usa una destinazione controllata; l’assenza non dimostra un’acquisizione da parte di terzi.
Una pagina di errore prova che il sottodominio è acquisibile?
No. Conferma stato e meccanismi di riserva o validazione del fornitore. Non acquisire risorse per dimostrare il rischio.
Fonte primaria: Microsoft — Prevent dangling DNS entries. Metodo correlato: consultare la guida pratica.
ETag, cache HTTP e modifiche concorrenti
Le note dettagliate di questa edizione sono disponibili in inglese.
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: errori, liste e dati parziali
Le note dettagliate di questa edizione sono disponibili in inglese.
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