Risorse · 63
Cache HTTP: proteggere le risposte personalizzate
Separare le cache condivise, private e dell'applicazione, ispezionare le chiavi, la convalida e l'invalidazione dopo le modifiche dei diritti di accesso.
Aggiornato · 3 min
Obiettivi di questa guida
- Livelli di inventario
- Scegliere la conservazione
- Ispezionare le chiavi
- Eseguire la riconvalida e la modifica
Verifica rapida
- L'assenza di cache significa che non viene conservato nulla?
- Vary protegge i diritti di accesso?
- Tutte le API dovrebbero essere memorizzate nella cache?
Metodo passo passo
- 1
Livelli di inventario
Elencare le cache di browser, CDN, proxy, service worker e applicazioni. Classificare le risposte pubbliche e personalizzate. Una policy HTTP non descrive automaticamente la memorizzazione nella cache implementata nel codice.
Risultato: diagramma dei livelli e dei proprietari.
- 2
Scegliere la conservazione
RFC 9111 distingue le direttive: no-cache richiede la convalida prima del riutilizzo, no-store vieta la memorizzazione HTTP pertinente e unqualified private esclude la memorizzazione condivisa. Nessuno da solo garantisce la riservatezza del sistema. Risultato
Risultato: politica di conservazione per risposta.
- 3
Ispezionare le chiavi
Verificare il metodo, l'URI e le dimensioni che modificano una rappresentazione. La variabile riguarda i campi della richiesta; non si tratta di autorizzazione. Ricercare la lingua omessa, la negoziazione del formato e il contesto dell'account nei livelli applicativi. Risultato
Risultato: chiavi e test di separazione.
- 4
Eseguire la riconvalida e la modifica
Testare risposte nuove e obsolete, aggiornamenti dei dati e diritti revocati. Ispezionare l'ETag, la convalida condizionale e il comportamento in caso di origine non disponibile. Una risposta precedentemente corretta potrebbe diventare sensibile dopo la revoca.
Risultato: tracce prima e dopo.
- 5
Riproduzione con due account.
Utilizzo di identità e marcatori fittizi. Richieste alternate allo stesso URI con cache calde e fredde. Verifica del logout, dei link diretti e del logging senza registrare token reali.
Risultato: test negativi e strategia di invalidazione.
Foglio di lavoro riutilizzabile
Completare con le proprie osservazioni autorizzate. Questi campi costituiscono un modello di lavoro, non risultati osservati.
| Campo | Informazioni da registrare |
|---|---|
| Risposta | Pubblico o personalizzato; Dimensioni |
| Livello | Cache, proprietario e chiave |
| Politica | Conservazione, aggiornamento e convalida |
| Prova | Account fittizio, modifica e osservazione |
Esempio pratico fittizio
Situazione illustrativa
Esempio fittizio: una CDN riutilizza una risposta del profilo allo stesso URI per due account di test.
Decisione e prove attese
Lo scenario rileva una perdita di dati, esamina le policy e le chiavi, quindi riproduce il comportamento dopo la correzione e la revoca dell'accesso.
Distinguere i meccanismi
| Meccanismo | Scopo | Verifica o limitazione |
|---|---|---|
| senza cache | Consenti l'archiviazione con convalida richiesta | Non interpretarlo come nessuna archiviazione |
| Privato non qualificato | Escludi la cache condivisa | Non interpretarlo come una garanzia di riservatezza |
| senza memorizzazione | Impedisci la memorizzazione HTTP pertinente | Controlla separatamente le cache e la cronologia dell'applicazione |
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Separazione degli account | Nessun marcatore da un altro account | Ispeziona corpo, link e metadati |
| Età e convalida | Riutilizzo coerente con la policy | Verifica la scadenza e l'origine non disponibile |
| Ritardo di invalidazione | Tempo fino alla rappresentazione corretta | Denomina ogni livello ancora obsoleto |
Errori comuni
- Non interpretarlo come nessuna archiviazione
- Non interpretarlo come una garanzia di riservatezza
- Controlla separatamente le cache e la cronologia dell'applicazione
Domande frequenti
L'assenza di cache significa che non viene conservato nulla?
No. Richiede la convalida prima del riutilizzo; non vieta l'archiviazione come fa "senza memorizzazione".
Vary protegge i diritti di accesso?
No. Partecipa alla selezione della rappresentazione; l'autorizzazione rimane separata.
Tutte le API dovrebbero essere memorizzate nella cache?
No. I vantaggi dipendono da costi, attualità e rischio. Le risposte sensibili possono giustificare l'evitare cache condivise.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
Riferimenti consultati il .
