Warum unsere Websites architektonisch sicher sind – und WordPress nicht. Für Besucher gibt es keinen Server, keine Datenbank, keinen ausführbaren Code. Redakteure arbeiten über einen geschützten Login – aber die öffentliche Website bleibt unangreifbar.
Allein 2025 wurden 11.334 neue Sicherheitslücken im WordPress-Ökosystem entdeckt – ein Anstieg von 42 % gegenüber dem Vorjahr. Aber das Problem betrifft jedes CMS mit PHP-/DB-Architektur: WordPress, Joomla, Drupal, TYPO3.
Jedes traditionelle CMS hat eine Datenbank, die direkt mit dem Internet verbunden ist. Ein SQL-Injection-Angriff reicht.
Jeder Request wird serverseitig verarbeitet. Code-Execution ist möglich – der Albtraum jedes Sicherheitsexperten.
96 % aller WordPress-Schwachstellen stammen aus Plugins. Die Hälfte aller kritischen Lücken wird innerhalb von 24 Stunden ausgenutzt.
Jeder weiß, wo man angreifen muss. Brute-Force-Attacken sind Alltag – bei WordPress, Joomla und Drupal gleichermaßen.
Viele Unternehmen bemerken einen Hack erst nach Wochen – wenn Google die Seite bereits als „gefährlich“ markiert hat.
Statt eine Festung zu bauen und zu hoffen, dass die Mauern halten, haben wir die Festung überflüssig gemacht.
„Für Besucher hat die Live-Website keinen Server, keine Datenbank und keinen ausführbaren Code. Redakteure arbeiten über einen geschützten Login – aber die öffentliche Auslieferung bleibt unangreifbar."
React + TypeScript, Admin-Backend, Datenbank, Auth-System, Edge Functions. Redakteure loggen sich über einen individuell definierten, nicht erratbaren Pfad ein – kein /wp-admin, kein /login, sondern eine URL, die nur das Team kennt.
GitHub Repository – versioniert, Code-Review, Audit-Trail. Kein FTP, kein SSH, keine Remote-Verbindung.
Für Besucher: nur statisches HTML/CSS/JS. Kein PHP, keine öffentliche Datenbank, kein öffentliches Login. Redakteure erreichen das Backend über einen authentifizierten Zugang.
| Angriffsvektor | Traditionelles CMS | Zero Attack Surface |
|---|---|---|
| SQL Injection | Möglich (DB erreichbar) | Unmöglich (keine DB) |
| Cross-Site Scripting | Möglich (PHP rendert HTML) | Unmöglich (statisches HTML) |
| Brute-Force Login | /wp-admin öffentlich | Kein öffentliches Login (Redakteurs-Login geschützt & nicht auffindbar) |
| Plugin-Exploits | 60.000+ Angriffsflächen | Unmöglich (kein Plugin-System) |
| DDoS | Server überlastbar | Minimal (statische Files, CDN-fähig) |
| Malware-Injection | Code ausführbar | Unmöglich (kein ausführbarer Code) |
| Zero-Day Exploits | PHP/MySQL Updates nötig | Irrelevant (kein Server-Code) |
Die Login-URL ist frei wählbar und wird nur einmalig an das Redaktionsteam kommuniziert. Bots, die nach /wp-admin oder /login scannen, laufen ins Leere. In Kombination mit starkem Passwort und rollenbasiertem Zugriff entsteht ein mehrschichtiger Schutz.
Änderungen durchlaufen einen kontrollierten Prozess: Code wird in GitHub committed, automatisch zu HTML kompiliert und deployed.
Was auf dem Live-Server liegt: fertige HTML-Seiten, optimierte Bilder, CSS. Keine Passwörter, keine Kundendaten, keine DB-Zugänge.
Für Kontaktformulare und Newsletter nutzen wir isolierte, serverlose Edge Functions: kein dauerhaft laufender Server, sandboxed, kein Dateisystem-Zugriff, automatisch gepatcht.
So verändert sich die Sicherheitslage, wenn eine Website von einem traditionellen CMS auf die Zero Attack Surface Architektur migriert wird.
11.334
neue WP-Schwachstellen 2025
96%
davon aus Plugins
<24h
bis zum ersten Exploit
0
davon relevant für sp8 CMS
Wo ein Hack Reputationsschaden bedeutet
Hoher Traffic = hohes Angriffsziel
Wo Compliance (DSGVO, ISO 27001) zählt
Die keine eigene Security-Abteilung haben
In einem 30-minütigen Gespräch zeigen wir Ihnen, wie verwundbar Ihre aktuelle Website ist – und wie eine Migration konkret aussehen würde.