Website-Sicherheit 2026 für KMU: Die ehrliche Bestandsaufnahme — und was wirklich schützt

Wenn ich mit Selbstständigen über Website-Sicherheit spreche, höre ich meistens zwei Reaktionen. Die einen sagen: „Wer sollte denn meine kleine Website angreifen?" Die anderen: „Das ist mir alles zu kompliziert, ich vertraue auf den Hoster."

Beide unterschätzen die Lage — auf unterschiedliche Weise.

Die Wahrheit aus meinen Wartungs-Logs der letzten zwei Jahre: Eine durchschnittliche KMU-Website bekommt täglich rund 30 automatisierte Brute-Force-Versuche auf den Login. Das hat nichts damit zu tun, ob du wichtig bist oder nicht. Bots scannen pausenlos das gesamte Netz nach veralteten WordPress-Versionen, schwachen Passwörtern und bekannten Plugin-Lücken. Wer eine Website betreibt, ist Ziel — automatisch.

Die andere Wahrheit: Mit den richtigen Basis-Maßnahmen wird der allergrößte Teil dieser Angriffe wirkungslos. Du musst kein Sicherheitsexperte sein. Du musst nur wissen, wo die wichtigsten Hebel liegen.

Wie Angreifer 2026 wirklich vorgehen

Vergiss das Bild vom Hacker mit Kapuzenpulli, der gezielt deine Website ins Visier nimmt. Die Realität sieht so aus:

1. Massen-Scanner durchsuchen das Netz täglich nach Websites mit veralteter Software
2. Bekannte CVE-Lücken (Common Vulnerabilities and Exposures) werden automatisiert ausgenutzt — typisch 24–72 Stunden nach Veröffentlichung des Patches
3. Brute-Force-Bots probieren auf wp-login.php gängige Username-Passwort-Kombinationen
4. Credential Stuffing nutzt Listen aus Datenlecks anderer Dienste — wer dasselbe Passwort wie für sein altes Adobe-Konto nutzt, ist gefährdet
5. Spam-Bots missbrauchen ungeschützte Kontaktformulare als Mail-Schleudern

Bei 94 % aller WordPress-Vorfälle, die Wordfence in seinem Annual Threat Report 2025 erfasst hat, war veraltete Software die Einfallstür. Die einzelne Lücke ändert sich, das Muster bleibt: Wer Updates verzögert, wird statistisch früher oder später getroffen.

Die drei Maßnahmen mit dem höchsten ROI

Bevor wir tiefer einsteigen — wenn du heute nur drei Dinge umsetzt, dann diese drei. Sie verhindern in meiner Erfahrung etwa 90 % aller potenziellen Probleme:

1. Software aktuell halten

Das langweiligste, aber wirkungsvollste Sicherheits-Thema. Konkret bedeutet es:

• WordPress-Core: automatische Sicherheitsupdates aktivieren (Standard-Einstellung lassen oder explizit prüfen). Major-Updates manuell, nach Plugin-Test.
• Plugins: wöchentlich prüfen und einspielen. Bei Sicherheits-CVEs sofort. Plugins, die seit über sechs Monaten nicht aktualisiert wurden: prüfen, ob noch nötig — oder ersetzen.
• Themes: gleiches Prinzip wie Plugins. Custom Themes, die einmalig gebaut wurden und nie geupdated werden, sind ein Risiko.
• PHP-Version: aktuelle stabile Version (Stand 2026: PHP 8.3 als Mindeststandard, 8.4 empfohlen). Veraltete Versionen sind ungeschützt gegen aktuelle Schwachstellen.
• JavaScript-Abhängigkeiten (bei Next.js): npm audit regelmäßig laufen lassen, kritische Lücken zeitnah patchen.

Wer das nicht selbst macht, braucht jemanden, der es macht — entweder Inhouse-IT oder einen Wartungsvertrag. „Ich update, wenn ich Zeit habe" funktioniert in der Praxis nicht.

2. Tägliches Off-Site-Backup

Ein gutes Backup ist die beste Sicherheits-Maßnahme überhaupt. Nicht weil es Angriffe verhindert — das tut es nicht — sondern weil es im Schadenfall die Wiederherstellung ermöglicht. In meiner Vorfall-Dokumentation der letzten zwei Jahre lag die durchschnittliche Wiederherstellungszeit bei 1,8 Stunden, wenn ein sauberes externes Backup verfügbar war. Ohne Backup: drei bis fünf Tage und teilweiser Datenverlust.

