Der wöchentliche Security-Sweep der Kanzlei-Website

Würdigung — eine Website ist ein lebendes System#

Eine fertig gebaute Website fühlt sich an wie ein Produkt: Sie steht, sie funktioniert, sie ist abgenommen. Genauso wird sie oft verkauft — als einmalige Investition, danach „nur" gelegentliche Inhalts-Updates. Das Bild ist verständlich, aber strukturell falsch. Eine Website ist nicht ein Bild an der Wand; sie ist ein lebendes System, eingebettet in eine Infrastruktur, die sich permanent verändert: NPM-Pakete bekommen Sicherheits-Patches, Hosting-Plattformen ändern Default-Header, Browser verschärfen Pflicht-Standards, neue Compliance-Anforderungen erscheinen, Drittanbieter modifizieren ihre Verhaltensweise.

Wer eine Website ohne strukturierte Wartung betreibt, kumuliert stille Probleme. Sie sind selten dramatisch — meist klein, manchmal aber teuer. Die Frage ist nicht ob, sondern wann. Strukturelle Wartung verschiebt den Zeitpunkt der Entdeckung von „irgendwann" auf „nächsten Montag".

Drei Beispiele, die niemand auf der Rechnung hatte#

Drei reale Vorfälle aus den letzten zwei Jahren, an denen eine wartungs-fern betriebene Website still gelitten hat — ohne dass jemand eine Wartungsrechnung dafür bekommen hätte:

• Die xz-Utils-Backdoor (März 2024, CVE-2024-3094). Ein über Jahre gepflegtes Linux-Werkzeug, auf dem mittelbar fast jeder Web-Server der Welt aufsetzt, wurde von einem böswilligen Maintainer mit einer Backdoor versehen. Entdeckt wurde der Fund durch einen Microsoft-Entwickler, der bei der Performance-Analyse eines SSH-Tools eine merkwürdige CPU-Last bemerkte. Sites, deren Build-Pipelines die betroffene Version eingespielt hatten, brauchten innerhalb von Stunden ein Update. Ohne automatisierte Dependency-Routine wäre das Problem unbemerkt geblieben.
• Stille Default-Anpassungen bei Hosting-Plattformen. Anbieter wie VercelVercel · zum GlossarHosting-Plattform für moderne Web-Apps — Standard-Heimat für Next.js-Sites mit EU-Region. oder Netlify schärfen regelmäßig ihre Default-Konfigurationen nach — Cache-Control-Header, SameSite-Cookie-Defaults, CSP-Empfehlungen. Die Änderungen stehen im Changelog, aber niemand liest das wöchentlich. Effekte reichen von subtilen Caching-Problemen bis zu sichtbaren Layout-Veränderungen, je nach Site.
• Verschärfung von Bot-Detection bei CDN-Anbietern. CloudflareCloudflare · zum GlossarUS-Anbieter für CDN, WAF, DDoS-Schutz und Turnstile — Privacy-by-Design-Ausrichtung. und andere CDN-Betreiber justieren ihre Bot-Erkennungs-Regeln mehrmals pro Jahr. Ein automatisierter Sicherheits-Scanner, der gestern noch durchgelaufen ist, wird heute geblockt — und die eigene Site fällt dann aus der Routine-Prüfung raus, ohne dass der Site-Betreiber das bemerkt.

Keines dieser Ereignisse stand in einer Wartungsrechnung — aber sie alle hatten Auswirkungen, die jemand prüfen musste. Dieser „jemand" ist die strukturierte Wartung.

Stufe 1: Dependency-Check#

Die erste wöchentliche Prüfung schaut auf die Abhängigkeiten, von denen die Site lebt. Konkret läuft npm audit --omit=dev --json über die produktiv eingesetzten NPM-Pakete und meldet bekannte CVEs. Parallel werden alle Major-Updates der letzten 7 Tage aufgelistet — auch wenn keine Sicherheits-Lücke gemeldet ist, sind Major-Sprünge ein Grund zum Hinschauen.

Diese Stufe ist eine bewusste Dopplungs-Schicht zu Dependabot: Dependabot legt Pull-Requests für offene CVEs an, der Sweep prüft, ob diese PRs wirklich gemerged sind, und ob es Funde gibt, die Dependabot nicht erkennt (z. B. transitive Abhängigkeiten in Lock-Files). Belt-and-suspenders — die Kosten der Dopplung sind null, der Nutzen ist nachweislich.

