Sicherheit einer Kanzlei-Website beginnt in der Architektur, nicht im Plugin.

Bevor irgendein Inhalt geladen wird, fragt der Browser nach Anweisungen vom Server: Welche Skripte sind erlaubt, welche Quellen darf die Site einbetten, wie wird mit Cookies umgegangen. Diese Anweisungen heißen HTTP-Security-Header — Content-Security-Policy (CSP), HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy. Sie sind die erste Schicht der Härtung und gleichzeitig die billigste, weil sie nur Konfiguration sind, kein Code.

Unter dem Selbstverständnis-Test securityheaders.com bekommt eine Standard-WordPress-Site ohne weitere Konfiguration meist Note F. Eine bewusst konfigurierte Site bekommt Note A. Der Unterschied ist eine Datei und ein erneutes Deployment — strukturell sehr asymmetrisch zwischen Aufwand und Wirkung.

Hinter den Browser-Headern liegt die Frage, wer überhaupt durchkommt. Automatisierte Schwachstellen-Scanner laufen kontinuierlich gegen jede öffentliche Website — viele davon mit dem Ziel, bekannte CMS-Lücken zu finden und auszunutzen. Eine vorgelagerte Schicht wie Cloudflare fängt einen großen Teil davon ab, bevor die Anfragen den eigentlichen Server erreichen.

Für Formulare gilt dasselbe Prinzip auf einer anderen Ebene: Statt Mandanten mit Google-reCAPTCHA-Aufgaben zu quälen, fängt ein serverseitiger Honeypot plus Rate-Limit die meisten Spam-Bots strukturell ab — DSGVO-freundlich, Nutzer-freundlich, und ohne Datenabfluss in die USA.

Die nachhaltigste Sicherheits-Entscheidung ist die Stack-Wahl. Jede WordPress-Site lebt mit einer wachsenden Plugin-Liste, von denen jedes einzelne fremder Code mit Datenbank-Zugriff im eigenen System ist. Eine bekannt gewordene CVE in einem populären Plugin wird von Bots automatisch gesucht — und ein nicht eingespieltes Update ist die wahrscheinlichste Einfallstür.

Eine statisch gerenderte Site hat dieses Problem strukturell nicht: kein CMS, keine Datenbank, keine Plugins, die veralten könnten. Die Angriffsfläche schrumpft auf das, was technisch nötig ist (das Kontaktformular über eine isolierte Server-Action), nicht auf das, was zufällig mit installiert wurde.

Einmal gebaut, dann stabil — das ist eine Lüge. NPM-Pakete bekommen CVEs, Hosting-Plattformen ändern Default-Header, Browser verschärfen Pflicht-Standards. Was diese Bewegung im Griff hält, ist kein einmaliger Audit, sondern eine wöchentliche Routine, die strukturierte Sweep-Checks gegen die Site fährt: Dependency-Stand, Header-Konfiguration, Code-Pattern-Scan, Compliance-Drift zwischen Datenschutzerklärung und realem Code.

Für Kanzlei-Sites mit niedriger Änderungs-Frequenz verdichtet sich das zu drei Quartals-Fragen: CMS-/Plugin-Update-Stand, securityheaders.com mindestens Note A, DSE-Drift gegen realen Stack. Diese drei Fragen ehrlich beantworten zu können, ist das Minimum operativer Sicherheits-Hygiene.