Sicherheit
Web-Sicherheit: Grundlagen, die jede Website braucht
Sicherheit ist keine Option. Für Unternehmenswebsites reichen oft wenige konsequente Maßnahmen: HTTPS, aktuelle Software, sichere Formulare und klare Prozesse bei Updates.
Was Sie wirklich schützen müssen
| Asset | Risiko bei Lücke |
|---|---|
| Nutzerdaten (Formulare, Login) | DSGVO, Vertrauensverlust |
| Admin-Zugänge | Defacement, Erpressung, Datenabfluss |
| Verfügbarkeit | Ausfall, SEO-Schaden, Umsatzverlust |
| Reputation | Phishing über kompromittierte Domain |
Nicht jede Website braucht ein Security Operations Center (SOC). HTTPS, Patches und Zugriffskontrolle gehören jedoch zur Grundausstattung.
HTTPS überall
- TLS 1.2+ (besser 1.3) auf allen Seiten, nicht nur Login
- Kein Mixed Content (HTTP-Ressourcen auf HTTPS-Seiten)
- HSTS Header, damit Browser HTTPS erzwingen
- Zertifikate automatisch erneuern (Let's Encrypt, Hosting-Provider)
HTTPS ist Ranking-Signal und Vertrauensbasis (siehe auch SEO-Grundlagen).
Sichere Entwicklung (OWASP-Kern)
Input validieren serverseitig: Formulare, Suche, API-Parameter. Client-Validierung ist UX, Server-Validierung ist Sicherheit.
SQL-Injection: Parametrisierte Queries / ORM, nie Strings konkatenieren.
XSS: Ausgabe escapen, Content-Security-Policy (CSP) setzen, um Skript-Quellen zu begrenzen.
Secrets: API-Keys und Passwörter nie ins Git. Umgebungsvariablen oder Secret Manager des Hosters.
Dependencies: npm audit, Dependabot, regelmäßige Updates. Viele Breaches nutzen bekannte, ungepatchte Lücken.
Authentifizierung und Admin
- MFA für CMS-, Hosting- und Admin-Konten
- Starke Passwörter, keine Wiederverwendung
- Passwörter gehasht (bcrypt/Argon2), nie Klartext
- Session-Timeout, sichere Cookies (
HttpOnly,Secure) - Brute-Force-Schutz (Rate Limiting, Lockout)
Weniger Admin-Oberflächen exponieren = kleinere Angriffsfläche. Static Sites (Next.js SSG) haben weniger Angriffsvektoren als veraltetes WordPress ohne Pflege.
Die Architekturentscheidung dahinter ordnet der Überblick zu modernen Web-Technologien ein.
Updates und Backups
Patch-Rhythmus: CMS, Plugins, Node-Dependencies, Server-Images. Staging testen, dann Produktion.
Backups: 3-2-1-Regel anwenden, Sicherungen verschlüsseln und den Restore testen. Nur eine erfolgreich wiederhergestellte Sicherung ist belastbar.
Monitoring: Fehlgeschlagene Logins, ungewöhnlicher Traffic, Dateiänderungen. Alerts an eine Person, die reagiert.
DSGVO und Formulare
- Nur Daten erheben, die Sie brauchen
- Datenschutzerklärung aktuell halten
- Einwilligung bei Marketing/M tracking sauber dokumentieren
- Löschanfragen und Auskunft Prozesse definieren
Kontaktformular per mailto: (wie auf bitautor.de) reduziert Server-Speicherung, ersetzt aber keine Datenschutz-Information.
Praktische Checkliste
- HTTPS und HSTS aktiv?
- Alle Dependencies und CMS-Plugins aktuell?
- MFA auf Hosting und CMS?
- CSP und Security-Headers (
X-Frame-Options,X-Content-Type-Options) gesetzt? - Backups + letzter Restore-Test dokumentiert?
Mehr Performance-Härtung (CDN, Caching) im Performance-Leitfaden. Technische Basis beim Relaunch: Website-Entwicklung.
Security Headers im Überblick
Neben CSP helfen diese Header gegen häufige Angriffe:
| Header | Schutz |
|---|---|
Strict-Transport-Security | erzwingt HTTPS |
X-Frame-Options / frame-ancestors | Clickjacking |
X-Content-Type-Options: nosniff | MIME-Sniffing |
Referrer-Policy | Datenabfluss über Referrer |
Bei Next.js oder Static Hosting prüfen, ob der Hoster Header setzt oder ob Sie sie in der Config ergänzen müssen.
Incident Response ohne Panik
Wenn etwas schiefgeht, brauchen Sie einen kurzen Ablauf:
- Eindämmen: betroffene Zugänge sperren, Site ggf. in Wartungsmodus
- Analysieren: Logs, geänderte Dateien, letzte Deployments
- Beheben: Patch, Passwörter rotieren, Backdoor entfernen
- Kommunizieren: intern sofort, extern nur bei Datenpannen nach DSGVO-Prozess
- Nachbereiten: Root Cause dokumentieren, Monitoring verschärfen
Ein einseitiger Notfallplan hält die Kontakte für Hosting, IT und Datenschutz griffbereit.
Bei Relaunches: alte Admin-URLs abschalten, Test-Accounts löschen, Staging nicht öffentlich indexieren. Viele Vorfälle entstehen durch vergessene Zugänge, nicht durch exotische Zero-Days.
Regelmäßige Dependency-Updates gehören in den Kalender, nicht nur „wenn Zeit ist“. Bekannte CVEs in CMS-Plugins sind der häufigste Einbruchsweg bei kleinen Sites.
Sicherheit endet nicht mit dem Launch. Eine quartalsweise Prüfung von Headern, Backups und Zugängen senkt das Risiko teurer Notfälle.
Wichtige Erkenntnisse
- HTTPS und aktuelle Software sind das Minimum
- Serverseitige Validierung und CSP stoppen die häufigsten Web-Angriffe
- MFA für Admin-Zugänge ist Pflicht, nicht Kür
- Backups nur wertvoll, wenn Restore getestet ist
- Sicherheit und Datenschutz stärken Vertrauen und SEO
Häufige Fragen zur Web-Sicherheit
Reicht HTTPS allein?
Nein. HTTPS ist Minimum. Dazu gehören Updates, MFA, serverseitige Validierung und getestete Backups.
Wie oft sollte ich Backups testen?
Mindestens quartalsweise einen Restore-Test dokumentieren. Ein Backup ohne erfolgreichen Test ist wertlos.
Brauche ich CSP auch bei kleinen Sites?
Ja, wenn dynamische Inhalte oder Formulare existieren. CSP reduziert XSS-Risiko deutlich.
Was ist der schnellste Sicherheitsgewinn?
MFA auf Hosting und CMS, veraltete Plugins entfernen, Admin-Oberflächen nicht unnötig exponieren.