Stufe 2: Security-Header-Check#

Die zweite Prüfung adressiert die Auslieferungs-Schicht: Welche Security-Header liefert die Site aktuell aus, und sind sie noch wie konfiguriert? Die Prüfung läuft zweistufig:

• Konfigurations-Soll aus next.config.ts einlesen und gegen den dort definierten Bestand abgleichen — fehlt ein Header, wird das gemeldet.
• Externes Live-Test als Empfehlung über securityheaders.com oder Mozilla Observatory — beide vergeben eine Note (A bis F), die unser Soll-Wert „mindestens A" sein soll.

Hier fängt die Routine die häufigsten Drifts: ein nachträglich eingefügter Header wurde im falschen Block deklariert; eine CSP-Direktive wurde versehentlich relaxed; ein Hosting-Default überschrieb eine eigene Regel. Alles selten dramatisch, aber konsistent zu finden.

Stufe 3: Code-Pattern-Scan#

Die dritte Prüfung schaut auf den Code selbst — nicht nach Bugs, sondern nach bekannten Risiko-Mustern. Pro Sweep läuft ein grep gegen das Repository nach:

• dangerouslySetInnerHTML — React-Setze für rohen HTML-Inhalt. Jeder Fund braucht eine Begründung im Code-Kommentar.
• eval(, new Function(, document.write( — JavaScript-Konstrukte, die fast nie ihre Verwendung in einem modernen Stack rechtfertigen.
• Hardcoded API-Keys in Pattern-Form: sk-, pk_live, AKIA, ghp_ und ähnliches. Selbst wenn der Key später in einer Env-Variable landet, hinterlässt ein versehentlicher Push einen Treffer in der Git-History.
• Server-Actions ohne Zod-Schema (oder ohne andere strikte Input-Validierung) — eine Server-Action ohne Validation ist eine offene Tür.

Die Scans laufen über grep/ripgrep mit fest definierten Regeln. False positives gibt es — sie werden im Sweep-Report als „erwartet, freigegeben" markiert. Was zählt, sind die echten neuen Treffer, die nicht in der Freigabe stehen.

Stufe 4: Compliance-Drift#

Die vierte Prüfung schaut auf die Konsistenz zwischen rechtlich/operativ deklarierten Aussagen und der echten technischen Realität:

• .env.example vs Code. Wenn der Code eine neue Env-Variable nutzt, sollte sie in der Beispiel-Datei als Platzhalter stehen. Sonst hat der nächste Onboarding-Lauf eine Lücke.
• Neue Tracker/CDN-Pattern. Per Pattern-Scan wird geprüft, ob neue Drittanbieter-Skripte oder CDN-Endpunkte aufgetaucht sind, die in der Datenschutzerklärung noch nicht stehen.
• DSE-Sub-Dienstleister vs reale Code-Aufrufe. Die Datenschutzerklärung benennt Sub-Dienstleister (z. B. Resend für Mail, Upstash für Rate-Limit). Wenn ein Code-Pfad einen weiteren Anbieter aufruft, der nicht in der DSEDSE · zum GlossarDatenschutzerklärung — die Pflicht-Information für Website-Besucher nach Art. 13 DSGVO. steht, ist das ein Compliance-Befund. Tiefer dazu: Soll-Ist-Drift bei der DSE.

Stufe 4 ist die operative Brücke zwischen Code und Rechtsdoku — die, die ohne strukturierte Prüfung am schnellsten aus dem Takt gerät.

Drei Quartals-Fragen für Kanzleien#

Eine Kanzlei-Site ist meist eine andere Sorte System als eine schnell-entwickelnde Web-App: niedrigere Änderungs-Frequenz, weniger Code-Bewegung, fokussiertes Funktions-Set. Für solche Sites verdichten sich die vier Sweep-Stufen sinnvoll zu drei Quartals-Fragen, die intern (oder im Quartals-Call mit dem Dienstleister) beantwortbar sein müssen:

1. Wann hat CMS/Page-Builder zuletzt ein Sicherheits-Update gefahren? Gibt es ein Plugin, das nicht mehr gepflegt wird (kein Update seit über 12 Monaten)? Antwort als Datum und Plugin-Name dokumentiert.
2. Liefert die Seite securityheaders.com mindestens Note A? Der Test dauert eine Minute, das Ergebnis ist eine objektive Schranke. Wenn die Note unter A liegt, ist eine Erklärung (oder ein Behebungs-Plan) Pflicht.
3. Stimmt die DSE noch mit den real eingesetzten Diensten überein? Konkret: Welche Drittanbieter werden im Quelltext gefunden? Steht jeder davon in der Datenschutzerklärung? Wenn nein: korrigieren — sonst ist die DSE veraltet und abmahnbar.

Diese drei Fragen sind weder vollständig (das ist die CI-Routine) noch ein Ersatz für eine professionelle Bewertung — aber sie sind das Minimum, das eine Kanzlei selbst (oder die hauseigene IT-Verantwortliche) quartalsweise prüfen kann.

Wie wir es bauen#

Bei jedem Mandanten-Boost-Projekt richten wir den wöchentlichen Sweep als Cloud-Routine ein — ein Cron-getriebener Job, der montags früh läuft und einen strukturierten Report per Mail liefert. Im fahoch2.de-Repo flankieren mehrere Skripte den Sweep operativ:

• scripts/check-go-live.mjs — Reality-Check der Go-Live-Checkliste vor jedem Briefing.
• scripts/lint-dse-consistency.mjs — DSE-Konsistenz-Linter als Drift-Sperre zwischen Datenschutz-Seite und Code-Referenzen.
• scripts/lint-voice.mjs — Voice-Linter inkl. gitcheckter Hash-Blocklist gegen interne Namen.
• .github/dependabot.yml — Dependabot mit Minor+Patch automatisch, Major manuell.
• .husky/pre-push — Test-Lauf vor jedem Push, als zweite Verteidigungs-Linie.

Die Cloud-Routine selbst läuft auf einer Cron-getriebenen Infrastruktur mit dem Eintrag „Montag 07:00 Berlin" und liefert einen einzelnen, scanbaren Sweep-Report ins Mail-Postfach. Im Ergebnis: eine Stunde pro Woche, keine Überraschung pro Quartal.

Für eine strukturierte Bewertung der Wartungs-Lage einer bestehenden Kanzlei-Site empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Eine Website ist kein Bild an der Wand — sie ist ein lebendes System, eingebettet in eine Infrastruktur, die sich permanent verändert. NPM-Pakete bekommen CVEs, Hosting-Plattformen ändern Default-Header, CDN-Anbieter verschärfen Bot-Detection — keines dieser Ereignisse steht in einer Wartungsrechnung, aber alle haben Auswirkungen. Auf fahoch2.de prüft ein wöchentlicher Security-Sweep vier Stufen: Dependencies (Doppel-Schicht zu Dependabot), Security-Header (Soll vs Live mit securityheaders.com als Schranke), Code-Pattern (grep nach Risiko-Mustern und hardcoded Keys), Compliance-Drift (DSE vs reale Code-Aufrufe). Für Kanzlei-Sites mit niedriger Änderungs-Frequenz verdichten sich die vier Stufen zu drei Quartals-Fragen: CMS-/Plugin-Update-Stand, securityheaders.com mindestens Note A, DSE-Drift. Das ist die strukturelle Antwort auf die Lüge „einmal gebaut, dann stabil" — und die Voraussetzung dafür, dass eine Kanzlei-Website über Jahre keine stillen Probleme akkumuliert.

Quellen#

• npm — npm audit Documentation — abgerufen 2026-06-07
• securityheaders.com — HTTP Security Headers Scanner — abgerufen 2026-06-07
• Mozilla Observatory — Web Security Scanner — abgerufen 2026-06-07
• Next.js — Server Actions and Mutations — abgerufen 2026-06-07
• BSI — Mindeststandards für die Informationssicherheit — abgerufen 2026-06-07
• OWASP — Top 10 Web Application Security Risks — abgerufen 2026-06-07
• NVD — CVE-2024-3094 (xz-utils Backdoor) — abgerufen 2026-06-07

Disclaimer: Beschreibung der operativen Sicherheits-Routine von fahoch2.de zum Zeitpunkt der Veröffentlichung. Dies ist keine erschöpfende Security-Beratung. Konkrete Sicherheits- und Compliance-Konzepte für Steuerkanzleien folgen § 203 StGB, § 4 BDSG und den GoBD — und gehören in die Abstimmung mit dem Datenschutzbeauftragten und ggf. der zuständigen Steuerberaterkammer.