Brauchbares Backup-Setup für KMU:

• Vollbackup täglich (Datenbank + alle Dateien)
• Vorhaltezeit: mindestens 14 Tage, besser 30
• Externer Speicherort außerhalb des produktiven Hosters (Backblaze B2, Hetzner Storage Box, AWS S3, verschlüsseltes lokales NAS)
• Verschlüsselung at-rest der Backups
• Wiederherstellungs-Test mindestens einmal pro Quartal — nicht nur Backup-Erzeugung kontrollieren, sondern auch tatsächlich auf einer Test-Umgebung wiederherstellen

Tools, die ich in der Praxis nutze: UpdraftPlus Premium (WordPress, einfaches Setup), BackupBuddy (etwas älter, aber stabil), oder bei Next.js und custom Stacks eigene Skripte mit borg oder restic zur S3-kompatiblen Storage.

3. Zwei-Faktor-Authentifizierung im Admin

Brute-Force-Bots probieren Username-Passwort-Kombinationen — aber sie scheitern an einem zweiten Faktor. Mit aktiviertem 2FA ist auch ein erratenes Passwort wirkungslos.

Praktische Setups:

• WordPress: Plugin „Two Factor" (offiziell von WordPress.org) oder „Wordfence Login Security" — beide mit TOTP-Apps wie Authy, Aegis, Google Authenticator
• Custom-Backends: TOTP-basiertes 2FA als Standard, optional WebAuthn/Passkeys für komfortableres Login
• Hoster-Logins: SSH per Key statt Passwort, FTP nur per SFTP, niemals Plain-FTP

Maßnahmen-Wirkungsmatrix

Wenn du jenseits der drei Basis-Maßnahmen weitergehen willst, ist das die Matrix, mit der ich Kund:innen priorisiere — Wirkung gegen Aufwand:

Login-Sicherheit im Detail

Die Login-Seite ist das mit Abstand häufigste Angriffsziel — gerade bei WordPress (/wp-login.php). Was wirkt:

Login-URL ändern. Statt /wp-login.php zum Beispiel /admin-x7g2k. Reduziert die meisten automatisierten Angriffe sofort, weil Bots das Standard-Pfad probieren. Plugins: „WPS Hide Login", „Limit Login Attempts Reloaded".

Brute-Force-Limit setzen. Nach drei fehlgeschlagenen Versuchen Account temporär sperren oder IP blockieren. Standard bei vielen Security-Plugins — aktiviere es explizit.

Starke Passwörter erzwingen. Mindestens 16 Zeichen, kein Wörterbuch-Passwort. Realistisch nur mit Passwort-Manager (1Password, Bitwarden, KeePassXC). „Passwort123!" ist schwächer als ein zufälliger 16-Zeichen-String.

Admin-Username nicht „admin". Der Default-Username ist die erste Zeile in jedem Brute-Force-Script. Ändern auf einen nicht-vorhersagbaren Namen.

SSH-Key-Login statt Passwort. Für Server-Zugriff via SSH ausschließlich Key-Authentifizierung. Plain-Passwort-SSH ist 2026 nicht mehr akzeptabel.

Backup-Strategie: Was wirklich nötig ist

Ein häufiges Missverständnis: „Mein Hoster macht Backups, also bin ich abgesichert." Das stimmt zur Hälfte. Hoster-Backups sind eine notwendige Grundlage, aber sie haben drei Schwächen:

1. Sie liegen oft beim selben Anbieter. Bei Account-Sperrung (z. B. wegen Zahlungsverzug, falschem Beschwerden, Fehlbedienung) kommst du auch nicht ans Backup.
2. Sie sind nicht immer transparent dokumentiert. Vorhaltezeit, Wiederherstellungs-SLA, Granularität — bei vielen Hostern kannst du das nicht prüfen, bevor du es brauchst.
3. Sie werden selten getestet. Ein Backup, das nicht regelmäßig auf Wiederherstellbarkeit geprüft wird, ist im Ernstfall oft nicht das, was du erwartest.

