threatover Patrik Grobshäuser
Code-Review

Plugin & theme audit.

A manual source-code security review of a WordPress plugin or theme.

Festpreis pro Codebasis

Was wir damit tun

Static source review.

Wir bekommen eine Kopie deines Plugin- oder Theme-Quellcodes und lesen ihn. Funktion für Funktion. Endpoint für Endpoint. Wir suchen nach den Mustern, die sechs Monate später zu Kompromittierungen werden — denen, die Linter und Scanner übersehen, weil es um Absicht geht, nicht um Syntax.

Anschließend schreiben wir auf, was wir gefunden haben, wie sich jedes Problem reproduzieren lässt und wie es sich beheben lässt, ohne das umgebende Feature zu brechen.

Wer das bucht

  • Plugin-Autoren, die eine Einreichung beim WordPress.org-Repo oder einem kostenpflichtigen Marketplace vorbereiten.
  • Entwickler, die eine Custom-Integration an einen bestimmten Kunden ausliefern, der ein Audit verlangt hat.
  • Seitenbetreiber, die ein Custom-Plugin oder -Theme geerbt haben und ihm nicht trauen.
  • Agenturen, die ein Plugin übernehmen und vor der Unterschrift Due Diligence auf die Codebasis wollen.

Abdeckung

Beispiele, wonach wir suchen.

Capability-Prüfungen

Jede Admin-Aktion auf current_user_can() und die richtige Capability geprüft — nicht nur is_user_logged_in().

Nonces & CSRF

Jeder zustandsändernde Request auf eine gültige, aktionsgebundene Nonce geprüft. Leicht zu vergessen; häufige Ursache von CSRF-zu-RCE-Ketten.

Eingabe-Handling

Sanitisierung und Validierung jeder Nutzereingabe — nicht nur beim Speichern, sondern auf jeder Ebene (REST, AJAX, Shortcode, Block, CLI-Befehl).

Output-Escaping

Jedes echo / printf / Template-Variable in den richtigen Escaper gepackt (esc_html, esc_attr, esc_url, wp_kses). Reflected XSS ist immer noch der häufigste WordPress-Befund.

Datenbankzugriff

Durchgehend Prepared Statements. Keine String-Konkatenation in $wpdb->query(). $wpdb->prepare() mit den richtigen Format-Spezifizierern.

Dateioperationen

Upload-Handler, File-Deletes, File-Reads — alles auf Path-Traversal, Typprüfung und Ausführungsverhinderung in Upload-Verzeichnissen geprüft.

Gefährliche Funktionen

Nutzungen von eval, unserialize, system, exec, preg_replace /e, extract — markiert und im Kontext geprüft.

Berechtigung

Eigene Login-Logik, Passwort-Reset, OAuth, API-Token-Handling — sobald das Plugin Identität bewegt, schauen wir genau hin.

Abhängigkeiten

Mitgelieferte Bibliotheken (jQuery, Composer-Pakete, npm-Builds) auf bekannt verwundbare Versionen und Forks von Upstream-Code geprüft.

Telemetrie & Egress

Jeder ausgehende HTTP-Request geprüft — was gesendet wird, wohin und ob der Response blind vertraut wird.

Update-Kanal

Wenn sich das Plugin aus einer Nicht-WordPress.org-Quelle selbst aktualisiert, wird die Integrität des Update-Kanals durchgängig geprüft.

Multisite & Rollen

Trennung Network-Admin vs. Site-Admin, Super-Admin-Escalation-Pfade, rollen-eingeschränkte Aktionen im gesamten Netzwerk.

So funktioniert es

How the audit runs.

  1. Schritt 1

    Code-Übergabe

    Quelle (zip, git oder Commit-Pin) mit Build-Kontext.

  2. Schritt 2

    Weiterlesen

    Zeilenweise Prüfung. Befunde mit file:line-Referenzen.

  3. Schritt 3

    Dynamische Prüfung

    Vielversprechende Befunde auf einer echten Installation bestätigt.

  4. Schritt 4

    Bericht & Debriefing

    Bericht, Walk-Through und ein Nachtest.

Preise

Pro Codebasis, Festpreis.

Vorab angeboten nach Größe und Komplexität. Die Zahlen unten sind typische Startpunkte; nach Sichtung des Codes senden wir einen Festpreis.

Klein

Quoted

Bis zu ~3.000 PHP-Zeilen

Plugin oder Theme für einen Zweck. Beispiele: Formular-Handler, Custom Post Type, leichtgewichtige Integration.

Besprechen
Groß

Individuell

10.000+ Zeilen

Großes Plugin (WooCommerce-Extension, Mehrsprachen-Layer), plattformartige Codebasis oder alles mit komplexem Update-Kanal und Lizenz-Schicht.

Besprechen

Häufig gefragt

Häufige Fragen.

Ist das nur ein Scanner-Lauf?

Nein. Scanner sind Teil des Workflows (wir nutzen sie für schnelle Triage), aber jeder Befund im Bericht wurde von einem Menschen im Kontext gelesen. Scanner liefern False Positives — wir nicht.

Unterzeichnet ihr eine NDA, bevor wir Code schicken?

Ja. Wir haben eine Standard-Mutual-NDA und nutzen auf Wunsch gerne deine. Code wird am Ende des Auftrags plus 30 Tage für Nachtest-Zwecke gelöscht.

Prüft ihr auch JavaScript- und Asset-Code?

Ja, für sicherheitsrelevantes JS — Admin-UI-Skripte, Gutenberg-Blöcke, Asset-Upload-Handler. Frontend-Code prüfen wir nicht auf nicht-sicherheitsrelevante Bugs.

Stellt ihr eine Bestätigung für die Marketplace-Einreichung aus?

Wir können eine Audit-Bestätigung ausstellen, die für Marketplaces geeignet ist, die das verlangen. Wir bescheinigen nicht, dass eine Codebasis null Bugs hat — niemand Ehrliches tut das.

E-Mail [email protected] or use the contact form.