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.
Jede Admin-Aktion auf current_user_can() und die richtige Capability geprüft — nicht nur is_user_logged_in().
Jeder zustandsändernde Request auf eine gültige, aktionsgebundene Nonce geprüft. Leicht zu vergessen; häufige Ursache von CSRF-zu-RCE-Ketten.
Sanitisierung und Validierung jeder Nutzereingabe — nicht nur beim Speichern, sondern auf jeder Ebene (REST, AJAX, Shortcode, Block, CLI-Befehl).
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.
Durchgehend Prepared Statements. Keine String-Konkatenation in $wpdb->query(). $wpdb->prepare() mit den richtigen Format-Spezifizierern.
Upload-Handler, File-Deletes, File-Reads — alles auf Path-Traversal, Typprüfung und Ausführungsverhinderung in Upload-Verzeichnissen geprüft.
Nutzungen von eval, unserialize, system, exec, preg_replace /e, extract — markiert und im Kontext geprüft.
Eigene Login-Logik, Passwort-Reset, OAuth, API-Token-Handling — sobald das Plugin Identität bewegt, schauen wir genau hin.
Mitgelieferte Bibliotheken (jQuery, Composer-Pakete, npm-Builds) auf bekannt verwundbare Versionen und Forks von Upstream-Code geprüft.
Jeder ausgehende HTTP-Request geprüft — was gesendet wird, wohin und ob der Response blind vertraut wird.
Wenn sich das Plugin aus einer Nicht-WordPress.org-Quelle selbst aktualisiert, wird die Integrität des Update-Kanals durchgängig geprüft.
Trennung Network-Admin vs. Site-Admin, Super-Admin-Escalation-Pfade, rollen-eingeschränkte Aktionen im gesamten Netzwerk.
So funktioniert es
How the audit runs.
- Schritt 1
Code-Übergabe
Quelle (zip, git oder Commit-Pin) mit Build-Kontext.
- Schritt 2
Weiterlesen
Zeilenweise Prüfung. Befunde mit file:line-Referenzen.
- Schritt 3
Dynamische Prüfung
Vielversprechende Befunde auf einer echten Installation bestätigt.
- 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.
Quoted
Bis zu ~3.000 PHP-Zeilen
Plugin oder Theme für einen Zweck. Beispiele: Formular-Handler, Custom Post Type, leichtgewichtige Integration.
BesprechenQuoted
Bis zu ~10.000 Zeilen
Plugin mit mehreren Features oder ein komplettes Custom-Theme. Inklusive Review der JS-/Asset-Pipeline.
BesprechenIndividuell
10.000+ Zeilen
Großes Plugin (WooCommerce-Extension, Mehrsprachen-Layer), plattformartige Codebasis oder alles mit komplexem Update-Kanal und Lizenz-Schicht.
BesprechenHä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.