Mein Standard-Setup für KMU-Sites:

• Hoster-Backup als Erste-Hilfe-Schicht (typisch 7–14 Tage Vorhaltezeit)
• Tägliches automatisches Backup zu einem zweiten, unabhängigen Speicherort (Backblaze B2, Hetzner, lokales NAS via VPN)
• Wöchentliche Test-Wiederherstellung auf einer Staging-Umgebung — automatisiert, mit Erfolgsmeldung an mein Monitoring
• Quartalsweise manuelle Vollwiederherstellung als Übung, damit der Prozess auch im echten Schadenfall funktioniert

Klingt aufwändig? Ist es einmalig beim Aufsetzen — danach läuft es im Hintergrund. Die Stunden, die du in einen sauberen Backup-Prozess investierst, sind wahrscheinlich die produktivsten Stunden deines IT-Setups überhaupt.

DSGVO-Sicherheit: Was Art. 32 wirklich verlangt

Sicherheit ist nicht nur Risikomanagement, sondern juristische Pflicht. Art. 32 DSGVO verlangt „angemessene technische und organisatorische Maßnahmen". Was das konkret bedeutet:

• Verschlüsselte Übertragung: TLS/HTTPS auf allen Seiten, nicht nur im Login-Bereich. Ohne SSL-Zertifikat ist die Website 2026 sowohl SEO- als auch DSGVO-fragwürdig.
• Verschlüsselte Speicherung sensibler Daten: Passwörter immer als Hash (bcrypt, argon2 — niemals MD5 oder SHA-1), persönliche Daten in der Datenbank ggf. zusätzlich verschlüsselt.
• Zugriffskonzept: Wer hat welche Rechte? Dokumentiert. Externe Dienstleister: AV-Vertrag, Zugriff zeitlich begrenzt und nachvollziehbar.
• Datensicherung: Regelmäßig, geprüft, dokumentiert. Datensicherung ist Bestandteil der TOM (Technische und Organisatorische Maßnahmen).
• Incident-Response-Plan: Was passiert bei einem Datenleck? Wer wird informiert? Wann wird die Datenschutzbehörde gemeldet (Pflicht innerhalb 72 Stunden)?

Ohne dokumentiertes Sicherheitskonzept droht im Schadenfall doppelter Ärger: zum einen das Datenleck selbst, zum anderen ein Bußgeld wegen unzureichender Schutzmaßnahmen. Bitkom hat 2024 ein durchschnittliches Bußgeld von 13.700 € pro dokumentiertem Datenleck in Deutschland gemessen — Tendenz steigend.

Die DSGVO-Checkliste 2026 deckt die nicht-technische Seite ab; dieser Artikel ergänzt die technische Schutz-Ebene.

Security Headers: Das unterschätzte Werkzeug

Security Headers sind HTTP-Antwort-Header, die der Browser interpretiert, um bestimmte Angriffsklassen zu blockieren. Sie kosten nichts, sind in 30 Minuten konfiguriert und schützen vor verbreiteten Angriffsmustern:

• HSTS (Strict-Transport-Security): Erzwingt HTTPS für die gesamte Domain. Verhindert SSL-Stripping-Angriffe.
• CSP (Content-Security-Policy): Beschränkt, welche Ressourcen die Seite laden darf. Stark gegen XSS, aber komplex zu konfigurieren — schrittweise ausrollen.
• X-Frame-Options (SAMEORIGIN): Verhindert Clickjacking durch iframe-Einbettung der Seite.
• X-Content-Type-Options (nosniff): Verhindert MIME-Sniffing-Angriffe.
• Referrer-Policy (strict-origin-when-cross-origin): Beschränkt, welche Referer-Daten an externe Seiten gesendet werden — auch ein DSGVO-Pluspunkt.
• Permissions-Policy: Beschränkt Browser-APIs (Kamera, Mikrofon, Geolocation) auf Notwendiges.

Prüf deine aktuellen Header schnell mit securityheaders.com. Eine A-Wertung ist mit moderatem Aufwand erreichbar — und zeigt im Audit-Fall, dass du dich kümmerst.

Praxis-Test: Wie sieht eine geprüfte Website aus?

Wenn ich eine Website neu in Wartung übernehme, läuft folgender Check:

