Warum Ihre Website ein Sicherheitsrisiko ist — und wie es richtig gemacht wird
Kurz gesagt
Web-Sicherheit ist keine Frage des Budgets, sondern der Architektur. Wer von Anfang an auf sauberen Code ohne lange Plugin-Ketten setzt, Eingaben konsequent validiert und regelmäßig aktualisiert, hat weniger Angriffsfläche. Die häufigste Schwachstelle im Mittelstand sind veraltete WordPress-Plugins, die automatisiert und innerhalb weniger Tage ausgenutzt werden.
Warum Mittelstandswebsites besonders gefährdet sind
Große Unternehmen haben Security-Teams. Kleine Unternehmen glauben, zu uninteressant für Angriffe zu sein. Der Mittelstand fällt durch beide Raster: groß genug, um interessant zu sein, klein genug, um keine ausreichenden Schutzmaßnahmen zu haben. Dieses Kombinationsrisiko macht ihn zur häufigsten Zielgruppe automatisierter Angriffe.
Die häufigste Angriffsfläche sind WordPress-Installationen mit veralteten Plugins. Sicherheitslücken in bekannten Plugins werden öffentlich dokumentiert — in CVE-Datenbanken, auf GitHub, in Security-Blogs — und dann automatisiert ausgenutzt. Kein gezielter Angriff, sondern maschinelles Scannen von Millionen Websites nach bekannten Schwachstellen. Der Zeitraum zwischen der Veröffentlichung einer Schwachstelle und dem ersten automatisierten Exploit-Versuch beträgt im Durchschnitt weniger als 72 Stunden. Die Folgen reichen von Datenverlust und Reputationsschäden bis zu DSGVO-Bußgeldern und direkter Haftung gegenüber Kunden.
Die häufigsten Angriffsmuster (OWASP Top 10)
- XSS (Cross-Site-Scripting): Schadcode wird über Nutzereingaben eingeschleust und im Browser anderer Nutzer ausgeführt
- SQL-Injection: Datenbankabfragen werden manipuliert, um Daten auszulesen — häufig durch schlecht validierte Formulare
- CSRF: Nutzer werden unbemerkt zu Aktionen verleitet, die sie nicht beabsichtigen, etwa eine Passwort-Änderung
- Veraltete Komponenten: Plugins und CMS-Versionen mit öffentlich bekannten Lücken, die nicht aktualisiert wurden
- Fehlkonfigurierte Zugriffsrechte: ungeschützte Admin-Bereiche, nie geänderte Standard-Passwörter
- Broken Authentication: schwache Passwörter, fehlendes Rate-Limiting, keine Zwei-Faktor-Authentifizierung für Admin-Zugänge
- Sensitive Data Exposure: Kundendaten unverschlüsselt gespeichert oder unverschlüsselt übertragen
Sicherheit als Architekturentscheidung
1. Nutzereingaben immer serverseitig validieren: clientseitige Validierung allein ist kein Schutz. Ausgaben in HTML werden escaped, Datenbankabfragen laufen über Prepared Statements — ohne Ausnahme. 2. Plugin-Abhängigkeiten radikal minimieren: Jedes Plugin ist eine potenzielle Angriffsfläche mit Zugriff auf die gesamte Datenbank. Wer 40 Plugins betreibt, hat 40 Stellen, die regelmäßig geprüft werden müssen. 3. Regelmäßige Updates mit anschließendem Test: CMS, Plugins und PHP-Version müssen regelmäßig aktualisiert werden — idealerweise mit einem monatlichen Rhythmus und einer Staging-Umgebung. 4. Security-Header auf Serverebene setzen: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options und HSTS schließen eine ganze Klasse von Angriffen mit minimalem Aufwand. 5. Tägliche Backups extern speichern: Wer gehackt wird, braucht einen sauberen Stand von gestern, nicht von letztem Monat — und ein regelmäßig getestetes Backup. 6. Monitoring und Alarmierung einrichten: Uptime-Monitoring, Datei-Integritätsprüfungen und Fehler-Logs liefern frühe Hinweise, bevor Kunden das Problem melden.
Wer haftet, wenn Kundendaten gestohlen werden?
Bei einem Datenschutzverstoß durch einen Hack haftet der Website-Betreiber, nicht die Agentur und nicht der Hoster. Die DSGVO verlangt nach Art. 32 angemessene technische Schutzmaßnahmen. Wer keine nachweisbaren Maßnahmen implementiert hat, riskiert Bußgelder bis zu 4 Prozent des weltweiten Jahresumsatzes sowie Schadensersatzforderungen betroffener Kunden. Ein dokumentierter Fall: Ein Online-Händler mit 5 Millionen Euro Umsatz, dessen Shop durch ein ungepatchtes Plugin kompromittiert wurde, meldete einen Kundendaten-Abfluss an die Aufsichtsbehörde — Bußgeld 180.000 Euro, dazu Kosten für forensische Analyse, Systemreinigung und Kunden-Benachrichtigung. Das Gesamtschadensbild überstieg 300.000 Euro, für ein Plugin-Update, das 15 Minuten gedauert hätte.
Sicherheits-Checkliste für den Sofort-Check
- HTTPS aktiv: kein gemischter Content, keine HTTP-Ressourcen auf HTTPS-Seiten
- Adminbereich geschützt: nur per Zwei-Faktor-Authentifizierung oder IP-Whitelist erreichbar, kein Standard-Passwort
- Alle Plugins aktuell: kein Plugin älter als 90 Tage ohne verfügbares Update
- PHP-Version aktuell: PHP 8.2 oder 8.3, kein End-of-Life-Stand im Betrieb
- Backup vorhanden: externes, tägliches Backup mit dokumentiertem Restore-Test
- Security-Header gesetzt: CSP, X-Frame-Options und HSTS im HTTP-Response vorhanden
- Keine Standard-Zugangsdaten: keine schwachen Passwörter wie "admin" oder "admin123" aktiv
- Fehler-Monitoring aktiv: Log-Dateien werden überwacht, nicht erst bei Kundenbeschwerden