Scheid applicatiecache en HTTP-cache
Redis, Workers KV en HTTP-caches hebben niet automatisch dezelfde garanties. Workers KV is uiteindelijk consistent: een schrijfactie is niet direct overal zichtbaar. De volgende instructies gelden voor HTTP-caches en configureren niet zelfstandig de applicatiecache.
| HTTP-antwoordinstructie | Hoofdbetekenis | Beperking |
|---|---|---|
| no-cache | Opslag toegestaan, valideren vóór hergebruik. | Betekent niet “niets opslaan”. |
| no-store | Dit antwoord niet in caches opslaan. | Verwijdert eerdere kopieën niet automatisch. |
| private | Geen opslag in gedeelde cache. | Geen authenticatieregel. |
| max-age | Versheidsduur van een antwoord. | Garandeert geen consistentie van alle gegevens. |
Test het juiste antwoord voor de juiste persoon
- Definieer sleutelvariaties voor bron, parameters, taal en rechten. Test dat een account nooit het privéantwoord van een ander ontvangt.
- Bepaal maximale ouderdom, ongeldig maken en gedrag na wijziging of verwijdering. Een korte TTL garandeert niet onmiddellijk consistente leesacties.
- Test gelijktijdig verlopen, cache-uitval en oorsprongsuitval. Bundel vernieuwingen waar nodig en gebruik oude antwoorden alleen als bedrijfsregels dat toelaten.
Meet meer dan het cachetrefferpercentage
Volg latentie, fouten, oorsprongsbelasting en onjuiste of verouderde antwoorden. Saldi, gereserveerde voorraad en rechten kunnen andere garanties vragen dan een openbare catalogus. Een snelle cache mag geen ongecontroleerde alternatieve waarheid worden.
Primaire bronnen
API-caching moet toegangsbeslissingen behouden
Een antwoordcache kan een onjuiste query snel maken wanneer sleutels de machtigingen van de aanvrager negeren. Het risico neemt toe wanneer een grafiek openbare en privéobjecten combineert.
- Classificeer openbare, privé- en rolafhankelijke velden vóór caching.
- Test een antwoord onder één account en vraag het op onder een ander account.
- Maak resultaten ongeldig na wijzigingen in machtigingen of gegevens.
Primaire bron: OWASP — GraphQL Cheat Sheet. Verwante methode: lees de praktische gids.
Meet ook hoe actueel cachegegevens zijn
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Twee leesacties zijn snel, maar één toont na een bronwijziging nog de oude beschikbaarheid.
- Vergelijk waarde, versie, leeslocatie en tijd sinds wijziging. Test ongeldig maken, verlopen en toegang tot de bron volgens de systeemafspraken.
- Bepaal aanvaardbare veroudering per toepassing en bewaak verschillen. Lagere vertraging bewijst geen consistentie van geleverde gegevens.
Primaire bron: IETF — RFC 9111, HTTP Caching. Verwante methode: lees de praktische gids.
Verlaten subdomeinen: een CNAME gecontroleerd verwijderen
Koppel DNS-namen aan beheerde middelen en sluit afhankelijkheden voordat een dienst wordt vrijgegeven.
- Leg naam, CNAME-keten, leveranciersmiddel en eigenaar vast. Vergelijk DNS met de inventaris van het bevoegde account. Een HTTP-fout, NXDOMAIN of ontbrekend middel vraagt onderzoek en bewijst geen overnamemogelijkheid; bescherming verschilt per leverancier.
- Verwijder de verwijzing of gebruik een beheerd doel voordat het middel wordt vrijgegeven. Houd rekening met eerdere TTL-waarden en caches; controleer autoritatieve DNS en meerdere resolvers. Bewaar noodzakelijke eigendomsvalidaties in plaats van alle TXT-records te wissen.
- Controleer links, redirects, OAuth-callbacks, webhooks en cookiedomeinen. Is het middel al vrijgegeven, corrigeer DNS en onderzoek blootstelling via het incidentproces. Vergelijk DNS en middelen na elke verwijdering.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Verwachte beslissing
Fictief voorbeeld: portal.example verwijst naar een verwijderd middel. Verwijder de CNAME of kies een beheerd doel; afwezigheid bewijst geen overname door derden.
Bewijst een foutpagina dat een subdomein overneembaar is?
Nee. Bevestig middelstatus en reserverings- of eigendomscontroles van de leverancier. Claim geen middel om het risico aan te tonen.
Primaire bron: Microsoft — Prevent dangling DNS entries. Verwante methode: lees de praktische gids.
ETag, HTTP-cache en gelijktijdige wijzigingen
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
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: fouten, lijsten en gedeeltelijke data
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
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