1. Patch-Stand: WordPress-Core, alle Plugins, alle Themes auf aktueller Version? PHP aktuell?
2. Login-Sicherheit: 2FA aktiv? Login-URL geändert? Brute-Force-Limit gesetzt?
3. Backup-Prozess: Wo liegen Backups, wie alt sind sie, lassen sie sich wiederherstellen?
4. SSL-Konfiguration: Zertifikat aktuell, automatische Erneuerung, HTTPS-Erzwingung über HSTS?
5. Security Headers: Welche sind gesetzt, welche fehlen? securityheaders.com-Score?
6. Datei-Berechtigungen: chmod-Stand korrekt (644 für Dateien, 755 für Verzeichnisse, sensible Files restriktiver)?
7. Datenschutzerklärung: Aktuell, vollständig, alle Tools erwähnt?
8. Monitoring: Gibt es Alarme für Ausfälle, ungewöhnlichen Traffic, fehlgeschlagene Backups?
9. Hoster-Setup: Welcher Hoster, welche Sicherheits-Features sind aktiviert, wer hat Account-Zugriff?
10. Wartungs-Zyklus: Wer macht Updates, wann, mit welcher Dokumentation?

Bei den meisten Websites finden sich in dieser Liste 4–7 Lücken, die in 2–4 Stunden geschlossen werden können. Das ist die Standard-Aufräumarbeit beim Übernehmen einer Bestandsseite.

Wenn doch etwas passiert: Der Notfall-Plan

Sicherheit ist immer auch Risikomanagement. Wenn der Vorfall trotzdem eintritt — kompromittierte Seite, Datenleck, Ransomware — gilt:

Erste Stunde:

• Hoster informieren, gegebenenfalls Site temporär offline nehmen
• Passwörter aller Admin-Accounts ändern, 2FA verifizieren
• Aktuelle Backups in sicheren Bereich kopieren

Erster Tag:

• Forensik durch Spezialist:in (oft via Hoster oder externer Dienstleister) — was wurde kompromittiert, welche Daten sind betroffen
• Bei Datenleck: 72-Stunden-Meldepflicht an die zuständige Datenschutzbehörde prüfen (Art. 33 DSGVO)
• Bei Ransomware: nicht zahlen, Strafanzeige erstatten, Wiederherstellung aus Backup

Erste Woche:

• Wiederherstellung aus sauberem Backup
• Ursachenanalyse: Wie konnte es passieren?
• Lückenschluss vor Re-Live
• Kommunikation an betroffene Kund:innen, falls nötig

Wer keinen vorbereiteten Notfall-Plan hat, verliert in dieser Phase die meiste Zeit mit Improvisation. Selbst eine einseitige Notfall-Checkliste, einmal im Jahr aktualisiert, macht im Ernstfall einen großen Unterschied.

Fazit: Sicherheit ist Routine, nicht Magie

Es gibt keinen einzigen Zauberknopf, der eine Website sicher macht. Es gibt eine Reihe pragmatischer Maßnahmen, die in Summe genau das tun: aktuelle Software, saubere Backups, starke Logins, dokumentierte Prozesse.

Was ich in jedem Audit sehe: Die größten Schwachstellen sind nicht exotisch. Es sind veraltete Plugins, schwache Passwörter, fehlende Backups oder unvollständige Datenschutzerklärungen. Wer diese Basis sauber aufstellt, ist gegen 95 % der typischen Angriffe geschützt — ohne Enterprise-Budget, ohne Sicherheits-Spezialist im Haus.

Die andere Wahrheit: Sicherheit braucht Routine. Einmal aufgesetzt und drei Jahre nicht angefasst, war die beste Lösung von vor drei Jahren — heute ist sie veraltet. Wartungsverträge, regelmäßige Audits oder mindestens ein interner Check-Termin pro Quartal sind das, was die Investition in saubere Erst-Aufsetzung dauerhaft schützt.

Wenn du dir bei deiner Website unsicher bist, wo du gerade stehst: Schreib mir. Ich prüfe in 30 Minuten die wichtigsten Punkte und sage dir konkret, welche drei Maßnahmen dir am meisten bringen. Kostenlos und ohne Folge-Verpflichtung.