Dokumentation · Entwickler-Dokumentation

Bereinigung und Maskierung

Diese Seite beschreibt den Bereinigungs- und Maskierungsansatz des Plugins auf hoher Ebene. Interne Helper-Namen, Validierungs-Pipelines und genaue Maskierungsregeln sind Implementierungsdetails und werden hier nicht veröffentlicht.

Ansatz

Das Plugin folgt den Standard-Sicherheitsrichtlinien von WordPress:

  • Bereinigen bei der Eingabe (Sanitise on input). Jeder nicht vertrauenswürdige Wert wird vor der Speicherung oder Verwendung mit der für seinen Typ geeigneten WordPress-API bereinigt.
  • Maskieren bei der Ausgabe (Escape on output). Jeder dynamische Wert wird zum Zeitpunkt des Renderns mit der für seinen Kontext (HTML, Attribut, URL, JavaScript, JSON) geeigneten WordPress-Maskierungs-API maskiert.
  • Validieren, dann bereinigen, dann maskieren. Die Validierung weist Werte außerhalb des zulässigen Bereichs ab; die Bereinigung normalisiert die Form; die Maskierung schützt den Ausgabekontext.
  • Geheimnisse in Diagnosen maskieren. Diagnoseausgaben enthalten niemals Klartext-Geheimnisse, Token, Autorisierungs-Header oder Header für signierte Anfragen.

Für Entwickler, die das System erweitern

Wenn Sie Code schreiben, der in das Plugin integriert wird (benutzerdefinierte Templates, Theme-Overrides, Hook-Callbacks):

  • Behandeln Sie jeden Wert, der aus Anfrageparametern, Optionen, Post-Meta oder APIs von Drittanbietern stammt, als nicht vertrauenswürdig.
  • Verwenden Sie bei der Eingabe die WordPress-Bereinigungs-API (sanitize_text_field, sanitize_email, wp_kses_post, absint usw.).
  • Verwenden Sie am Punkt der Ausgabe die WordPress-Maskierungs-API (esc_html, esc_attr, esc_url, esc_js, wp_json_encode).
  • Geben Sie konfigurierte Geheimnisse oder Zugangsdaten niemals per Echo in gerenderten Ausgaben oder Protokollzeilen aus.

Unterstützte öffentliche Integrationsflächen

Wenn Sie eine Integration mit dem Plugin vornehmen, bevorzugen Sie diese stabilen Schnittstellen:

Interne Klassennamen, Optionsschlüssel, Datenbanktabellen, REST- und AJAX-Endpunkte, Cron-Hook-Namen, Berechtigungs- und Nonce-Identifikatoren sowie die Release- und Update-Infrastruktur werden als Implementierungsdetails behandelt. Sie können sich zwischen den Versionen ohne vorherige Ankündigung ändern und sind nicht Bestandteil des öffentlichen Integrationsvertrags.

Stabilitäts- und Änderungsrichtlinie

Alles, was oben nicht als unterstützte öffentliche Schnittstelle aufgeführt ist, gilt als internes Implementierungsdetail. Interne APIs, das Speicherlayout und Sicherheitsimplementierungen können sich zwischen den Versionen ändern. Verlassen Sie sich in Drittanbieter-Code, Themes oder externen Systemen nicht auf diese Details. Direkte Datenbankzugriffe werden nicht unterstützt.

Hinweis zur öffentlichen Dokumentation. Diese Seite bietet nur eine allgemeine Integrationsübersicht. Interne Implementierungsdetails, private APIs, Speicherinterna und sicherheitsrelevante Release-Infrastrukturen werden separat gepflegt und sind nicht Teil der öffentlichen Dokumentation. Unterstützte Integrationsschnittstellen sind die dokumentierten Shortcodes, Template-Overrides, die Einstellungs-Benutzeroberfläche und alle in diesem Abschnitt explizit veröffentlichten Erweiterungspunkte.