Anwendungs- und HTTP-Cache unterscheiden
Redis, Workers KV und HTTP-Caches haben nicht automatisch gleiche Garantien. Workers KV ist eventuell konsistent: Schreibvorgänge sind nicht sofort überall sichtbar. Die folgenden Direktiven gelten für HTTP-Caches und konfigurieren den Anwendungscache nicht allein.
| HTTP-Antwortdirektive | Hauptbedeutung | Grenze |
|---|---|---|
| no-cache | Speicherung erlaubt, vor Wiederverwendung validieren. | Bedeutet nicht „nichts speichern“. |
| no-store | Diese Antwort nicht in Caches speichern. | Entfernt frühere Kopien nicht automatisch. |
| private | Keine Speicherung im gemeinsamen Cache. | Keine Authentifizierungsregel. |
| max-age | Frischelebensdauer einer Antwort. | Garantiert keine Konsistenz aller Daten. |
Die richtige Antwort für die richtige Person prüfen
- Definieren Sie Schlüsselvarianten für Ressource, Parameter, Sprache und Rechteumfang. Prüfen Sie, dass kein Konto private Antworten eines anderen erhält.
- Legen Sie Höchstalter, Invalidierung und Verhalten nach Änderung oder Löschung fest. Kurze TTL garantiert keine sofort konsistenten Lesezugriffe.
- Testen Sie gleichzeitiges Ablaufen, Cache- und Ursprungsausfall. Bündeln Sie Aktualisierungen bei Bedarf und liefern Sie veraltete Antworten nur bei fachlicher Zulässigkeit.
Mehr als die Trefferquote messen
Beobachten Sie Latenz, Fehler, Ursprungslast sowie falsche oder veraltete Antworten. Kontostände, reservierter Bestand und Rechte benötigen möglicherweise andere Garantien als ein öffentlicher Katalog. Ein schneller Cache darf keine unkontrollierte alternative Wahrheitsquelle werden.
Primärquellen
API-Caching muss Zugriffsentscheidungen beibehalten.
Ein Antwortcache kann eine fehlerhafte Abfrage beschleunigen, wenn Schlüssel die Berechtigungen des Anfragenden ignorieren. Das Risiko steigt, wenn ein Graph öffentliche und private Objekte kombiniert.
- Klassifizieren Sie öffentliche, private und rollenabhängige Felder vor dem Caching.
- Testen Sie eine Antwort unter einem Konto und fordern Sie sie unter einem anderen an.
- Ungültigmachen von Ergebnissen nach Berechtigungs- oder Datenänderungen.
Primärquelle: OWASP — GraphQL Cheat Sheet. Verwandte Methode: den praktischen Leitfaden lesen.
Neben Cachegeschwindigkeit auch Aktualität messen
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Zwei Lesezugriffe sind schnell, doch einer zeigt nach einer Änderung der Quelle noch die alte Verfügbarkeit.
- Wert, Version, Leseort und Zeit seit der Änderung vergleichen. Invalidierung, Ablauf und Zugriff auf die Quelle gemäß Systemvertrag testen.
- Zulässige Veralterung je Anwendung definieren und Abweichungen überwachen. Niedrigere Latenz belegt keine konsistenten Auslieferungsdaten.
Primärquelle: IETF — RFC 9111, HTTP Caching. Verwandte Methode: den praktischen Leitfaden lesen.
Verwaiste Subdomains: CNAME-Verweise kontrolliert entfernen
DNS-Namen mit kontrollierten Ressourcen verknüpfen und Abhängigkeiten vor der Freigabe auflösen.
- Erfasse Namen, CNAME-Kette, Anbieterressource und Verantwortliche. Gleiche DNS mit dem Inventar des berechtigten Kontos ab. HTTP-Fehler, NXDOMAIN oder fehlende Ressourcen verlangen Prüfung, beweisen aber keine Übernahmemöglichkeit. Schutzmechanismen unterscheiden sich je Anbieter.
- Entferne den Verweis oder leite ihn auf ein kontrolliertes Ziel, bevor die Ressource freigegeben wird. Berücksichtige frühere TTLs und Caches; prüfe autoritatives DNS und mehrere Resolver. Behalte noch erforderliche Eigentumsnachweise statt alle TXT-Einträge zu löschen.
- Prüfe Links, Weiterleitungen, OAuth-Rückrufe, Webhooks und Cookie-Domains. Ist die Ressource bereits freigegeben, korrigiere DNS und untersuche mögliche Exposition im Vorfallprozess. Gleiche nach jeder Löschung DNS und Ressourcen ab.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}Erwartete Entscheidung
Fiktives Beispiel: portal.example verweist auf eine gelöschte Ressource. Entferne den CNAME oder wähle ein kontrolliertes Ziel; die fehlende Ressource allein beweist keine Übernahme durch Dritte.
Beweist eine Fehlerseite die Übernehmbarkeit?
Nein. Ressourcenstatus und Reservierungs- oder Eigentumsprüfung des Anbieters müssen geklärt werden. Keine Ressource zur Risikodemonstration beanspruchen.
Primärquelle: Microsoft — Prevent dangling DNS entries. Verwandte Methode: den praktischen Leitfaden lesen.
ETag, HTTP-Cache und gleichzeitige Änderungen
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
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: Fehler, Listen und Teildaten
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
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