WordPress Cache-Sicherheit: Kundendaten privat halten

Ein Kunde öffnet eine Kontoseite und sieht den Namen von jemand anderem. Die Anmeldung funktioniert möglicherweise wie vorgesehen. Ein gemeinsam genutzter Cache hat möglicherweise die falsche Seite gespeichert und an den nächsten Besucher gesendet.

Caching macht WordPress durch die Wiederverwendung von Arbeit schneller. Aber eine für eine Person erstellte Seite benötigt andere Regeln als ein öffentlicher Blogbeitrag. Dieser Leitfaden zeigt, wie Sie diese Grenze überprüfen können, ohne jede Geschwindigkeitsfunktion zu deaktivieren.

Ordnen Sie die Caches zu, die Ihre Site verwendet

Beginnen Sie mit dem Browser, dann dem CDN, dem Hosting-Cache, dem Seiten-Cache-Plugin und dem Objekt-Cache. Ein CDN ist ein Netzwerk, das Inhalte in der Nähe von Besuchern bereitstellt. Ein Objektcache speichert von der App verwendete Daten; es ist nicht dasselbe wie eine gespeicherte ganze Seite.

Schreiben Sie auf, wem jede Ebene gehört. Zwei Tools können für sich genommen korrekt aussehen, während eine allgemeine Regel die andere außer Kraft setzt. Die Regel „Alles zwischenspeichern“ sollte in einem Shop oder auf einer Mitgliederseite genau überprüft werden.

Unser WordPress Geschwindigkeitsführer deckt die Leistungsseite ab. Fügen Sie derselben Arbeit eine Datenschutzprüfung hinzu, damit Geschwindigkeitsgewinne kein Datenleck verbergen.

Legen Sie fest, welche Antworten privat bleiben müssen

Listen Sie Seiten auf, auf denen Namen, Bestellungen, Adressen, private Downloads, Kontodetails oder benutzerdefinierte Preise angezeigt werden. Schließen Sie die API-Aufrufe ein, die diese Daten laden, nachdem die Seite geöffnet wurde.

Warenkorb-, Kassen- und Kontoseiten erfordern oft Regeln zur Umgehung des Shared-Caches. Das gilt auch für authentifizierte Antworten und Seiten, die von einer privaten Sitzung abhängen. Überprüfen Sie die tatsächlichen Routen, die von Ihren Plugins verwendet werden; eine benutzerdefinierte Kontoseite hat möglicherweise eine andere URL.

Eine öffentliche Seite kann dennoch ein privates Widget laden. Beispielsweise kann das Seitengerüst sicher zu cachen sein, während dies für die Bestellübersicht nicht gilt. Untersuchen Sie die Antwort, die die privaten Daten enthält, nicht nur die Adressleiste.

Nutzen Sie unsere WooCommerce Sicherheitscheckliste um Konto- und Checkout-Abläufe in die Überprüfung einzubeziehen.

Verstehen Sie drei nützliche Cache-Anweisungen

Der Cache-Control-Header teilt kompatiblen Caches mit, wie sie mit einer Antwort umgehen sollen. „Privat“ schließt gemeinsame Caches aus, kann aber einen Browser-Cache zulassen. „No-store“ weist Caches an, die Antwort nicht aufzubewahren. „No-Cache“ ermöglicht die Speicherung, erfordert jedoch eine Validierung vor der Wiederverwendung. Es bedeutet nicht „das niemals speichern“.

Diese Bedeutungen und anbieterspezifischen Verhaltensweisen sind in dokumentiert Cache-Control-Leitfaden von Cloudflare. Überprüfen Sie auch die Regeln Ihres Hosts und CDN. Ein Header allein ist kein Beweis dafür, was der gesamte Stack tut.

Verwenden Sie für sensible Seiten eine bewusste Richtlinie sowohl für Browser- als auch für Shared-Caches. Testen Sie dann die Antwort. Behalten Sie Authentifizierungsprüfungen bei: Cache-Header können nicht entscheiden, wer eine Bestellung einsehen darf.

Führen Sie einen Test mit zwei Konten durch

