Website-Sicherheit: Konten, Dateien und Wiederherstellung

Schütze zuerst die Konten, die alles verändern können.

1. Liste Domainverwaltung, Hosting, Codeverwaltung, Mail und gegebenenfalls CMS als getrennte Zugänge auf. Notiere Besitzer und die Personen, die wirklich Änderungen benötigen.
2. Verwende persönliche Konten, eindeutige Passwörter beziehungsweise unterstützte Passkeys und einen zusätzlichen Faktor, wo verfügbar. Geteilte Administratorkonten erschweren die Zuordnung und das spätere Entziehen von Zugriff.
3. Sichere Wiederherstellungscodes geschützt außerhalb des Kontos. Prüfe, ob die Wiederherstellungsadresse unabhängig erreichbar bleibt, falls die eigene Domain ausfällt.
4. Entferne nicht mehr benötigte Einladungen und Zugänge nach abgestimmter Prüfung. Halte mindestens einen kontrollierten Wiederherstellungsweg für den Verantwortlichen offen.
5. Prüfe Benachrichtigungen zu Anmeldung, Domainablauf und Abrechnung. Sicherheitsmeldungen helfen nur, wenn sie jemand erhält und bearbeitet.

Alles im Browser ist grundsätzlich einsehbar.

JavaScript, HTML und öffentlich ausgelieferte Dateien sind kein Versteck für Passwörter. Ein API-Schlüssel wird nicht dadurch geheim, dass sein Variablenname kompliziert ist oder er in einem minimierten Skript steht. Besonders kritisch sind vollständige Projektordner, die versehentlich statt des vorgesehenen Veröffentlichungsverzeichnisses hochgeladen werden.

Prüfe den Dateisatz vor dem Upload: keine .env-Dateien, Sicherungsarchive, privaten PDFs, internen Notizen oder vertraulichen Testdaten. Gehe außerdem durch bereits veröffentlichte Dateien und die Änderungshistorie. Ist ein Geheimnis öffentlich geworden, reicht Löschen allein nicht: Zugang sperren oder austauschen, Reichweite prüfen und betroffene Verarbeitung bewerten.

Zum Nachlesen: OWASP: Umgang mit technischen Geheimnissen

Die Verbindung und die Anwendung getrennt prüfen.

HTTPS schützt die Übertragung zwischen Browser und dem jeweiligen Server. Es beweist nicht, dass jede Person nur ihre eigenen Daten sehen kann, dass Inhalte richtig gespeichert werden oder dass keine unerwünschten Drittanbieter beteiligt sind. Auch eine mit HTTPS erreichbare Vorschau kann für die ganze Welt offen sein.

Für eine reine Informationsseite prüfst du HTTPS, Weiterleitungen, externe Ressourcen und veröffentlichte Inhalte. Für eine Anwendung brauchst du zusätzlich Tests mit verschiedenen Rollen: abgemeldet, normaler Benutzer und Admin. Prüfungen im Browser sind dabei nur die Oberfläche; der Server muss jede geschützte Operation selbst berechtigen.

Eine neue Version braucht einen überprüfbaren Rückweg.

1. Sichere vor einer Änderung den vollständigen Quellstand und die notwendigen Konfigurationen. Bei CMS oder Anwendungen gehören relevante Datenbestände dazu; ein Screenshot ist keine Sicherung.
2. Teste die Änderung zunächst in einer getrennten Umgebung ohne echte Kundendaten. Kontrolliere auch Funktionen, die du nicht absichtlich verändert hast.
3. Notiere freigegebene Version, Datum und Verantwortlichen. Veröffentliche eine überschaubare Änderung und prüfe danach Startseite, Unterseiten und den tatsächlichen Kontaktweg.
4. Übe an einer Testumgebung die Rückkehr zum vorherigen Stand. Bei Datenbanken kann ein Code-Rollback allein unzureichend sein; Datenänderungen brauchen einen eigenen Rückweg.
5. Richte regelmäßige Update- und Funktionskontrollen ein. Sicherheitsrelevante Meldungen warten nicht automatisch bis zum nächsten monatlichen Routinetermin.

Schreibe eine Notiz, die auch im Ausfall hilft.

Deine Betriebsnotiz enthält Anbieter, zuständige Personen, gesicherten Quellstand, Wiederherstellungsverfahren und den Weg zum Support. Passwörter selbst gehören in eine geeignete geschützte Verwaltung, nicht als Klartext in dieselbe Notiz. Gib der Vertretung genau die Rechte, die sie im vereinbarten Fall braucht.

Miss Erreichbarkeit und Funktionsfähigkeit getrennt. Eine Startseite kann erreichbar sein, während Anfragen im Hintergrund scheitern. Ein regelmäßiger Test mit eindeutig erkennbaren künstlichen Angaben zeigt, ob der fachliche Ablauf noch funktioniert. Dokumentiere anschließend, wo diese Testdaten entfernt werden müssen.