Website-Sicherheit für Unternehmen: Was Sie prüfen sollten

Für Unternehmen kann ein Fehler bei Berechtigungen Kundenanfragen, interne Informationen oder Betriebsabläufe betreffen. Der konkrete Schutzbedarf hängt von den Daten und Zugängen ab.

Eine Anmeldung sieht sicher aus, wenn du deinen eigenen Bereich siehst. Sie beweist aber nicht, dass andere Menschen keinen Zugriff darauf haben. Sicherheit entsteht durch mehrere Maßnahmen, die zusammenpassen: Anmeldung, Berechtigungen, sichere Konfiguration, geschützte Schlüssel und ein Plan für den Ernstfall.

Die OWASP Top 10 für Webanwendungen helfen, häufige Risikoklassen zu verstehen. Sie sind ein Einstieg, kein Zertifikat für dein konkretes Projekt.

1. Zeichne auf, wo Daten fließen

Liste auf: Browser, Hosting, Serverfunktionen, Datenbank, externe APIs, E-Mail-Dienst und Backups. Welche Daten liegen wo? Wer verwaltet die Dienste? Welche Zugänge besitzen administrative Rechte? Markiere alle öffentlich erreichbaren Endpunkte und Datenbestände. Ein Diagramm auf Papier reicht zunächst.

Nicht jede Website hat eine Datenbank. Auch eine reine Infoseite hat aber ein Hosting-Konto, Abhängigkeiten und eine Domain, die geschützt und gepflegt werden müssen.

2. Anmeldung ist nicht Berechtigung

Authentifizierung klärt, wer eine Person ist. Autorisierung entscheidet, was sie tun darf. Ein versteckter Menüpunkt ist keine Zugriffskontrolle: Jemand kann eine Anfrage auch direkt stellen. Der Server oder die Datenbankregeln müssen jede relevante Anfrage prüfen.

Teste in einer geeigneten Testumgebung mit zwei Testkonten: Kann Konto A die eigenen Daten lesen und ändern? Wird der Zugriff auf Daten von Konto B verweigert, auch wenn eine Kennung in einer Anfrage verändert wird? Was passiert ohne Anmeldung und mit abgelaufener Sitzung? Prüfe Lesen, Erstellen, Ändern und Löschen getrennt. Nutze nur Systeme und Konten, für die du die Erlaubnis hast.

3. Schlüssel gehören nicht in die ausgelieferten Dateien

Alles, was der Browser herunterladen kann, ist für Nutzer einsehbar. Vertrauliche Schlüssel gehören in serverseitig geschützte Konfiguration, nicht in Quelltext, öffentliches Repository oder Frontend-Bundle. Manche Dienste bieten ausdrücklich öffentliche Client-Schlüssel an: Ob ihre Nutzung sicher ist, hängt zusätzlich von den serverseitigen Regeln ab. Lasse dir die Einordnung vom Anbieter erklären und prüfe sie.

Wenn ein echter geheimer Schlüssel veröffentlicht wurde, behandle ihn als kompromittiert: beim Anbieter sperren oder ersetzen, Verwendung prüfen und gegebenenfalls Verantwortliche informieren. Das bloße Löschen aus einer Datei entfernt ihn nicht zuverlässig aus Versionshistorie oder Kopien.

4. Konten und Dienste absichern

Schütze Hosting, Domain, Quellcode und Datenbank mit individuellen Konten und Mehrfaktor-Anmeldung, wo verfügbar. Vergib nur nötige Rechte, entferne veraltete Zugänge, halte Abhängigkeiten aktuell und prüfe Fehlermeldungen auf unbeabsichtigt sichtbare interne Details. Test- und Produktionsdaten gehören getrennt; ein öffentliches Vorschauprojekt braucht eigene Zugriffsregeln.

5. Wiederherstellung ist ein eigener Test

Eine Sicherung ist erst dann praktisch brauchbar, wenn sie sich zurückspielen lässt. Kläre, was gesichert wird, wie oft, wie lange und wer die Wiederherstellung ausführen darf. Probiere sie in einer isolierten Testumgebung aus. Dokumentiere außerdem, wen du bei einem Vorfall informierst und wie du betroffene Zugänge sperrst. Bei personenbezogenen Daten können Meldepflichten entstehen; die Umstände müssen dann zeitnah fachlich beurteilt werden.

Prompt für eine erste Prüfung

Prüfe dieses Projekt ausschließlich lesend auf Sicherheitsrisiken. Ich bin zur Prüfung berechtigt. Keine externen Angriffe, keine Änderungen, keine echten Nutzerdaten ausgeben.
Kartiere Datenflüsse und öffentlich erreichbare Endpunkte. Prüfe Authentifizierung und serverseitige Autorisierung, Datenbankregeln, Geheimnisse im Frontend, Abhängigkeiten und Konfiguration von Test und Produktion.
Gib je Befund Datei/Fundstelle, konkretes Risiko, Voraussetzungen, Schwere als begründete Einschätzung und einen sicheren Prüfschritt mit Testkonten aus. Trenne nachgewiesene Befunde von Vermutungen und nenne, was du nicht prüfen konntest. Gib keine Geheimnisse aus.
Schlage anschließend die kleinsten Korrekturen und passende Tests vor. Setze nichts ohne meinen Auftrag um.

Ein Coding-Assistent sieht nur, was du ihm zugänglich machst; externe Einstellungen und reale Angriffswege können fehlen. Ein Bericht mit „keine Probleme gefunden“ ist kein Sicherheitsnachweis.

Hilfe und nächste Schritte

Wenn du unsicher bist, ob dein Login und deine Datenbank richtig abgesichert sind, sprich uns bei Moinsen an. Wir können gemeinsam den technischen Umfang und sinnvolle nächste Prüfungen klären. Umfang und Ergebnis einer konkreten Prüfung werden gesondert vereinbart.

Kontakt zu Moinsen.

Weiterlesen: Hosting · Datenschutz · Barrierefreiheit · Alle Beiträge im Moinsen-Blog

Checkliste zum Mitnehmen

• Admin-Konten mit individuellen Zugängen und, soweit verfügbar, Mehrfaktor-Anmeldung geschützt.
• Keine geheimen Schlüssel in öffentlichem Code oder ausgelieferten Dateien.
• Anmeldung und Berechtigungen getrennt geprüft; zwei Testkonten und nicht angemeldete Zugriffe berücksichtigt.
• Test- und Produktionsumgebung getrennt; Vorschauen auf Öffentlichkeit geprüft.
• Abhängigkeiten, Fehlermeldungen und unnötige Zugänge geprüft.
• Zuständigkeiten und erste Schritte bei einem Vorfall dokumentiert.