Erstellen Sie zwei Testkunden mit deutlich unterschiedlichen Platzhalterdaten. Verwenden Sie separate Browser-Profile, damit die Cookies getrennt bleiben. Ein drittes Profil sollte abgemeldet bleiben.

• Melden Sie sich als Kunde A an und öffnen Sie die Kontoseite mehrmals.
• Öffnen Sie die gleiche Route wie Kunde B und vergleichen Sie das Ergebnis.
• Fordern Sie die Route an, während Sie abgemeldet sind.
• Wiederholen Sie diesen Vorgang nach dem Löschen des Caches und noch einmal, nachdem der Cache aufgewärmt ist.
• Überprüfen Sie sowohl die sichtbare Seite als auch die Netzwerkanworten, die sie füllen.

Zwischen diesen Sitzungen dürfen sich keine privaten Namen, Bestellungen oder Adressen kreuzen. Wiederholen Sie den Vorgang mit einem Warenkorb, einem abgelaufenen Login und einem passwortgeschützten Download. Verwenden Sie Testaufträge, keine echten Kundendatensätze.

Unser Leitfaden zur Sitzungssicherheit erklärt hier, warum Cookies und Abmeldeverhalten wichtig sind.

Überprüfen Sie, was der Cache tatsächlich ausgeliefert hat

Bitten Sie Ihren Entwickler, Antwort-Header und den Cache-Status zu überprüfen. Ein unerwarteter Cache-Hit bei einer privaten Antwort muss untersucht werden. Ein Cache-Miss reicht nicht als Beweis für die Sicherheit aus; die nächste Anfrage könnte ein Hit sein.

Testen Sie mit demselben CDN und Hosting-Setup wie die Live-Site. Wenn das Staging kein CDN hat, decken die Ergebnisse Edge-Caching nicht ab. Enthalten Inszenierungssicherungen und ein kleiner, kontrollierter Live-Check.

Notieren Sie die Route, den Benutzerstatus, das erwartete Verhalten und das Ergebnis. Wiederholen Sie diese Prüfungen nach einer Cache-Plugin-Änderung, einer neuen Mitgliedschaftsfunktion oder einem Hosting-Umzug.

Was tun, wenn Daten offengelegt werden?

Stoppen Sie das gemeinsame Caching auf den betroffenen Routen und löschen Sie gespeicherte Antworten auf jeder relevanten Ebene. Bewahren Sie genügend Beweise auf, um zu verstehen, welche Daten wann bereitgestellt wurden. Korrigieren Sie die Regel, testen Sie sie erneut und beurteilen Sie, wer möglicherweise betroffen ist.

Das Ändern eines Headers entfernt bereits anderswo gespeicherte alte Kopien nicht zuverlässig. Befolgen Sie die Schritte in unserem Leitfaden zur Reaktion auf Vorfälle wenn es sich um Kundendaten handelt.

Öffentliche Beiträge und statische Assets können weiterhin vom Caching profitieren. Für Hilfe bei der Überprüfung der Grenze steht Ihnen unser zur Verfügung Geschwindigkeitsoptimierungsdienst kann neben dem Verhalten auf privaten Seiten auch die Leistung überprüfen.

Häufig gestellte Fragen

Sollte ich das gesamte Caching in einem WordPress-Shop deaktivieren?

Normalerweise nein. Öffentliche Inhalte und statische Assets können weiterhin zwischengespeichert werden. Überprüfen Sie private Seiten, Sitzungen und API-Antworten separat.

Verhindert no-cache, dass eine Seite gespeichert wird?

Nein. Die Speicherung ist zwar möglich, erfordert jedoch vor der Wiederverwendung eine Validierung. No-Store ist die Richtlinie, die zur Verhinderung der Speicherung verwendet wird.

Reicht ein abgemeldeter Browser aus, um die Cache-Privatsphäre zu testen?

Nein. Testen Sie zwei separate Benutzerkonten und eine abgemeldete Sitzung. Überprüfen Sie sowohl den kalten als auch den warmen Cache-Status.

Behebt das Bereinigen des Caches eine fehlerhafte Regel?

Nein. Bei einer Bereinigung werden gespeicherte Kopien entfernt, aber dieselbe Regel kann private Daten erneut speichern. Korrigieren Sie die Richtlinie und testen Sie sie erneut.