Wie sicher ist eine Website wirklich? Der große Sicherheitscheck 2026

Stell dir vor, du kommst nach Hause. Die Haustür hat ein teures Schloss, der Briefkasten ist abgesperrt, die Klingel leuchtet freundlich. Und das Kellerfenster? Steht seit drei Wochen auf Kipp.

Genau so sehen erstaunlich viele Websites aus. Vorne glänzt das Schloss im Browser, hinten liegt eine Datei namens backup.zip offen im Hauptverzeichnis, das Adminpasswort lautet Sommer2019, und ein Plugin hat seit drei Jahren kein Update mehr gesehen. Der Besucher merkt davon nichts. Ein Angreifer merkt es nach fünf Minuten.

Wir bauen seit 1999 Websites, Tools und Dienste, und dabei haben wir eines gelernt: Eine Website kann tadellos funktionieren, hübsch aussehen, schnell laden und trotzdem löchrig sein wie ein Schweizer Käse. Funktionieren und sicher sein sind zwei völlig verschiedene Eigenschaften.

In diesem Guide nehmen wir deshalb eine Website Stück für Stück auseinander. Wir schauen uns an, was sie nach außen verrät, was Server, Login, Formulare, Uploads, Datenbank, DNS und Backups damit zu tun haben, und wie du all das selbst prüfen kannst. Ohne Angstmacherei, ohne Fachchinesisch, dafür mit vielen Beispielen, typischen Fehlern und einer Checkliste, die du am Ende direkt abarbeiten kannst.

KURZANTWORT: Wie sicher ist eine Website wirklich? So sicher wie ihr schwächstes Glied. Ein aktives HTTPS Zertifikat (das Schloss im Browser) verschlüsselt nur den Transportweg zwischen Besucher und Server. Ob die Website selbst sicher ist, entscheidet sich an acht weiteren Stellen: aktuelle Software, sauber konfigurierter Server, geschützte Logins, korrekte Zugriffsrechte, geprüfte Eingaben, sichere Uploads, gut versteckte Geheimnisse und funktionierende Backups samt Überwachung. Eine Website gilt als gut abgesichert, wenn alle diese Bereiche geprüft, dokumentiert und regelmäßig gepflegt werden. Hundert Prozent Sicherheit gibt es nie, wohl aber eine drastisch kleinere Angriffsfläche.

Was du in diesem Guide lernst

Dieser Artikel ist mit in Summe mit 41 DIN A4 Seiten bewusst lang. Wir wollen, dass du am Ende nichts mehr nachschlagen musst. Das erwartet dich:

• Was Website Sicherheit eigentlich bedeutet und welche fünf Schutzziele dahinterstecken
• Welche Informationen jede Website schon beim ersten Blick preisgibt und wie Angreifer daraus Schlüsse ziehen
• Warum HTTPS wichtig, aber nur der Anfang ist, und wie du TLS, Zertifikate und HSTS prüfst
• Wie Security Header funktionieren und was passiert, wenn sie fehlen
• Worauf es bei Server, Betriebssystem, Ports und SSH ankommt
• Wie du Logins, Passwörter, Sessions und Zugriffsrechte richtig absicherst
• Wie SQL Injection, Cross Site Scripting, Command Injection und Path Traversal entstehen und wie man sie verhindert
• Warum Datei Uploads eines der größten unterschätzten Risiken sind
• Wie du Datenbank, Geheimnisse, Cookies und Fehlerseiten in den Griff bekommst
• Wie DNS, SPF, DKIM und DMARC zusammenspielen und warum deine Emails sonst im Spam landen oder gefälscht werden
• Wie ein Backup aussehen muss, das im Ernstfall wirklich rettet
• Wie du einen kompletten Website Sicherheitscheck mit Checkliste selbst durchführst
• Was du tun musst, wenn es trotzdem passiert ist

Bequem zum Mitlesen oder zum späteren Nachschlagen: Jedes Kapitel funktioniert auch einzeln. Wer es eilig hat, springt direkt zur Checkliste im Kapitel 18.

WICHTIG: Wichtig vorab: nur an eigenen Systemen testen. Alle Prüfungen in diesem Guide führst du ausschließlich an Websites und Servern durch, die dir gehören oder für die du eine ausdrückliche schriftliche Erlaubnis hast. Das unbefugte Scannen oder Ausprobieren fremder Systeme kann in Deutschland strafbar sein, unter anderem nach den Paragrafen 202a bis 202c des Strafgesetzbuchs. Wir erklären Angriffe, damit du sie verstehst und verhinderst, nicht damit du sie nachbaust. Dieser Artikel ersetzt keine Rechtsberatung.

1. Was bedeutet sicher überhaupt? Die fünf Schutzziele einer Website

Bevor wir mit Werkzeugen um uns werfen, klären wir ein Wort, das ständig benutzt und selten erklärt wird: sicher. Wenn jemand sagt, seine Website sei sicher, meint er meistens etwas anderes als sein Nachbar. Der eine denkt an das Schloss im Browser, der andere an den Virenscanner, der dritte daran, dass noch nie etwas passiert ist.

In der IT Sicherheit hat sich ein klares Raster bewährt. Es heißt Schutzziele, und für Websites sind fünf davon entscheidend.

Schutzziel	Die Kernfrage	So sieht eine Verletzung aus
Vertraulichkeit	Können Unbefugte Daten lesen?	Kundendaten liegen in einer offenen Exportdatei, Passwörter stehen im Klartext in der Datenbank
Integrität	Kann jemand Inhalte oder Daten verändern?	Jemand schmuggelt Werbelinks oder Schadcode in deine Seiten, Preise im Shop werden manipuliert
Verfügbarkeit	Bleibt die Website erreichbar?	Ein Angriff mit Massenanfragen legt den Server lahm, ein Defekt zerstört die Datenbank ohne Backup
Authentifizierung und Autorisierung	Wer darf rein, und was darf er dort tun?	Ein Benutzer sieht die Daten eines anderen, ein Admin Konto wird per Passwort Raten übernommen
Datenschutz	Werden personenbezogene Daten angemessen verarbeitet?	Kontaktformular Daten wandern unverschlüsselt per Email, Logs speichern ewig vollständige IP Adressen

Vertraulichkeit: Wer darf was lesen?

Vertraulichkeit heißt, dass Informationen nur die Menschen sehen, für die sie bestimmt sind. Das betrifft Kundendaten, interne Dokumente, aber auch harmlos wirkende Dinge wie eine Liste von Benutzernamen. Ein Verstoß passiert oft ohne Hackerfilm Dramatik: Ein Entwickler legt eine Datenbank Sicherung im öffentlichen Webverzeichnis ab, weil es praktisch ist. Die Datei heißt dump.sql, und Suchmaschinen für offene Dateien finden sie schneller, als der Kaffee durchläuft.

Integrität: Ist alles noch so, wie es sein soll?

Integrität bedeutet, dass Inhalte und Daten nicht unbemerkt verändert werden. Der Klassiker: Eine gehackte Website sieht auf den ersten Blick völlig normal aus, liefert aber nur Suchmaschinen versteckte Spam Links aus. Der Betreiber sieht nichts, Google sieht alles, und plötzlich rutscht die Seite im Ranking ab. Integrität betrifft auch Preise, Bestellungen und Überweisungsdaten. Wer sie ändern kann, kann Geld umleiten.

Verfügbarkeit: Ist die Seite da, wenn man sie braucht?

Eine Website, die nicht erreichbar ist, ist für den Besucher genauso kaputt wie eine gehackte. Verfügbarkeit umfasst Schutz vor Überlastung (zum Beispiel durch DDoS Angriffe, also koordinierte Massenanfragen), ausreichend Serverressourcen, Redundanz und vor allem die Fähigkeit, nach einem Ausfall schnell wieder hochzufahren. Das führt direkt zum Thema Backups, dem wir später ein eigenes Kapitel widmen.

Authentifizierung und Autorisierung: Wer bist du, und was darfst du?

Zwei Begriffe, die oft verwechselt werden. Authentifizierung beantwortet die Frage, wer jemand ist (Login mit Passwort, Zwei Faktor Code, Passkey). Autorisierung beantwortet die Frage, was diese Person tun darf. Viele Websites schützen den Login gewissenhaft und vergessen die Autorisierung vollständig. Dann kommt man zwar nur mit Passwort hinein, sieht dort aber alles, was man nicht sehen sollte. Dieses Thema ist so wichtig, dass es in den OWASP Top 10, der bekanntesten Liste der häufigsten Webrisiken, seit Jahren ganz oben steht.

Datenschutz: Die rechtliche Seite der Sicherheit

In der EU hängt Sicherheit direkt am Recht. Die Datenschutz Grundverordnung (DSGVO) verlangt in Artikel 32 angemessene technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten. Und Artikel 33 verpflichtet dich, bestimmte Datenpannen innerhalb von 72 Stunden der Aufsichtsbehörde zu melden. Wer Sicherheit ernst nimmt, schützt also nicht nur Besucher, sondern auch sich selbst vor Bußgeldern. Wir sind keine Anwälte, und dieser Hinweis ersetzt keine Beratung. Er soll dir aber zeigen, dass Website Sicherheit kein Hobby für Technikfans ist, sondern Betreiberpflicht.

2. Der erste Blick: Was verrät deine Website nach außen?

Jetzt wird es praktisch. Bevor ein Angreifer irgendetwas ausprobiert, schaut er sich erst einmal um. Dieser Schritt heißt Reconnaissance (Aufklärung) oder auch Fingerprinting (Fingerabdruck nehmen). Er ist legal, leise und erstaunlich aufschlussreich, denn jede Website plaudert mehr aus, als ihr Betreiber ahnt.

Das Gute daran: Du kannst genau dasselbe tun, um deine eigene Seite zu prüfen. Nimm dir zehn Minuten und schau hin.

Server Header und Versionsnummern

Bei jedem Seitenaufruf schickt der Server zusätzlich zur Seite ein paar Kopfzeilen mit, die HTTP Header. Viele Server verraten dort freiwillig, wer sie sind. Das sieht zum Beispiel so aus:

Server: Apache/2.4.41 (Ubuntu) X-Powered-By: PHP/7.4.3

Ein Angreifer liest daraus: Apache in einer bestimmten Version, PHP in einer bestimmten Version, Ubuntu als Betriebssystem. Nun muss er nur noch nachsehen, welche bekannten Schwachstellen es für genau diese Versionen gibt. Die Listen dafür sind öffentlich (sie heißen CVE Datenbanken, CVE steht für Common Vulnerabilities and Exposures).

Wichtig ist die Einordnung: Eine Versionsnummer im Header ist keine Schwachstelle. Sie ist eine Einladung zum gezielten Suchen. Wer aktuell gepatcht ist, hat wenig zu befürchten. Wer aber PHP 7.4 oder älter betreibt, das seit 2022 keine Sicherheitsupdates mehr bekommt, verschenkt dem Angreifer die halbe Arbeit.

EXPERTENTIPP: So prüfst du es selbst: Öffne in Chrome oder Firefox die Entwicklerwerkzeuge (Taste F12), wechsle zum Reiter Netzwerk, lade die Seite neu und klicke auf die erste Anfrage. Unter Antwort Header siehst du alles, was dein Server nach außen schickt. Alternativ geht es in der Konsole mit dem Befehl curl und der Option für Header Ausgabe.

CMS, Frameworks und Bibliotheken erkennen

Auch ohne Header lässt sich vieles erraten. Der Quellcode verrät, ob WordPress, Joomla, Drupal, TYPO3 oder ein Shopsystem läuft. Typische Spuren sind die Standardordner des jeweiligen Systems, ein Meta Tag namens generator oder bekannte Standarddateien. Dazu kommen JavaScript Bibliotheken samt Version, zum Beispiel eine uralte jQuery, deren Dateiname die Nummer gleich mitliefert.

Werkzeuge wie Wappalyzer oder BuiltWith automatisieren das: Domain eingeben, und sie listen CMS, Theme, Plugins, Analyse Tools, Hosting und Bibliotheken auf. Das ist nichts Geheimes, es ist öffentlich beobachtbar.

Öffentliche Dateien und Verzeichnisse

Dann kommen die kleinen Dateien, die fast jede Website hat:

• robots.txt sagt Suchmaschinen, was sie nicht durchsuchen sollen. Praktisch, aber tückisch: Wer dort Pfade wie /admin oder /geheim einträgt, zeigt Angreifern gleich, wo es interessant wird.
• sitemap.xml listet alle Seiten auf. Nützlich für SEO, aber manchmal tauchen dort Seiten auf, die gar nicht öffentlich sein sollten, etwa Testseiten oder Entwürfe.
• security.txt ist das Gegenteil: eine freiwillige Datei in einem standardisierten Unterordner deiner Domain (siehe Adresse unter der Liste), die Sicherheitsforschern sagt, an wen sie Funde melden können (festgelegt in RFC 9116). Sie ist ein Zeichen von Professionalität.
• Versteckte Überbleibsel wie backup.zip, old.zip, config.php.bak, database.sql, .env, .git/ oder phpinfo.php. Sie sind der Albtraum jedes Betreibers und der Jackpot jedes Angreifers.

Die Adresse der security.txt sieht so aus:

https://beispiel.de/.well-known/security.txt

Kommentare, Quellcode und Fehlermeldungen

Entwickler hinterlassen Notizen. Manchmal auch solche: ein HTML Kommentar mit dem Hinweis, dass hier noch das alte Testpasswort steckt, ein Pfad zu einer internen Testumgebung oder ein vergessener API Schlüssel im JavaScript. Ein kurzer Blick in den Quelltext (Strg plus U) lohnt sich für jeden Betreiber.

Dasselbe gilt für Fehlermeldungen. Wenn eine falsche Adresse eine ausführliche Fehlerseite mit Dateipfad, Datenbankname oder Stack Trace auslöst, bekommt der Besucher Innenansichten, die er nie brauchen sollte. Dem Thema widmen wir später ein eigenes Kapitel.

Praxisbeispiel: Die Website, die alles erzählte Nehmen wir eine fiktive, aber typische Firmenwebsite. Ein einziger Blick zeigt: Apache in einer drei Jahre alten Version, PHP 7.4, WordPress mit einem Kontaktformular Plugin, das den Versionsstand im Quelltext ausgibt, eine jQuery Version von 2016 und eine robots.txt, die den WordPress Adminbereich und einen Ordner namens intern auflistet. Im Hauptverzeichnis liegt außerdem eine Datei mit dem Namen test.php, die beim Aufruf die komplette PHP Konfiguration ausgibt. Nichts davon ist für sich genommen ein Einbruch. Zusammen ergibt es aber ein Drehbuch: Ein Angreifer weiß, welche Lücken zu welcher Software passen, wo der Login sitzt und wo der vergessene Ordner liegt. Das Ziel ist also nicht, nichts zu verraten, sondern so wenig wie möglich zu verraten und alles aktuell zu halten.

Ein häufiges Missverständnis räumen wir gleich aus: Informationen zu verstecken, nennt man Security through Obscurity (Sicherheit durch Geheimhaltung), und das ist allein keine Sicherheit. Wenn du die Versionsnummer versteckst, aber nie Updates einspielst, hast du die Lücke nur unsichtbar gemacht. Verstecken ist ein zusätzlicher Schritt, kein Ersatz für Patches.

3. HTTPS: wichtig, aber nur der Anfang

Das grüne oder graue Schloss neben der Adresse hat eine ganze Generation von Website Betreibern beruhigt. Und genau da liegt das Problem. Viele glauben: Schloss da, Website sicher. Das stimmt so nicht, und das ist eines der häufigsten Missverständnisse überhaupt.

Was HTTPS tatsächlich leistet

HTTPS ist HTTP mit Verschlüsselung. Die Verschlüsselung übernimmt das Protokoll TLS (Transport Layer Security, der Nachfolger des alten SSL). Damit erreicht HTTPS drei Dinge:

• Vertraulichkeit auf dem Transportweg: Niemand im selben WLAN oder auf dem Weg zwischen Browser und Server kann mitlesen.
• Integrität auf dem Transportweg: Niemand kann unterwegs Inhalte verändern, etwa Werbung einschleusen.
• Echtheit des Servers: Das Zertifikat belegt, dass der Server wirklich zur Domain gehört.

Was HTTPS nicht leistet

Und jetzt der wichtige Teil. HTTPS schützt nicht vor:

• SQL Injection und anderen Eingabefehlern (die Verschlüsselung transportiert auch Angriffe brav verschlüsselt)
• Cross Site Scripting (XSS)
• gestohlenen oder erratenen Passwörtern
• schlecht gesicherten Adminbereichen
• veralteter Software mit bekannten Lücken
• Serverfehlern und Fehlkonfigurationen
• kompromittierten Accounts
• fehlerhafter Zugriffskontrolle

Ein Bild hilft: HTTPS ist ein gepanzerter Geldtransporter. Er schützt das Geld auf der Fahrt. Ob der Tresor in der Bank offen steht, weiß er nicht.

Typischer Irrtum: Phishing Seiten haben auch HTTPS Ein großer Teil der Betrugsseiten im Netz nutzt inzwischen ein gültiges Zertifikat, denn kostenlose Zertifikate gibt es für jeden. Das Schloss beweist also nur, dass die Verbindung verschlüsselt ist, nicht dass die Seite vertrauenswürdig oder sicher ist.

TLS Version: Nur moderne Protokolle zulassen

TLS gibt es in mehreren Versionen. Die Versionen 1.0 und 1.1 gelten seit Jahren als veraltet, und moderne Browser haben sie abgeschaltet. Aktuell sind TLS 1.2 und TLS 1.3. Dein Server sollte mindestens TLS 1.2 anbieten, besser beide, und alles darunter abschalten. TLS 1.3 ist schneller (weniger Verbindungsaufbau Runden) und entfernt viele alte, unsichere Verfahren komplett.

Prüfen kannst du das kostenlos mit dem SSL Labs Server Test von Qualys. Domain eingeben, ein paar Minuten warten, Note ablesen. Eine Note A oder besser ist ein gutes Ziel. Schauen solltest du dabei nicht nur auf den Buchstaben, sondern auf die Details: unterstützte Protokolle, Cipher Suites (die angebotenen Verschlüsselungsverfahren) und Warnhinweise.

Zertifikat: Gültigkeit, Kette und Laufzeit

Ein Zertifikat hat ein Ablaufdatum, und abgelaufene Zertifikate sind einer der häufigsten Gründe für plötzliche Totalausfälle. Browser zeigen dann eine große rote Warnseite, die kaum ein Besucher wegklickt. Das Schlimmste daran: Es ist meistens vermeidbar.

Zwei Dinge solltest du wissen. Erstens werden Zertifikate immer kurzlebiger. Seit März 2026 gilt für öffentlich vertraute Zertifikate eine maximale Laufzeit von 200 Tagen, in den kommenden Jahren sinkt sie stufenweise weiter. Manuelles Erneuern wird damit unpraktisch. Zweitens ist Automatisierung die Lösung: Kostenlose Zertifizierungsstellen und viele Hoster erneuern per ACME Protokoll automatisch. Dein Job ist nur sicherzustellen, dass die Automatik wirklich läuft und dass dich ein Monitoring warnt, wenn sie es nicht tut.

Geprüft werden sollten außerdem:

• Passt der Domainname im Zertifikat zu allen genutzten Adressen, auch zur Variante mit und ohne www?
• Wird die komplette Zertifikatskette ausgeliefert (Zwischenzertifikate)? Fehlt ein Glied, meckern manche Geräte, obwohl der Desktop Browser schweigt.
• Sind die Zertifikate für Subdomains abgedeckt, oder gibt es eine vergessene Subdomain mit abgelaufenem Zertifikat?

Weiterleitung von HTTP auf HTTPS

Gibt jemand die Adresse ohne https ein, landet er zuerst auf der unverschlüsselten Version. Deshalb braucht jede Website eine saubere, permanente Weiterleitung (Statuscode 301) von HTTP auf HTTPS. Sie sollte in einem Schritt direkt zur endgültigen Adresse führen. Drei Weiterleitungen hintereinander kosten Ladezeit und öffnen unnötige Angriffsfenster.

Dazu gehört auch das Problem der Mixed Content Fehler: Die Seite lädt per HTTPS, bindet aber ein Bild, Skript oder Stylesheet über HTTP ein. Moderne Browser blockieren das teilweise, teilweise zeigen sie Warnungen. Kurz: alle Ressourcen konsequent auf HTTPS umstellen.

HSTS: Der Browser merkt sich, dass nur HTTPS erlaubt ist

Selbst mit Weiterleitung bleibt eine kleine Lücke: Der allererste Aufruf einer Seite ohne https kann abgefangen werden. Hier kommt HSTS ins Spiel, kurz für HTTP Strict Transport Security. Es ist ein Header, der dem Browser sagt: Sprich mit dieser Domain künftig ausschließlich verschlüsselt, und zwar für die nächsten so und so viele Sekunden.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Die Zahl 31536000 entspricht einem Jahr. Die Option includeSubDomains dehnt die Regel auf alle Subdomains aus, was nur sinnvoll ist, wenn wirklich alle Subdomains HTTPS können. Wer zusätzlich das Schlüsselwort preload ergänzt und die Domain in die Preload Liste der Browser eintragen lässt, schließt auch die Lücke beim Erstaufruf, allerdings ist das schwer rückgängig zu machen. Darum gilt: Erst mit kurzer Laufzeit testen (zum Beispiel einen Tag), dann schrittweise erhöhen.

Typischer Fehler: HSTS zu früh mit langer Laufzeit aktiviert Ein Betreiber stellt HSTS auf ein Jahr mit Subdomains, vergisst aber, dass eine alte Testsubdomain nur über HTTP läuft. Ergebnis: Besucher bekommen Fehlermeldungen, die sich nicht wegklicken lassen. Erst testen, dann verlängern.

4. Security Header: kleine Zeilen, große Wirkung

Jetzt wird es richtig spannend, denn Security Header gehören zu den Dingen, bei denen das Verhältnis von Aufwand zu Wirkung fast unverschämt gut ist. Ein paar Zeilen in der Serverkonfiguration, und der Browser des Besuchers arbeitet plötzlich als zusätzlicher Wachmann für dich.

Ein Security Header ist eine Anweisung, die dein Server zusammen mit der Seite an den Browser schickt. Sie sagt dem Browser, welche Dinge er erlauben und welche er verbieten soll. Das ist eine zweite Verteidigungslinie: Selbst wenn sich irgendwo ein Fehler in deinem Code versteckt, kann der Browser den Schaden oft begrenzen.

Header	Schützt vor	Was passiert, wenn er fehlt?	Priorität
Content Security Policy	Schadskripten (XSS), fremden Inhalten, Clickjacking	Eingeschleuster Code läuft ungehindert im Browser des Besuchers	Hoch
Strict Transport Security	Downgrade auf HTTP, Abfangen beim Erstaufruf	Erstaufruf kann manipuliert werden	Hoch
X Content Type Options	Falscher Dateityp Interpretation	Browser rät Dateitypen und führt ggf. Hochgeladenes als Skript aus	Mittel bis hoch
Referrer Policy	Datenabfluss über die Herkunftsadresse	Interne URLs oder Tokens wandern zu Drittseiten	Mittel
Permissions Policy	Missbrauch von Kamera, Mikrofon, Standort	Eingebettete Skripte dürfen Gerätefunktionen anfragen	Mittel
Frame Schutz (frame ancestors)	Clickjacking	Deine Seite lässt sich unsichtbar in fremde Seiten einbetten	Mittel bis hoch

Content Security Policy (CSP): der mächtigste Header

Die Content Security Policy ist die Königin unter den Headern. Sie legt fest, von wo der Browser Skripte, Bilder, Stylesheets, Schriften und andere Ressourcen laden darf. Alles, was nicht auf der Liste steht, wird blockiert.

Warum ist das so wertvoll? Nehmen wir an, ein Angreifer schafft es, einen Schnipsel JavaScript in deine Seite zu schmuggeln (das nennt man Cross Site Scripting, kurz XSS, dazu gleich mehr). Ohne CSP führt der Browser das Skript brav aus. Mit einer strengen CSP sagt der Browser: Dieses Skript steht nicht auf der Erlaubnisliste, ich führe es nicht aus. Der Angriff läuft ins Leere.

Ein einfaches Beispiel für eine Richtlinie:

Content-Security-Policy: default-src ’self‘; img-src ’self‘ data:; script-src ’self‘; style-src ’self‘; frame-ancestors ’none‘; base-uri ’self‘; form-action ’self‘

Das bedeutet in Klartext: Standardmäßig nur Inhalte von der eigenen Domain. Bilder zusätzlich als eingebettete Daten. Skripte nur von der eigenen Domain. Die Seite darf in keinem fremden Rahmen eingebettet werden, und Formulare dürfen nur an die eigene Domain senden.

So führst du eine CSP ohne Panik ein:

1. Starte im Testmodus mit dem Header Content Security Policy Report Only. Er blockiert nichts, meldet aber jede Verletzung in der Browser Konsole (und optional an einen Meldeendpunkt).
2. Sammle eine Woche lang die Meldungen und ergänze legitime Quellen, etwa deine CDN Domain oder dein Analyse Tool.
3. Entferne nach Möglichkeit Inline Skripte, also JavaScript direkt im HTML. Wo das nicht geht, nutze Nonces (einmalige Zufallswerte pro Seitenaufruf), statt pauschal die Direktive unsafe inline zu erlauben.
4. Schalte erst dann auf den echten Header um.

Typischer Fehler: Die CSP wird kopiert und verwässert Viele kopieren eine CSP aus dem Internet, die Seite bricht, und als schnelle Reparatur wird unsafe inline und unsafe eval erlaubt oder gleich ein Sternchen als Quelle eingetragen. Dann existiert der Header, schützt aber kaum noch. Eine CSP, die alles erlaubt, ist Deko.

Strict Transport Security (HSTS)

Haben wir im HTTPS Kapitel besprochen. Zur Erinnerung: Er zwingt den Browser dauerhaft auf verschlüsselte Verbindungen. Fehlt er, bleibt der Erstaufruf angreifbar, etwa in offenen WLANs.

X Content Type Options: Der Browser soll nicht raten

Browser sind hilfsbereit, manchmal zu hilfsbereit. Wenn eine Datei als Text ausgeliefert wird, der Inhalt aber aussieht wie JavaScript, raten manche Browser, dass es wohl doch ein Skript ist, und führen es aus. Das nennt man MIME Sniffing.

X-Content-Type-Options: nosniff

Mit diesem einen Wort sagst du: Halte dich an den Dateityp, den ich dir nenne. Besonders wichtig ist das bei Seiten mit Datei Uploads, weil es verhindert, dass eine getarnte Datei als Code durchrutscht.

Referrer Policy: Was erfährt die nächste Seite?

Klickt ein Besucher auf einen Link, schickt der Browser der Zielseite mit, woher er kommt. Das ist der Referrer. Enthält die Adresse sensible Teile (zum Beispiel ein Reset Token oder eine Bestellnummer), wandert das zur fremden Seite.

Referrer-Policy: strict-origin-when-cross-origin

Dieser Wert ist ein solider Standard: Innerhalb deiner eigenen Seite bleibt alles wie gehabt, an fremde Seiten geht nur die Domain, nicht der komplette Pfad, und bei einem Wechsel von HTTPS auf HTTP gar nichts.

Permissions Policy: Gerätefunktionen einschränken

Ein eingebettetes Werbeskript braucht weder Kamera noch Mikrofon noch Standort. Mit der Permissions Policy sagst du dem Browser, welche Funktionen deine Seite überhaupt nutzen darf:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Die leeren Klammern bedeuten: für niemanden erlaubt, auch nicht für die eigene Seite. Brauchst du etwas davon, erlaubst du es gezielt.

Clickjacking verhindern: frame ancestors und X Frame Options

Clickjacking ist ein fieses Spiel: Ein Angreifer bettet deine Seite unsichtbar in seine eigene ein und legt einen harmlosen Button darüber. Der Besucher glaubt, er klickt auf Gewinnspiel, klickt in Wahrheit aber auf deinen Löschen Button. Die Abwehr ist die Direktive frame ancestors in der CSP (oben im Beispiel bereits enthalten) oder der ältere Header X Frame Options mit dem Wert DENY oder SAMEORIGIN.

Weitere nützliche Header

• Cross Origin Opener Policy und Cross Origin Resource Policy isolieren deine Seite stärker von fremden Fenstern und Ressourcen. Für viele Seiten ein schönes Extra, für sicherheitskritische Anwendungen fast Pflicht.
• Cache Control sollte bei Seiten mit privaten Daten verhindern, dass sie im Zwischenspeicher landen (no store). Sonst sieht am Gemeinschafts Rechner der Nächste den Kontostand des Vorgängers.
• Server und X Powered By solltest du nach Möglichkeit entfernen oder auf das Nötigste kürzen. Das ist wie gesagt nur ein Zusatz, aber es nimmt dem Angreifer Futter.

So setzt du Security Header in der Praxis

Beim Apache Webserver geht das mit dem Modul headers in der Konfiguration oder der Datei .htaccess:

Header always set X-Content-Type-Options „nosniff“ Header always set Referrer-Policy „strict-origin-when-cross-origin“ Header always set Permissions-Policy „camera=(), microphone=(), geolocation=()“

Bei Nginx kommt die Direktive add_header in den Serverblock:

add_header X-Content-Type-Options „nosniff“ always; add_header Referrer-Policy „strict-origin-when-cross-origin“ always;

Bei einem Nginx Stolperstein lohnt sich Aufmerksamkeit: Definierst du in einem tieferen Block (etwa location) eigene add_header Zeilen, überschreiben diese die Header der höheren Ebene vollständig. Dann fehlen plötzlich genau auf den wichtigen Unterseiten die Header. Das passiert erstaunlich oft und fällt erst beim Test auf.

Expertentipp: Teste die Header auf mehreren Seiten Prüfe nicht nur die Startseite, sondern auch eine Unterseite, die Login Seite, eine Fehlerseite (404) und eine Datei wie ein Bild. Gute kostenlose Prüfwerkzeuge sind securityheaders.com und das Mozilla Observatory. Nimm die Note aber nicht als Gütesiegel, sondern als To do Liste.

5. Der Server: die eigentliche Basis

Eine sichere Website auf einem unsicheren Server ist wie ein Tresor auf einem Floß. Der Tresor mag stabil sein, das Floß hat aber ein Leck. Und umgekehrt genauso: Der bestgepflegte Server nützt wenig, wenn die Anwendung darauf Türen offen lässt. Beides muss stimmen.

Zuerst eine ehrliche Bestandsaufnahme: Wer ist für den Server verantwortlich? Beim Managed Hosting kümmert sich der Anbieter um Betriebssystem und Webserver, du um Anwendung und Inhalte. Beim Shared Hosting teilst du dir den Server mit anderen, dort hast du wenig Einfluss, solltest aber den Anbieter sorgfältig wählen. Bei einem eigenen virtuellen Server (VPS) oder Root Server bist du für alles verantwortlich, vom Betriebssystem bis zur Firewall. Mehr Freiheit heißt hier mehr Pflichten.

Software Stand: Betriebssystem, Webserver, PHP, Datenbank

Jede Softwareschicht hat einen Lebenszyklus. Irgendwann endet der Support (End of Life, kurz EOL), und ab dann gibt es keine Sicherheitsupdates mehr. Prüfe für jede Schicht:

• Läuft ein Betriebssystem, das noch Sicherheitsupdates bekommt?
• Ist der Webserver (Apache, Nginx) aktuell?
• Läuft eine PHP Version mit aktivem Support? Die offiziellen Supportzeiten kannst du auf php.net nachlesen.
• Ist die Datenbank (MariaDB, MySQL, PostgreSQL) aktuell?
• Werden Sicherheitsupdates automatisch eingespielt, oder hängt das an deinem guten Gedächtnis?

Bei Ubuntu und Debian gibt es dafür die Funktion für unbeaufsichtigte Updates (unattended upgrades). Sie installiert Sicherheitsupdates automatisch. Das ist kein Allheilmittel, aber für die meisten Server die bessere Alternative zu Vergessen.

Offene Ports und unnötige Dienste

Ein Server kommuniziert über Ports, nummerierte Türen. Die Faustregel: Jede offene Tür ist eine mögliche Schwachstelle, also öffne nur die, die du wirklich brauchst. Für eine typische Website sind das 80 (HTTP, nur zur Weiterleitung) und 443 (HTTPS), dazu ein abgesicherter Zugang für die Verwaltung.

Auf keinen Fall öffentlich erreichbar sein sollten:

• Datenbank Ports wie 3306 (MySQL oder MariaDB), 5432 (PostgreSQL), 27017 (MongoDB)
• Cache Dienste wie Redis (6379) oder Memcached (11211)
• Suchdienste wie Elasticsearch (9200)
• Verwaltungsoberflächen wie phpMyAdmin ohne zusätzlichen Schutz

Um herauszufinden, was offen ist, gibt es den Port Scanner nmap. Nutze ihn ausschließlich für eigene Server (siehe Warnhinweis oben). Ein Befehl von außen gegen die eigene IP Adresse zeigt dir, was die Welt sieht. Häufig ist das eine Überraschung: ein vergessener Testdienst, eine Entwicklungsdatenbank, eine Verwaltungsoberfläche.

Praxisbeispiel: Die Datenbank mit dem offenen Tor Ein Entwickler richtet für einen Test eine Datenbank auf einem neuen Server ein und öffnet den Port für seinen Laptop. Aus Bequemlichkeit gilt die Freigabe für alle Adressen, und das Passwort ist ein Platzhalter. Nach dem Test vergisst er die Sache. Nach kurzer Zeit tauchen in den Protokollen tausende Anmeldeversuche aus aller Welt auf. Automatische Scanner durchsuchen das Internet rund um die Uhr nach genau solchen Türen. Die Lehre: Was öffentlich erreichbar ist, wird auch gefunden, meist innerhalb von Stunden. Datenbanken gehören an die lokale Adresse oder in ein privates Netz, niemals ins offene Internet.

Firewall: Standardmäßig zu

Eine Firewall entscheidet, welcher Datenverkehr überhaupt zum Server durchdringt. Das Prinzip lautet Default Deny, also alles verbieten und gezielt erlauben. Auf Linux Servern reichen oft schon ufw (unkomplizierte Firewall) oder die Bordmittel des Hosters. Erlaube nur die notwendigen Ports, und beschränke Verwaltungsports wenn möglich auf bekannte IP Adressen oder ein VPN.

SSH richtig absichern

SSH ist der Fernzugang zum Server, gewissermaßen der Generalschlüssel. Er wird deshalb pausenlos angegriffen. Wirkungsvolle Maßnahmen:

• Anmeldung per Schlüssel statt Passwort: Ein SSH Schlüsselpaar ist um Größenordnungen schwerer zu knacken als jedes Passwort. Danach kann die Passwort Anmeldung komplett abgeschaltet werden.
• Root Login deaktivieren: Der Benutzer root ist ein bekanntes Ziel. Arbeite mit einem normalen Benutzer und erhöhe Rechte nur bei Bedarf.
• Fail2ban oder Ähnliches: Sperrt Adressen automatisch, die wiederholt fehlschlagen.
• Zwei Faktor Verfahren für Verwaltungszugänge, wo es möglich ist.

Ein Mythos noch: Den SSH Port von 22 auf einen anderen Wert zu ändern, reduziert das Rauschen in den Protokollen, erhöht die Sicherheit aber kaum. Es ist nett, aber kein Ersatz für Schlüssel und Fail2ban.

Dateirechte und Verzeichnisse

Auch innerhalb des Servers gilt das Prinzip der geringsten Rechte: Jeder Prozess und jeder Benutzer bekommt nur das, was er wirklich braucht. Der berüchtigte Reparaturversuch bei Problemen lautet: chmod 777, also jedem alles erlauben. Das löst das Problem und schafft ein größeres. Bei Dateien, die der Webserver nur lesen muss, reicht Leserecht. Schreibrechte gehören nur auf Ordner, in die die Anwendung wirklich schreiben muss (zum Beispiel Uploads oder Cache). Konfigurationsdateien mit Zugangsdaten gehören ideal außerhalb des öffentlichen Webverzeichnisses.

Und Directory Listing (die automatische Anzeige von Ordnerinhalten, wenn keine Startdatei vorhanden ist) solltest du abschalten. Sonst blättert jeder durch deine Ordner wie durch ein Fotoalbum.

Expertentipp: Trenne Umgebungen Testsystem, Entwicklung und Produktivsystem gehören auf getrennte Umgebungen mit getrennten Zugangsdaten. Testseiten unter einer Subdomain ohne Passwortschutz werden von Suchmaschinen und Scannern gefunden und sind ein klassischer Hintereingang. Schütze sie mit Passwort oder IP Beschränkung und lass sie nie mit Echtdaten laufen.

6. Updates, Plugins und Abhängigkeiten: die Schwachstelle mit Ansage

Wenn wir ehrlich sind: Die meisten erfolgreichen Angriffe auf Websites sind keine Meisterleistungen. Sie nutzen bekannte Lücken in veralteter Software aus, für die es längst einen Patch gibt. Der Angreifer muss nicht genial sein, er muss nur schneller sein als dein nächstes Update.

Nach übereinstimmenden Berichten von Sicherheitsfirmen entstehen bei Seiten mit Content Management System die meisten Lücken nicht im Kern des Systems, sondern in Erweiterungen wie Plugins und Themes. Das ist logisch: Der Kern hat ein großes Team, ein einzelnes Plugin vielleicht nur einen Entwickler in seiner Freizeit.

Die Update Routine, die wirklich funktioniert

• Alles, was du nicht brauchst, löschen. Deaktivierte Plugins sind nicht ungefährlich, denn ihre Dateien liegen weiter auf dem Server. Was nicht gebraucht wird, verschwindet.
• Verlassene Erweiterungen ersetzen. Wenn ein Plugin seit Jahren keine Updates erhält oder aus dem Verzeichnis entfernt wurde, such dir Ersatz.
• Sicherheitsupdates automatisch einspielen, wo das System es anbietet. Größere Versionssprünge erst auf einer Testumgebung prüfen.
• Vor jedem Update ein Backup. Siehe Kapitel 16.
• Feste Termine: Zum Beispiel jeden Montag fünfzehn Minuten für Updates. Regelmäßigkeit schlägt Heldentaten.
• Quellen beachten: Plugins und Themes nur aus vertrauenswürdigen Quellen. Geknackte Premium Versionen von Drittseiten sind fast immer mit Schadcode präpariert.

Lieferkette: Abhängigkeiten im Code

Wer mit Frameworks, Composer Paketen oder npm Bibliotheken arbeitet, baut auf dem Code hunderter Fremder auf. Diese Abhängigkeiten nennt man Lieferkette (Supply Chain). Wird dort eine Lücke bekannt, betrifft sie auch dich. Hilfreich sind die Befehle composer audit und npm audit. Sie prüfen, ob in deinen Paketen bekannte Schwachstellen stecken.

Auch eingebundene Skripte von Fremdservern (CDN) sind Teil der Lieferkette. Wird dieser Server gehackt, liefert er Schadcode an alle seine Kunden aus, also auch an deine Besucher. Dagegen hilft Subresource Integrity (SRI): Du gibst dem Script Tag eine Prüfsumme mit, und der Browser lädt die Datei nur, wenn sie exakt dazu passt.

<script src=“https://cdn.example.com/lib.js“ integrity=“sha384-PRUEFSUMME“ crossorigin=“anonymous“></script>

Typischer Fehler: Es läuft doch, warum anfassen? Der Satz ist der häufigste Grund für verwundbare Seiten. Nicht aktualisieren fühlt sich sicher an, weil nichts kaputtgeht. Bis eines Tages etwas kaputtgeht, und zwar gründlich. Das Risiko eines Updates ist überschaubar und planbar. Das Risiko einer bekannten, ungepatchten Lücke ist es nicht.

7. Login und Benutzerkonten: vom Eingang zum Innenleben

Bis hierher ging es um das Fundament. Jetzt wechseln wir zur Anwendung selbst, und die erste Tür ist der Login. Hier gilt: Wer Benutzerkonten hat, hat Verantwortung.

Passwörter: Länge schlägt Komplexität

Die alte Regel lautete: mindestens acht Zeichen, ein Großbuchstabe, eine Zahl, ein Sonderzeichen. Das Ergebnis waren Passwörter wie Sommer2026!, die zwar die Regeln erfüllen, aber von Raten Programmen in Sekunden getestet werden. Moderne Empfehlungen, etwa vom amerikanischen Standardisierungsinstitut NIST, setzen auf andere Dinge:

• Länge statt Schikane: Lieber 12 oder mehr Zeichen, gern als Passphrase aus mehreren Wörtern.
• Prüfung gegen bekannte Leaks: Passwörter, die in Datenlecks aufgetaucht sind, sollten abgelehnt werden.
• Kein erzwungener regelmäßiger Wechsel, nur bei Verdacht auf Kompromittierung. Erzwungene Wechsel führen zu Sommer2026! gefolgt von Herbst2026!.
• Passwort Manager erlauben, also Einfügen im Passwortfeld nicht verbieten.

Passwort Hashing: Niemals Klartext, niemals Schnellverfahren

Deine Anwendung darf Passwörter nie im Klartext speichern. Sie speichert einen Hash, eine Art Fingerabdruck, aus dem sich das Passwort nicht zurückrechnen lässt. Beim Login wird das eingegebene Passwort ebenfalls gehasht und verglichen. Wichtig: Es muss ein Verfahren sein, das absichtlich langsam ist. MD5 und SHA1 sind dafür ungeeignet, sie sind zu schnell und damit leicht massenhaft zu raten. Empfohlen sind Argon2id oder bcrypt.

In PHP ist das erfreulich einfach:

$hash = password_hash($passwort, PASSWORD_DEFAULT); // spaeter beim Login: if (password_verify($eingabe, $hash)) { /* Login ok */ }

Die Funktion kümmert sich um Salt (einen zufälligen Zusatz, der gleiche Passwörter unterschiedlich aussehen lässt) und um aktuelle Verfahren. Ein Angreifer, der die Datenbank stiehlt, bekommt so keine Passwörter, sondern nur aufwendig zu knackende Fingerabdrücke.

Zwei Faktor Authentifizierung und Passkeys

Ein Passwort allein ist ein einzelner Faktor. Zwei Faktor Authentifizierung (2FA) verlangt zusätzlich etwas, das man besitzt. Am gängigsten sind:

• Authenticator App (TOTP): Sechsstellige Codes, die alle 30 Sekunden wechseln. Solide und weit verbreitet.
• Hardware Sicherheitsschlüssel: Kleine USB oder NFC Geräte. Sehr stark, auch gegen Phishing.
• SMS Codes: Besser als nichts, aber die schwächste Variante, etwa wegen SIM Tausch Angriffen.

Die modernste Lösung sind Passkeys. Sie basieren auf dem Standard WebAuthn und ersetzen das Passwort durch ein kryptografisches Schlüsselpaar: Der private Schlüssel bleibt auf dem Gerät, die Website kennt nur den öffentlichen. Es gibt nichts, was man erraten, abfangen oder auf einer gefälschten Seite eingeben könnte. Große Plattformen setzen längst darauf, und 2026 ist der Einsatz für neue Projekte keine Zukunftsmusik mehr. Mindestens für Admin Zugänge ist 2FA Pflicht, nach unserer Überzeugung ohne Ausnahme.

Brute Force, Credential Stuffing und Schutz vor Dauerbeschuss

Zwei Begriffe, die du kennen solltest. Brute Force heißt: Ein Programm probiert massenhaft Passwörter durch.

Credential Stuffing heißt: Angreifer nehmen Zugangsdaten aus fremden Datenlecks und testen, ob dieselbe Kombination auch bei dir funktioniert. Das klappt erschreckend oft, weil viele Menschen Passwörter wiederverwenden.

Schutzmaßnahmen:

• Begrenzung der Versuche (Rate Limiting): Nach mehreren Fehlversuchen wird die Anmeldung verzögert oder zusätzlich geschützt.
• Progressive Verzögerung statt harter Sperre: Eine harte Kontosperre kann ein Angreifer missbrauchen, um echte Benutzer auszusperren. Schrittweise wachsende Wartezeiten oder ein zusätzlicher Test sind meist besser.
• Gleiche Fehlermeldung für alles: Sag nicht Benutzer existiert nicht oder Passwort falsch, sondern immer Anmeldung fehlgeschlagen. Sonst verrät das Formular, welche Benutzernamen existieren.
• Dasselbe beim Passwort zurücksetzen: Die Meldung lautet immer, dass eine Email gesendet wurde, falls das Konto existiert.
• Standardnamen meiden: Ein Konto namens admin ist das erste, was jeder Angreifer probiert.

Session Verwaltung: Was passiert nach dem Login?

Hier schlummert ein viel unterschätztes Thema. Nach dem Login bekommt der Browser eine Kennung, die Session ID, die bei jedem weiteren Aufruf beweist: Ich bin der Benutzer, der sich angemeldet hat. Wer diese Kennung stiehlt, ist der Benutzer, ohne jemals das Passwort zu kennen. Deshalb gilt:

• Nach dem Login eine neue Session ID erzeugen, damit keine zuvor untergeschobene Kennung gültig bleibt.
• Zeitlimit für Inaktivität und absolute Höchstdauer, je nach Sensibilität der Daten.
• Logout muss serverseitig die Session ungültig machen, nicht nur das Cookie im Browser löschen.
• Sichere Cookies, dazu mehr im Kapitel 13.
• Beim Passwortwechsel alle anderen Sessions beenden.

Und am wichtigsten: Was passiert nach dem erfolgreichen Login? Denn viele Systeme schützen die Eingangstür hervorragend, haben aber im Inneren keine einzige Zwischentür. Damit sind wir beim nächsten Kapitel.

8. Zugriffskontrolle: Darf der Benutzer das wirklich?

Wenn es ein Kapitel gibt, das wir dir ans Herz legen wollen, dann dieses. Fehlerhafte Zugriffskontrolle (englisch Broken Access Control) steht seit Jahren an der Spitze der OWASP Top 10. Das ist die Liste der häufigsten und gefährlichsten Webrisiken, die eine internationale Sicherheitsgemeinschaft regelmäßig aktualisiert. Und die Erklärung, warum sie ganz oben steht, ist banal: Es ist unfassbar leicht, hier einen Fehler zu machen, und automatische Scanner finden ihn oft nicht.

Das Beispiel, das alles erklärt

Stell dir eine Seite vor, die so aufgerufen wird:

https://beispiel.de/konto.php?id=123

Benutzer 123 sieht seine Bestellungen, seine Adresse, seine Rechnungen. So weit, so gut. Was passiert aber, wenn er die Zahl in der Adresszeile auf 124 ändert? Sieht er dann die Daten eines fremden Kunden? Falls ja, liegt ein gravierender Fehler vor. Er heißt IDOR (Insecure Direct Object Reference, auf Deutsch etwa unsichere direkte Objektreferenz). Niemand muss hacken, niemand muss Code einschleusen. Eine Zahl ändern genügt.

Praxisbeispiel: Die Rechnung von nebenan Ein Onlineshop zeigt Rechnungen unter einer Adresse mit fortlaufender Nummer. Ein Kunde bemerkt beim Herunterladen seiner Rechnung, dass die Nummer in der Adresse hochzählt, und stellt aus Neugier fest: Jede Nummer liefert eine Rechnung, auch die anderer Kunden, samt Name, Adresse und Kaufverlauf. Die Anwendung prüfte brav, ob jemand eingeloggt war, aber nie, ob die Rechnung ihm gehört. Der Fehler hatte einen Namen, Login Prüfung ohne Besitzprüfung, und einen gewaltigen Preis: eine meldepflichtige Datenpanne.

Die Lösung: Berechtigung serverseitig bei jeder Anfrage prüfen

Die Regel lautet: Die Anwendung muss bei jeder Anfrage auf dem Server prüfen, ob der angemeldete Benutzer dieses Objekt sehen oder ändern darf. Nicht nur beim Login, nicht nur im Menü, sondern jedes Mal. In Code gedacht:

$rechnung = holeRechnung($id); if ($rechnung->benutzer_id !== $aktueller_benutzer->id) {     http_response_code(403);     exit; }

Drei häufige Denkfehler dazu:

• Denkfehler 1: Zufällige statt fortlaufender IDs lösen das Problem. Lange zufällige Kennungen (UUIDs) erschweren das Raten und sind eine nette Ergänzung. Die Berechtigungsprüfung ersetzen sie nicht, denn IDs tauchen in Links, Protokollen und Mails auf.
• Denkfehler 2: Was im Menü nicht sichtbar ist, kann nicht aufgerufen werden. Ein ausgeblendeter Admin Button schützt nichts, wenn die dahinterliegende Adresse für jeden eingeloggten Benutzer funktioniert. Wer die Adresse kennt oder errät, ruft sie auf. Das nennt man Forced Browsing.
• Denkfehler 3: Das Frontend prüft schon. JavaScript im Browser kann ein Angreifer umgehen, sobald er Anfragen direkt sendet. Entscheidend ist immer die Prüfung auf dem Server.

Horizontal und vertikal: Zwei Arten von Rechteausweitung

Bei fehlerhafter Zugriffskontrolle unterscheidet man zwei Richtungen:

• Horizontal: Benutzer A greift auf Daten von Benutzer B zu, der gleichberechtigt ist (das Rechnungsbeispiel).
• Vertikal: Ein normaler Benutzer erlangt Rechte eines Administrators, zum Beispiel weil eine Verwaltungsfunktion nur über das Menü, aber nicht serverseitig geschützt ist.

Prinzipien für saubere Zugriffskontrolle

• Default Deny: Was nicht ausdrücklich erlaubt ist, ist verboten.
• Geringste Rechte: Jeder Benutzer und jede Rolle bekommt nur das Nötigste.
• Zentrale Prüfung: Eine einzige, gut getestete Stelle im Code prüft Rechte, statt an hundert Orten ein bisschen.
• Gilt auch für Schnittstellen (APIs): Mobile Apps und JavaScript Frontends sprechen über APIs mit dem Server, und jede einzelne Schnittstelle braucht die Prüfung.
• Protokollierung: Verweigerte Zugriffe gehören ins Protokoll, denn viele davon hintereinander sind ein Warnsignal.

Expertentipp: Der Zwei Konten Test Lege in deiner eigenen Anwendung zwei Testkonten an. Melde dich mit dem ersten an, notiere dir Adressen von Objekten (Bestellung, Profil, Datei) und rufe sie dann mit dem zweiten Konto auf. Versuche als normaler Benutzer Adressen des Adminbereichs aufzurufen. Wenn irgendetwas durchgeht, das nicht durchgehen sollte, hast du einen Fund, der mehr wert ist als jeder Scanner Bericht. Das ist kein Angriff, sondern eine ganz normale Qualitätsprüfung deiner eigenen Anwendung.

9. Formulare und Eingaben: Vertraue niemals ungeprüft

Jetzt kommen die Klassiker der Web Schwachstellen. Sie haben eines gemeinsam: Eine Anwendung nimmt Text von außen entgegen und behandelt ihn, als wäre er harmlos. Das Grundprinzip dahinter lautet: Benutzereingaben sind niemals vertrauenswürdig. Nicht aus Formularen, nicht aus Adresszeilen, nicht aus Cookies, nicht aus Headern, nicht aus hochgeladenen Dateien und nicht aus Schnittstellen.

Und ja, auch Eingaben von eingeloggten Benutzern, Kunden oder Kollegen. Nicht weil alle böse wären, sondern weil Angreifer genau so aussehen wie ganz normale Nutzer.

SQL Injection: Wenn Eingaben zu Befehlen werden

Datenbanken verstehen eine Sprache namens SQL. Eine Anwendung baut damit Abfragen zusammen, etwa: Suche den Benutzer mit diesem Namen. Der Fehler entsteht, wenn sie den Text des Besuchers einfach in die Abfrage klebt. Ein Angreifer schreibt dann nicht einen Namen, sondern ein Stück SQL Sprache. Die Datenbank kann nicht unterscheiden, was der Entwickler wollte und was der Angreifer eingeschmuggelt hat, und führt beides aus.

Die Folgen reichen vom Umgehen des Logins über das Auslesen kompletter Tabellen bis zum Löschen von Daten. Schwere Folgen, aber eine Schwachstelle mit einer klaren, einfachen Gegenmaßnahme: Prepared Statements (vorbereitete Abfragen). Dabei werden Befehl und Daten getrennt an die Datenbank geschickt. Die Datenbank behandelt Eingaben dann immer nur als Daten, nie als Befehl.

$stmt = $pdo->prepare(„SELECT * FROM benutzer WHERE email = ?“); $stmt->execute([$email]); $benutzer = $stmt->fetch();

Mehr Zauber steckt nicht dahinter. Das Fragezeichen ist ein Platzhalter, die Eingabe wird getrennt übergeben. Gleiches Prinzip gilt für jede Sprache und jedes Framework, bei Node, Python, Java oder PHP.

Typischer Fehler: Filtern statt trennen Manche Entwickler versuchen, gefährliche Zeichen wie Anführungszeichen aus Eingaben zu entfernen oder zu maskieren. Das ist fehleranfällig und wird irgendwann umgangen. Prepared Statements sind die richtige Lösung, Filter höchstens ein Zusatz. Auch ORMs (Werkzeuge, die Datenbank Abfragen für dich erzeugen) sind nicht automatisch sicher, wenn man rohe Abfragen hineinmischt.

Cross Site Scripting (XSS): Fremder Code in deiner Seite

Bei XSS landet Code eines Angreifers (meist JavaScript) in deiner Seite und läuft im Browser deiner Besucher. Er kann dort Inhalte verändern, Formulare abgreifen oder, wenn Cookies schlecht gesichert sind, Sitzungen stehlen. Es gibt drei Spielarten:

• Gespeichertes XSS (Stored XSS): Der Schadcode wird in der Anwendung gespeichert, zum Beispiel in einem Kommentar oder Profilnamen, und trifft jeden, der die Seite aufruft. Die gefährlichste Variante.
• Reflektiertes XSS (Reflected XSS): Der Code steckt in einem Link, den das Opfer anklickt, und wird von der Seite direkt zurückgespiegelt, etwa in einer Suchergebnisseite mit dem Text Keine Treffer für …
• DOM basiertes XSS: Der Fehler liegt im JavaScript der Seite selbst, das Eingaben unsicher in die Seite schreibt.

Die Hauptverteidigung heißt Ausgabe Escaping: Alles, was von außen kommt, wird beim Ausgeben so umgewandelt, dass der Browser es als reinen Text anzeigt und nicht als Code. In PHP zum Beispiel:

echo htmlspecialchars($kommentar, ENT_QUOTES, ‚UTF-8‘);

Moderne Frameworks machen das standardmäßig. Gefährlich wird es, wenn man diese Automatik bewusst umgeht oder mit der Funktion innerHTML im Browser arbeitet. Als zweite Verteidigungslinie wirkt die bereits besprochene Content Security Policy, als dritte das Attribut HttpOnly bei Cookies (Kapitel 13).

Cross Site Request Forgery (CSRF): Der untergeschobene Klick

Stell dir vor, du bist bei deiner Website eingeloggt und besuchst in einem anderen Tab eine präparierte Seite. Diese schickt im Hintergrund eine Anfrage an deine Seite, etwa Passwort ändern oder Email ändern. Dein Browser sendet dabei brav dein Login Cookie mit. Die Anfrage sieht echt aus, ist es aber nicht.

Schutz bieten CSRF Token (ein geheimer Zufallswert pro Formular, den nur die eigene Seite kennt) und das Cookie Attribut SameSite (Kapitel 13). Fast jedes Framework bringt das mit, man muss es nur einschalten.

Command Injection: Wenn Eingaben im Betriebssystem landen

Manche Anwendungen rufen Programme des Betriebssystems auf, etwa um Bilder zu verkleinern oder PDFs zu erzeugen. Setzt man dabei Befehle aus Benutzereingaben zusammen, kann ein Angreifer eigene Befehle anhängen. Das ist ein Totalschaden, denn dann läuft fremder Code direkt auf deinem Server. Die Regeln:

• Systembefehle wenn irgend möglich vermeiden und stattdessen Bibliotheken der Programmiersprache nutzen.
• Wenn es nicht ohne geht: Argumente einzeln und fest übergeben, Eingaben streng gegen eine Erlaubnisliste prüfen und Funktionen zum Maskieren von Argumenten verwenden.

Path Traversal: Ausbruch aus dem Ordner

Eine Seite liefert Dateien aus, etwa download.php mit einem Dateinamen als Parameter. Gibt der Angreifer statt eines Namens eine Kette aus Schritten nach oben im Verzeichnisbaum an, kann er aus dem vorgesehenen Ordner ausbrechen und Systemdateien oder Konfigurationen lesen. Gegenmittel: Dateinamen nie direkt aus Eingaben übernehmen, sondern über interne Kennungen zuordnen, den endgültigen Pfad normalisieren und prüfen, dass er wirklich im erlaubten Ordner liegt.

Validierung, Escaping und Kontext: Der Unterschied

Weil diese Begriffe ständig durcheinandergehen, eine klare Trennung:

• Validierung prüft, ob eine Eingabe dem Erwarteten entspricht (Ist das eine Zahl zwischen 1 und 100? Ist das eine gültige Emailadresse?). Am besten nach dem Erlaubnisprinzip: Nur Bekanntes wird akzeptiert.
• Escaping wandelt Daten für den jeweiligen Zielort so um, dass sie dort nicht als Befehl gelten (HTML, SQL, Shell, URL brauchen jeweils eigenes Escaping).
• Kontext entscheidet: Dieselbe Eingabe ist im HTML Text harmlos und im JavaScript Block gefährlich. Darum gilt: Escape immer für den Ort, an dem es landet.

Expertentipp: Validiere am Eingang, escape am Ausgang Prüfe Eingaben, sobald sie ankommen, und maskiere Daten beim Ausgeben für den jeweiligen Kontext. Wer sich nur auf eines von beiden verlässt, hat früher oder später eine Lücke. Und: Clientseitige Prüfungen im Browser sind Komfort für den Besucher, keine Sicherheit für dich.

10. Datei Uploads: das unterschätzte Risiko

Eine Upload Funktion klingt harmlos. Lade dein Profilbild hoch, hänge deinen Lebenslauf an, schick uns dein Foto. Aus Sicht eines Angreifers ist sie eine Einladung: Du darfst Dateien auf den Server eines Fremden legen. Wenn die Anwendung dabei nicht aufpasst, wird aus einem Profilbild im schlimmsten Fall ein Skript, das der Server ausführt, und damit die Übernahme des Servers.

Gehen wir eine Upload Funktion Schritt für Schritt durch, so wie man sie prüfen würde.

Die sieben Prüffragen für jeden Upload

1. Welche Dateiendungen sind erlaubt? Nutze eine Erlaubnisliste (zum Beispiel jpg, png, webp, pdf) statt einer Sperrliste. Sperrlisten vergessen immer eine Endung.
2. Wird der echte Dateityp geprüft? Der MIME Type, den der Browser mitschickt, ist ein Zuruf des Absenders und damit wertlos. Prüfe den Inhalt serverseitig, bei Bildern zum Beispiel, indem du sie mit einer Bildbibliothek öffnest und neu speicherst. Das entfernt auch versteckte Zusatzdaten.
3. Wird der Dateiname übernommen? Besser nicht. Lass die Datei beim Speichern umbenennen (zum Beispiel auf einen Zufallswert mit der geprüften Endung). Originalnamen können Sonderzeichen, Pfadangaben oder doppelte Endungen wie bild.php.jpg enthalten.
4. Wo wird die Datei gespeichert? Am besten außerhalb des öffentlichen Webverzeichnisses und über ein Skript ausgeliefert, das Rechte prüft. Mindestens aber in einem eigenen Ordner.
5. Ist das Upload Verzeichnis ausführbar? Im Upload Ordner darf der Server keine Skripte ausführen. Bei Apache und PHP gibt es dafür klare Einstellungen, die die Ausführung im Ordner abschalten. Das ist die wichtigste Einzelmaßnahme überhaupt.
6. Gibt es Größenlimits? Ohne Limit kann ein Angreifer mit riesigen Dateien Speicher und Rechenleistung verbrauchen (Verfügbarkeit!). Limits gehören sowohl in die Anwendung als auch in die Serverkonfiguration.
7. Wer darf hochladen und wer darf abrufen? Nicht jeder Besucher muss Dateien hochladen können, und nicht jede hochgeladene Datei muss jeder sehen. Hier begegnet dir die Zugriffskontrolle aus Kapitel 8 wieder.

Praxisbeispiel: Das Profilbild, das gar keins war Eine Website erlaubt Profilbilder und prüft nur, ob die Dateiendung jpg lautet. Ein Angreifer lädt eine Datei mit harmlosem Namen hoch, die im Inneren aber eine Mischung aus Bilddaten und Code enthält. Wird der Upload Ordner vom Server so betrieben, dass dort Code ausgeführt werden darf, und lässt sich die Datei unter einer Endung aufrufen, die der Server als Skript behandelt, läuft fremder Code auf dem Server. Der Schutz besteht hier aus mehreren Schichten: Erlaubnisliste, inhaltliche Prüfung, Umbenennen, getrennte Ablage und keine Ausführung im Ordner. Jede Schicht allein ist löchrig, zusammen sind sie stabil.

Zusatzrisiken bei Uploads

• SVG Dateien sind Bilder, können aber Skripte enthalten. Behandle sie wie aktiven Inhalt, bereinige sie oder erlaube sie nicht.
• Dokumente wie Word oder PDF können Schadcode transportieren, vor allem, wenn andere Benutzer sie öffnen. Ein Virenscan auf dem Server ist bei Uploads von Fremden sinnvoll.
• Archive (ZIP) können beim Entpacken Dateien an unerwünschte Orte schreiben. Die Entpackung nur mit Bibliotheken, die dieses Risiko kennen.
• Bildverarbeitung selbst hatte in der Vergangenheit Lücken. Auch hier gilt: Bibliotheken aktuell halten.

11. Datenbank und Backend: die Schatzkammer absichern

Die Datenbank ist das, worauf Angreifer am Ende meistens aus sind. Kundendaten, Bestellungen, Passwort Hashes, Nachrichten, alles liegt dort. Entsprechend sorgfältig sollte sie geschützt sein. Die Prüfliste:

• Die Datenbank ist nicht öffentlich erreichbar. Sie lauscht nur an der lokalen Adresse oder in einem privaten Netzwerk (siehe Kapitel 5).
• Eigener Datenbankbenutzer pro Anwendung. Nicht ein Benutzer für alles.
• Minimale Rechte. Eine Website braucht in aller Regel Lesen, Einfügen, Ändern und Löschen in ihrer eigenen Datenbank, aber keine Rechte zum Anlegen oder Löschen von Datenbanken oder zum Verwalten von Benutzern.
• Kein Root Zugriff aus der Webanwendung. Wenn ein Angreifer eine SQL Injection findet, bestimmen die Rechte des Datenbankbenutzers, wie groß der Schaden wird. Niedrige Rechte begrenzen ihn.
• Prepared Statements überall (Kapitel 9).
• Sensible Daten nicht im Klartext. Passwörter als Hash, besonders sensible Felder (zum Beispiel Gesundheitsdaten oder Ausweisdaten) zusätzlich verschlüsselt.
• Datensparsamkeit: Was du nicht speicherst, kann nicht gestohlen werden. Alte Daten, die du nicht mehr brauchst, löschst du regelmäßig.
• Backups sind geschützt, denn ein ungeschütztes Backup ist eine zweite Datenbank ohne Schloss (Kapitel 16).
• Zugangsdaten nicht im Repository, dazu gleich mehr.

Typischer Fehler: phpMyAdmin für alle Viele Installationen lassen die Datenbank Verwaltungsoberfläche unter einer erratbaren Adresse offen im Netz stehen, geschützt nur durch ein Passwort. Schütze sie zusätzlich durch IP Beschränkung, VPN oder eine zweite Anmeldung, oder entferne sie, wenn du sie nicht brauchst.

12. Geheimnisse im Quellcode: Passwörter gehören nicht in den Code

Ein Klassiker, den wir leider immer wieder sehen:

$db_passwort = „MeinSuperGeheimesPasswort“; const API_KEY = „sk_live_abc123…“;

Geheimnisse sind alles, womit sich deine Anwendung gegenüber anderen Systemen ausweist: Datenbankpasswörter, API Schlüssel (für Zahlungsanbieter, Emaildienste, Kartendienste, KI Dienste), Tokens, private Schlüssel, Signierschlüssel. Wer sie besitzt, kann in deinem Namen handeln, und zwar mit deiner Kreditkarte.

Wo Geheimnisse hingehören

• In Umgebungsvariablen oder einer .env Datei, die außerhalb des öffentlichen Webverzeichnisses liegt oder durch Serverregeln blockiert ist.
• In einem Secret Manager, wenn deine Infrastruktur einen anbietet.
• Nie im öffentlichen Webverzeichnis, denn eine .env Datei, die unter deiner Domain direkt abrufbar ist, gehört zu den häufigsten Funden überhaupt.
• Nie in Git, nicht einmal in einem privaten Repository, denn Zugriffe ändern sich, Mitarbeiter wechseln, Repositories werden irgendwann doch öffentlich.

Git Historie: Das Gedächtnis, das nie vergisst

Jetzt der Satz, den du dir merken solltest: Ein Geheimnis, das einmal in einem öffentlichen Git Repository gelandet ist, gilt grundsätzlich als kompromittiert, auch wenn die Datei später gelöscht wurde. Git speichert die gesamte Geschichte. Die Datei verschwindet aus der aktuellen Version, bleibt aber in früheren Ständen abrufbar. Und Suchroboter durchkämmen öffentliche Repositories in kurzer Zeit nach Zugangsdaten. Es gibt Berichte, nach denen versehentlich veröffentlichte Schlüssel schon nach Minuten ausprobiert werden.

Was tun, wenn es passiert ist?

1. Sofort das Geheimnis ungültig machen und ein neues erzeugen (Schlüssel rotieren). Das ist der entscheidende Schritt.
2. Prüfen, ob es missbraucht wurde (Protokolle des Anbieters, unerklärliche Kosten).
3. Erst danach die Historie bereinigen. Das ist Kosmetik, denn Kopien können längst existieren.
4. Künftig Werkzeuge einsetzen, die Geheimnisse vor dem Commit erkennen (sogenannte Secret Scanner), und eine Ignorierdatei pflegen, die .env Dateien ausschließt.

Auch im Frontend kein Geheimnis

Alles, was im JavaScript oder HTML ausgeliefert wird, liegt offen. Ein API Schlüssel im Browser Code ist kein Geheimnis. Manche Schlüssel sind ausdrücklich für den öffentlichen Einsatz gedacht und werden beim Anbieter auf Domains oder Funktionen beschränkt. Alles andere gehört auf den Server, der die Anfrage im Namen des Besuchers stellt.

13. Cookies und Sessions: drei Attribute, die den Unterschied machen

Cookies sind kleine Textstücke, die der Browser speichert und bei jeder Anfrage mitschickt. Für Login Sitzungen sind sie die wichtigste Währung. Darum haben sie drei Schutzattribute, die man kennen muss.

Attribut	Was es tut	Was passiert, wenn es fehlt?
Secure	Das Cookie wird nur über HTTPS gesendet	Es kann auf unverschlüsselten Verbindungen mitgelesen werden
HttpOnly	JavaScript kann das Cookie nicht lesen	Ein XSS Angriff kann die Session Kennung auslesen und stehlen
SameSite	Steuert, ob das Cookie bei Anfragen von fremden Seiten mitgesendet wird	Erleichtert CSRF Angriffe, weil fremde Seiten Aktionen im Namen des Benutzers auslösen können

So sieht ein sauber gesetztes Session Cookie aus:

Set-Cookie: session=ZUFALLSWERT; Secure; HttpOnly; SameSite=Lax; Path=/

SameSite kennt drei Werte. Strict sendet das Cookie nie bei Anfragen von fremden Seiten, das ist am sichersten, kann aber stören, wenn Besucher über einen externen Link kommen und dann scheinbar abgemeldet sind. Lax ist der sinnvolle Kompromiss und in modernen Browsern inzwischen Standard. None erlaubt Cookies überall und verlangt zwingend Secure.

Zusätzlich lohnt sich ein Blick auf das Cookie Präfix __Host, das Browser zu strengeren Regeln zwingt (nur Secure, kein Domain Attribut, Pfad Slash). Und denk daran: Nicht jedes Cookie ist ein Sicherheitscookie. Tracking und Analyse Cookies brauchen eine Einwilligung, das ist dann das Thema Datenschutz. Zur Sicherheit trägt bei ihnen nichts bei, außer dass sie dir ein weiteres Risiko und eine weitere Pflicht ins Haus holen.

Expertentipp: Sitzungsdaten nie im Cookie selbst speichern Das Cookie sollte nur eine zufällige, lange Kennung tragen, die Daten liegen serverseitig. Wer Informationen wie Benutzerrolle oder Benutzer ID direkt im Cookie speichert (ohne kryptografische Absicherung), lädt zum Manipulieren ein.

14. Fehlerseiten und Informationslecks: zu viel Hilfe schadet

Die folgende Fehlermeldung kennt fast jeder Webentwickler:

Warning: mysqli_connect(): (HY000/1045): Access denied for user ‚web’@’localhost‘ in /var/www/html/config/database.php on line 17

Für den Entwickler ist das Gold wert: Datei, Zeile, Benutzername, klarer Fehler. Für einen Besucher, der das zufällig sieht, ist es genauso wertvoll, nur aus anderem Grund. Er erfährt den Serverpfad, den Namen der Konfigurationsdatei, den Datenbankbenutzer und die Software. Genau solche Bausteine setzt ein Angreifer zum Gesamtbild zusammen.

Was nicht nach außen dringen sollte

• PHP Fehler und Warnungen (Einstellung display_errors in Produktivsystemen ausschalten, Fehler stattdessen in Protokolldateien schreiben)
• Stack Traces (die ausführliche Aufrufkette bei einem Programmfehler)
• Debug Modus von Frameworks. Ein versehentlich aktivierter Debug Modus in Produktion gehört zu den häufigsten und folgenreichsten Fehlern, weil er Konfigurationswerte, Umgebungsvariablen und Quellcode Auszüge zeigen kann.
• Serverpfade und Dateinamen
• Datenbankfehler mit Tabellen oder Spaltennamen
• Versionsinformationen in Fehlerseiten, etwa die Fußzeile einer Standardfehlerseite des Webservers
• Diagnose Seiten wie phpinfo.php oder Server Status Seiten

Wie gute Fehlerseiten aussehen

Für Besucher: eine freundliche, schlichte Seite mit einem kurzen Hinweis und Wegen zurück. Für dich: ausführliche Protokolle im Hintergrund, die nur du lesen kannst. Dazu eine einheitliche Antwort für Dinge, die existieren, aber nicht erlaubt sind, und Dinge, die es nicht gibt, wo es sinnvoll ist (wobei hier Nutzerfreundlichkeit und Schutz abzuwägen sind).

Praxisbeispiel: Der vergessene Debug Schalter Eine Entwicklerin zieht eine Anwendung auf den Live Server um und vergisst, den Debug Modus abzuschalten. Wenige Wochen später löst ein Bot durch zufällige Anfragen eine Fehlerseite aus. Sie zeigt nicht nur die Fehlermeldung, sondern auch Teile der Konfiguration samt Datenbankzugang. Seitdem steht bei jedem Umzug eine Mini Checkliste am Anfang: Debug aus, Fehleranzeige aus, Testdaten weg, Testkonten weg, Standardpasswörter geändert.

15. DNS und Email Sicherheit: die unsichtbare Infrastruktur

Jetzt kommen wir zu einem Bereich, den erstaunlich viele Website Betreiber links liegen lassen, obwohl er über Erreichbarkeit, Vertrauen und Emailzustellung entscheidet. Wir arbeiten an diesem Thema auch mit unserem DNS Werkzeug DNSMAP.DE, und wir wissen deshalb, wie oft hier Kleinigkeiten für große Probleme sorgen.

Was ist DNS, und warum gehört es zur Sicherheit?

DNS (Domain Name System) ist das Telefonbuch des Internets. Es übersetzt einen Namen wie beispiel.de in die Adresse des Servers, auf dem die Seite liegt. Wer die DNS Einträge einer Domain kontrolliert, kontrolliert, wohin Besucher und Emails geleitet werden. Das macht DNS zu einem attraktiven Ziel und zu einem Bereich, in dem kleine Fehler große Folgen haben.

Die wichtigsten DNS Eintragstypen auf einen Blick

Typ	Wofür er da ist	Sicherheitsrelevanz
A und AAAA	Verweisen auf die IPv4 und IPv6 Adresse des Servers	Alte Einträge, die auf nicht mehr genutzte Server zeigen, sind ein Risiko
CNAME	Leitet einen Namen auf einen anderen Namen um	Verwaiste Einträge ermöglichen die Übernahme von Subdomains
MX	Bestimmt, welcher Server die Emails der Domain annimmt	Falsche Einträge leiten Emails um oder lassen sie verschwinden
TXT	Freier Text, genutzt für SPF, DKIM, DMARC und Bestätigungen	Hier leben die Schutzmechanismen für Emails
NS	Benennt die Nameserver der Domain	Wer die Nameserver kontrolliert, kontrolliert alles
CAA	Legt fest, welche Zertifizierungsstellen Zertifikate ausstellen dürfen	Schützt vor unerwünscht ausgestellten Zertifikaten

Subdomain Übernahme: Der Klassiker unter den DNS Fehlern

Stell dir vor, du hattest einst eine Subdomain shop.beispiel.de, die per CNAME auf einen externen Dienst zeigte. Irgendwann hast du den Dienst gekündigt, den DNS Eintrag aber stehen lassen. Jetzt zeigt der Name ins Leere. Kann ein Fremder bei diesem Dienst dasselbe Ziel neu registrieren, liefert er unter deiner Subdomain seine eigenen Inhalte aus. Das nennt man Subdomain Takeover. Das Ergebnis: Seiten mit deinem guten Namen, aber fremdem Inhalt, bis hin zu Phishing Seiten mit gültigem Zertifikat.

Die Gegenmittel sind unspektakulär: DNS Einträge regelmäßig ausmisten, beim Kündigen eines Dienstes immer auch den DNS Eintrag entfernen, und alle Subdomains inventarisieren.

Absicherung der Domain selbst

• Zwei Faktor Anmeldung beim Domain Anbieter. Wer dein Registrar Konto übernimmt, übernimmt deine Domain.
• Domain Sperre (Transfer Lock) aktivieren, damit die Domain nicht unbemerkt zu einem anderen Anbieter umziehen kann.
• Automatische Verlängerung einschalten und Zahlungsdaten aktuell halten. Abgelaufene Domains werden gern von Fremden übernommen, samt Emailadressen und Reputation.
• Kontakt Emailadresse prüfen, denn an sie gehen die wichtigen Warnungen.
• DNSSEC ist eine Erweiterung, die DNS Antworten kryptografisch signiert, damit sie unterwegs nicht gefälscht werden können. Sie schützt vor bestimmten Manipulationen, ist aber keine Pflicht für jede Seite und kann bei falscher Einrichtung die ganze Domain unerreichbar machen. Nutze sie, wenn dein Anbieter sie zuverlässig unterstützt und du sie verstehst.

Email Sicherheit: SPF, DKIM und DMARC

Jetzt der Teil, der viele Betreiber überrascht: Emails sind von Haus aus erschreckend leicht zu fälschen. Das Protokoll, mit dem Emails verschickt werden, prüft ursprünglich nicht, ob der Absender wirklich zur angegebenen Domain gehört. Jeder kann eine Mail mit der Absenderadresse info@deinedomain verschicken (na gut, mit deiner eigenen Domain). Drei Verfahren schließen diese Lücke. Sie arbeiten zusammen, und jedes beantwortet eine eigene Frage.

Verfahren	Die Frage, die es beantwortet	Wie es funktioniert
SPF	Darf dieser Server im Namen der Domain senden?	Ein TXT Eintrag listet die erlaubten Absender Server auf
DKIM	Wurde die Mail unterwegs verändert, und stammt sie wirklich aus dieser Domain?	Der sendende Server signiert die Mail, der öffentliche Schlüssel liegt im DNS
DMARC	Was soll mit Mails geschehen, die SPF und DKIM nicht bestehen?	Ein TXT Eintrag legt die Richtlinie fest und liefert Berichte

SPF (Sender Policy Framework) ist die Gästeliste. Beispiel:

v=spf1 include:_spf.mailanbieter.de ~all

Das heißt: Erlaubt sind die Server deines Mailanbieters, alle anderen sind verdächtig. Die Endung bestimmt die Strenge. Die weiche Variante markiert Unbekannte als verdächtig, die harte weist sie ab. Wichtig zu wissen: SPF darf insgesamt nur zehn DNS Abfragen auslösen. Wer viele Dienste einträgt (Newsletter Tool, Rechnungsprogramm, Helpdesk, Mailanbieter), überschreitet die Grenze schneller, als man denkt, und dann bricht SPF komplett. Außerdem gilt: Pro Domain nur ein SPF Eintrag.

DKIM (DomainKeys Identified Mail) ist das Siegel. Der Mailserver signiert jede ausgehende Mail mit einem privaten Schlüssel. Der passende öffentliche Schlüssel liegt im DNS unter einem Namen, der einen sogenannten Selector enthält. Der Empfänger prüft die Signatur. Stimmt sie, ist die Mail echt und unverändert. Verwende Schlüssel mit 2048 Bit, wenn dein Anbieter das unterstützt.

DMARC (Domain based Message Authentication, Reporting and Conformance) ist der Türsteher, der SPF und DKIM zusammenführt und zusätzlich verlangt, dass die Domain im sichtbaren Absender zu einem der beiden Verfahren passt. Beispiel:

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

Das p steht für die Richtlinie und hat drei Stufen: none (nur beobachten und Berichte schicken), quarantine (verdächtige Mails in den Spamordner) und reject (verdächtige Mails abweisen). Der richtige Weg ist schrittweise: Starte mit none und lies die Berichte, bis du weißt, welche Systeme in deinem Namen senden. Erst dann geht es über quarantine zu reject.

TYPISCHER FEHLER Typischer Fehler: DMARC auf reject, ohne zu wissen, wer alles sendet Wer zu früh streng stellt, sperrt seine eigenen Newsletter, Rechnungsmails oder Kontaktformulare aus. Erst beobachten, dann verschärfen. Und vergiss nicht, dass auch das Kontaktformular deiner Website Emails im Namen deiner Domain verschickt: Läuft es über einen Server, der nicht in SPF steht, landen die Nachrichten im Spam oder gar nicht beim Empfänger.

Warum ist das heute wichtiger denn je? Große Mailanbieter stellen seit 2024 (Google und Yahoo) und seit 2025 auch Microsoft für Massenversender klare Anforderungen an SPF, DKIM und DMARC. Wer sie nicht erfüllt, riskiert, dass legitime Mails abgelehnt werden. Und unabhängig davon schützt eine saubere Konfiguration vor dem Missbrauch deiner Domain für Phishing, das im Namen deiner Firma an deine Kunden geht.

Expertentipp: Prüfe die Mails wirklich Schicke eine Testmail an ein Postfach bei einem großen Anbieter, öffne den vollständigen Header und suche nach den Ergebnissen für SPF, DKIM und DMARC. Dort steht jeweils pass oder fail. So siehst du nicht nur, ob die Einträge existieren, sondern ob sie auch greifen. Die DNS Einträge selbst kannst du jederzeit mit einem DNS Abfragewerkzeug wie DNSMAP.DE einsehen.

16. Backups: die vergessene Sicherheitsfunktion

Jetzt zu dem Kapitel, das niemand sexy findet und das eines Tages dein Retter oder dein Totengräber sein wird. Wenn alles andere schiefgeht (Angriff, Ransomware, Fehlbedienung, Serverdefekt, versehentliches Löschen), entscheidet das Backup, ob du in einer Stunde wieder online bist oder in drei Wochen nicht mehr existierst.

Die meisten Betreiber fragen nur: Gibt es ein Backup? Die richtigen Fragen sind andere:

• Wie oft wird gesichert? Das bestimmt, wie viele Daten du im schlimmsten Fall verlierst (Fachbegriff RPO, Recovery Point Objective). Ein Shop mit täglichen Bestellungen braucht andere Intervalle als eine Visitenkarten Seite.
• Wie schnell bist du wieder online? Das ist die Wiederherstellungszeit (RTO, Recovery Time Objective). Ein Backup, dessen Rückspielen zwei Tage dauert, ist bei einem Shop ein Problem.
• Wo liegt das Backup? Ein Backup auf demselben Server ist kein Backup, sondern eine zweite Kopie im brennenden Haus.
• Ist es vom Server getrennt? Kann ein Angreifer mit Zugang zum Server auch das Backup löschen oder verschlüsseln, hilft es bei Ransomware nichts.
• Ist es verschlüsselt? Ein Backup enthält dieselben Daten wie das Original und braucht denselben Schutz.
• Wie lange wird es aufbewahrt? Manche Schäden fallen erst nach Wochen auf. Wer nur das letzte Backup hat, sichert im Zweifel den Schaden mit.
• Wurde die Wiederherstellung getestet?

Und die letzte Frage führt zum wichtigsten Satz dieses Kapitels: Ein Backup, das noch nie erfolgreich zurückgespielt wurde, ist nur eine Annahme.

Die 3 2 1 Regel

Ein bewährtes Grundmuster: Drei Kopien deiner Daten (das Original und zwei Backups), auf zwei verschiedenen Arten von Speichermedien oder Systemen, und eine davon an einem anderen Ort (zum Beispiel bei einem anderen Anbieter oder in einer anderen Region). Moderne Erweiterungen fordern zusätzlich eine unveränderbare Kopie (immutable), die sich auch mit Admin Rechten nicht löschen lässt, sowie null Fehler beim Test der Wiederherstellung.

Was alles ins Backup gehört

• Dateien der Website (Code, Uploads, Medien)
• Datenbanken
• Konfigurationsdateien (Webserver, PHP, Cron Jobs)
• Zugangsdaten und Schlüssel (sicher verwahrt, nicht im selben Archiv unverschlüsselt)
• DNS Einträge als Export oder Notiz
• Emailkonten, falls sie auf demselben Server liegen

Praxisbeispiel: Das Backup, das nur in der Vorstellung existierte Ein Betreiber hat ein Backup Plugin eingerichtet, das jede Nacht eine Sicherung erzeugt. Ein Jahr lang sieht alles gut aus. Dann fällt der Server aus, und beim Zurückspielen zeigt sich: Das Plugin hat die Sicherungen im selben Verzeichnis gespeichert, das mit dem Server verloren ist, und die letzten Sicherungen waren unvollständig, weil die Datenbank größer wurde als das Zeitlimit des Skripts. Nach so einem Erlebnis gilt die Regel: Backups nur ernst nehmen, wenn die Wiederherstellung mindestens zweimal im Jahr auf einer Testumgebung geübt wurde.

Typische Backup Fehler

• Backups im öffentlichen Webverzeichnis. Dateien wie backup.zip sind von außen abrufbar. Damit ist das Backup ein Datenleck.
• Nur das Hosting Backup. Die automatische Sicherung des Hosters hilft, hat aber oft kurze Aufbewahrungszeiten und ist nicht unter deiner Kontrolle.
• Nie getestet. Siehe oben.
• Zugang zum Backup Speicher mit denselben Zugangsdaten wie zum Server. Wer einen hat, hat beide.
• Kein Plan. Wer stellt im Ernstfall wie wieder her? Eine halbe Seite Anleitung, die vor dem Ernstfall geschrieben wurde, ist mehr wert als jede Hektik danach.

17. Monitoring und Protokollierung: Wer nichts sieht, merkt nichts

Eine sichere Website ist nicht nur geschützt, sondern auch beobachtet. Der Unterschied ist der zwischen einer Haustür mit gutem Schloss und einer mit gutem Schloss plus Kamera. Ohne Überwachung erfährst du von einem Einbruch, wenn die Polizei klingelt, oder wenn ein Kunde anruft, oder wenn Google eine Warnung anzeigt.

Was du beobachten solltest

• Erreichbarkeit (Uptime): Ein Dienst, der die Seite alle paar Minuten abruft und dich bei Ausfall benachrichtigt.
• Zertifikatsablauf: Eine Warnung mindestens 14 Tage vor Ablauf.
• Login Versuche: Viele Fehlversuche in kurzer Zeit, Logins aus ungewöhnlichen Ländern oder zu ungewöhnlichen Zeiten.
• Ungewöhnliche Anfragen: Massenhafte Zugriffe auf Login oder Suchfunktion, Anfragen nach bekannten Schwachstellen Pfaden.
• Serverfehler: Plötzlich viele 500er Fehler deuten auf Probleme oder Angriffe hin.
• Dateiänderungen: Eine Prüfung, die meldet, wenn sich Dateien im Code Verzeichnis ändern, ohne dass du ein Update eingespielt hast (File Integrity Monitoring).
• Aktivitäten von Administratoren: Wer hat wann was geändert? Neue Benutzer mit Adminrechten sind ein Alarmzeichen.
• Ressourcen: CPU, Arbeitsspeicher, Speicherplatz. Plötzlich volle Platten oder dauerhaft hohe Last können auf Missbrauch hindeuten, etwa auf Schadsoftware, die deinen Server für fremde Zwecke nutzt.
• Ungewöhnlicher Traffic: Ein jäher Anstieg ohne erkennbaren Grund.
• Externe Signale: Die Google Search Console meldet Sicherheitsprobleme. Richte sie ein und lies die Benachrichtigungen.

Protokolle richtig handhaben

Protokolle (Logs) sind dein Gedächtnis. Sie sollten so lange aufbewahrt werden, dass du einen Vorfall zurückverfolgen kannst, und zugleich nicht länger, als es Datenschutz und Zweck erlauben, denn IP Adressen sind personenbezogene Daten. Ein vernünftiger Ansatz: kurze, dokumentierte Aufbewahrungsfristen, Schutz der Logs vor Änderung und Zugriff, und eine feste Stelle, die sie auswertet.

Und ein oft vergessener Punkt: Logs dürfen keine sensiblen Daten enthalten. Passwörter, vollständige Kartendaten oder Tokens in Logdateien sind ein eigenes Datenleck.

Expertentipp: Alarme, die keiner liest, sind keine Alarme Lieber drei Benachrichtigungen, die wirklich wichtig sind und sofort bearbeitet werden, als dreißig, die im Postfach versauern. Lege fest, wer alarmiert wird, wie (Mail, Push, Chat) und was die erste Handlung ist.

18. Der praktische Website Sicherheitscheck: deine Checkliste

Jetzt wird es konkret. Nimm dir einen Kaffee und arbeite die folgende Liste ab. Für jede Zeile gibt es drei Ergebnisse: Erfüllt, Teilweise oder Offen. Wichtig ist Ehrlichkeit: Teilweise ist auch dann die richtige Antwort, wenn es nur auf der Startseite klappt.

Nr	Prüfpunkt	Was du konkret prüfst	Ergebnis
1	HTTPS	Alle Seiten nur per HTTPS, saubere 301 Weiterleitung, keine Mixed Content Fehler	Erfüllt / Teilweise / Offen
2	TLS Version	Mindestens TLS 1.2 aktiv, ältere Versionen aus, SSL Labs Test	Erfüllt / Teilweise / Offen
3	Zertifikat	Automatische Erneuerung läuft, komplette Kette, alle Subdomains abgedeckt	Erfüllt / Teilweise / Offen
4	HSTS	Header vorhanden, Laufzeit sinnvoll, Subdomains bedacht	Erfüllt / Teilweise / Offen
5	Content Security Policy	Vorhanden, nicht verwässert, getestet	Erfüllt / Teilweise / Offen
6	Weitere Security Header	nosniff, Referrer Policy, Permissions Policy, Frame Schutz	Erfüllt / Teilweise / Offen
7	Server Version	Keine Versionsangaben in Headern und Fehlerseiten	Erfüllt / Teilweise / Offen
8	Betriebssystem und Webserver	Unterstützte Version, Sicherheitsupdates laufen	Erfüllt / Teilweise / Offen
9	PHP oder Laufzeitumgebung	Version mit aktivem Support	Erfüllt / Teilweise / Offen
10	CMS, Plugins, Themes	Alles aktuell, Ungenutztes entfernt, keine verlassenen Erweiterungen	Erfüllt / Teilweise / Offen
11	Ports und Firewall	Nur notwendige Ports offen, Datenbank nicht öffentlich	Erfüllt / Teilweise / Offen
12	SSH	Schlüssel statt Passwort, kein Root Login, Schutz vor Dauerbeschuss	Erfüllt / Teilweise / Offen
13	Login Schutz	Begrenzung der Versuche, gleiche Fehlermeldungen, kein Standardkonto admin	Erfüllt / Teilweise / Offen
14	Zwei Faktor Authentifizierung	Mindestens für Administratoren aktiv	Erfüllt / Teilweise / Offen
15	Passwort Speicherung	Argon2id oder bcrypt, keine Klartext oder Schnellhashes	Erfüllt / Teilweise / Offen
16	Zugriffskontrolle	Zwei Konten Test bestanden, Adminfunktionen serverseitig geschützt	Erfüllt / Teilweise / Offen
17	Eingaben	Prepared Statements, Ausgabe Escaping, CSRF Schutz	Erfüllt / Teilweise / Offen
18	Uploads	Erlaubnisliste, Umbenennen, keine Ausführung im Ordner, Größenlimit	Erfüllt / Teilweise / Offen
19	Datenbank	Eigener Benutzer, minimale Rechte, keine Root Nutzung	Erfüllt / Teilweise / Offen
20	Geheimnisse	Nicht im Code oder Repository, .env nicht abrufbar	Erfüllt / Teilweise / Offen
21	Cookies	Secure, HttpOnly, SameSite gesetzt	Erfüllt / Teilweise / Offen
22	Fehlerseiten	Debug aus, keine Pfade oder Traces sichtbar	Erfüllt / Teilweise / Offen
23	DNS	Keine verwaisten Einträge, Domain Sperre, 2FA beim Anbieter	Erfüllt / Teilweise / Offen
24	SPF, DKIM, DMARC	Alle drei eingerichtet, Test bestanden, Richtlinie sinnvoll	Erfüllt / Teilweise / Offen
25	Backups	Getrennt vom Server, verschlüsselt, Wiederherstellung getestet	Erfüllt / Teilweise / Offen
26	Monitoring	Uptime, Zertifikat, Logins und Dateiänderungen überwacht	Erfüllt / Teilweise / Offen

So wertest du aus

Zähle, wie viele Punkte Erfüllt sind. Zum Beispiel: Sicherheitsstatus 18 von 26 Prüfungen erfüllt, 5 teilweise, 3 offen. Das ist eine gute Momentaufnahme und eine noch bessere To do Liste.

Aber, und das ist uns wichtig: Wir verkaufen dir keinen Security Score als Gütesiegel. Eine Website mit 92 Prozent ist nicht automatisch sicher. Ein einziger offener Punkt, zum Beispiel ein ungeschützter Adminbereich, kann mehr Schaden anrichten als fünfundzwanzig erfüllte. Nicht jede Prüfung wiegt gleich. Lies die Liste deshalb so: Zuerst die offenen Punkte, die Zugang oder Daten betreffen (Login, Zugriffskontrolle, Datenbank, Geheimnisse, Uploads), dann Updates und Server, danach Header, DNS und Feinschliff.

Werkzeuge für deinen Check

Alle folgenden Werkzeuge sind kostenlos oder haben eine kostenlose Stufe. Setze sie nur bei eigenen Seiten ein.

• SSL Labs Server Test für TLS, Zertifikat und Protokolle
• securityheaders.com und Mozilla Observatory für Security Header und Grundeinstellungen
• Browser Entwicklerwerkzeuge für Header, Cookies und Quelltext
• DNSMAP.DE für den Blick auf deine DNS Einträge
• SEOPEN.DE als schneller Domain Audit für einen ersten Überblick
• MXToolbox oder Ähnliche für SPF, DKIM und DMARC Prüfung
• OWASP ZAP als frei verfügbarer Schwachstellenscanner für eigene Anwendungen (mit Bedacht einsetzen, am besten auf einer Testumgebung, denn aktive Scans können Daten verändern)
• nmap für offene Ports deines eigenen Servers
• WPScan oder die Sicherheitsfunktionen deines CMS für bekannte Lücken in Plugins
• composer audit und npm audit für Abhängigkeiten
• Lynis für eine Härtungsprüfung von Linux Servern

Noch ein ehrlicher Satz zu automatischen Scannern: Sie finden viel, aber nicht alles. Logikfehler wie die fehlende Besitzprüfung bei Rechnungen entdeckt kein Scanner, weil er nicht weiß, wem welche Rechnung gehört. Dafür brauchst du den Zwei Konten Test und gesunden Menschenverstand.

19. Was eine Website niemals vollständig sicher macht

Zeit für einen ehrlichen Teil. Wer dir hundert Prozent Sicherheit verspricht, verkauft dir etwas. Denn:

• Es gibt Schwachstellen, die noch niemand kennt (sogenannte Zero Day Lücken). Gegen sie hilft nur ein gestaffeltes Schutzkonzept.
• Menschen sind Teil des Systems. Die beste Technik nützt wenig, wenn jemand auf eine täuschend echte Mail antwortet und sein Passwort preisgibt.
• Angreifer haben Zeit und Motivation, du hast ein Tagesgeschäft.
• Jede Änderung erzeugt neue Risiken. Ein Update, ein Plugin, eine neue Funktion.

Sicherheit bedeutet deshalb nicht Unverwundbarkeit. Sie bedeutet:

• Risiken reduzieren, durch aktuelle Software und saubere Konfiguration
• Angriffsflächen minimieren, indem du abschaltest und löschst, was du nicht brauchst
• Fehler erkennen, durch Monitoring und Protokolle
• Auswirkungen begrenzen, durch geringste Rechte und getrennte Systeme
• Wiederherstellen können, durch getestete Backups und einen Notfallplan

Vor und Nachteile im Überblick: Sicherheit hat ihren Preis

Jede Schutzmaßnahme kostet etwas, und wir wollen dir nichts verschweigen. Die folgende Übersicht hilft bei der Entscheidung.

Maßnahme	Vorteil	Nachteil oder Aufwand
Zwei Faktor Authentifizierung	Stoppt die meisten Passwortangriffe	Etwas mehr Aufwand beim Login, Wiederherstellung bei Geräteverlust muss geplant werden
Strenge Content Security Policy	Starke Abwehr gegen XSS	Erfordert Testen und Pflege, kann Drittanbieter Skripte blockieren
HSTS mit Preload	Schließt die Lücke beim Erstaufruf	Schwer rückgängig zu machen, alle Subdomains müssen HTTPS können
Automatische Updates	Patches kommen sofort	Selten können Updates etwas verändern oder brechen, daher Backup und Monitoring
Web Application Firewall (WAF)	Filtert viele bekannte Angriffsmuster	Kein Ersatz für sauberen Code, kann legitime Anfragen blockieren
Sicherheits Plugins	Bündeln nützliche Funktionen wie Login Schutz	Ein Plugin ist auch Software mit eigenen Risiken und ersetzt keine Grundpflege
Kurze Logaufbewahrung	Datenschutzfreundlich	Weniger Material für die Ursachenforschung

Woran du erkennst, dass etwas nicht stimmt

• Die Seite leitet Besucher auf fremde Seiten um, besonders von Suchmaschinen aus.
• Google zeigt eine Warnung oder Suchergebnisse mit fremden, fremdsprachigen Titeln.
• Neue, unbekannte Benutzer mit Administratorrechten tauchen auf.
• Dateien haben ein neues Änderungsdatum, ohne dass du etwas gemacht hast.
• Deine Domain verschickt Spam, und Kunden melden Mails, die du nie geschrieben hast.
• Der Hoster meldet auffällige Aktivität oder sperrt dein Konto.
• Die Seite ist plötzlich langsam, der Server ausgelastet.

Notfallplan: Was tun, wenn es trotzdem passiert?

Ruhe bewahren, und dann der Reihe nach:

1. Eindämmen: Seite in den Wartungsmodus oder vom Netz nehmen, wenn Besucher gefährdet sind.
2. Beweise sichern: Protokolle und eine Kopie des aktuellen Zustands sichern, bevor du aufräumst. Sie brauchst du, um die Ursache zu finden.
3. Zugangsdaten ändern: Alle Passwörter, API Schlüssel, Datenbankzugänge, Serverschlüssel. Von einem sauberen Gerät aus.
4. Ursache finden: Wie kamen die Angreifer hinein? Ohne Antwort passiert es wieder.
5. Sauber wiederherstellen: Am besten aus einem nachweislich sauberen Backup, die Lücke schließen, alles aktualisieren. Nur Aufräumen ist riskant, denn Angreifer hinterlassen gern Hintertüren.
6. Melden, wo nötig: Sind personenbezogene Daten betroffen, gilt die Meldepflicht der DSGVO mit einer Frist von 72 Stunden an die Aufsichtsbehörde, und unter Umständen sind Betroffene zu informieren. Hol dir im Zweifel rechtlichen Rat.
7. Nachbereiten und beobachten: Was lernen wir, was ändern wir? Engmaschiges Monitoring für die nächsten Wochen.

Die häufigsten Website Sicherheitsfehler im Überblick

Zum Abschluss des Hauptteils eine Zusammenfassung der Fehler, die wir immer wieder sehen, samt Gegenmittel.

1. HTTPS mit Sicherheit verwechseln. Gegenmittel: Die Kapitel 4 bis 15 abarbeiten.
2. Updates aufschieben. Gegenmittel: Feste Wochentermine, Automatik für Sicherheitsupdates.
3. Unnütze Plugins und alte Testseiten behalten. Gegenmittel: Löschen, was nicht gebraucht wird.
4. Schwache oder wiederverwendete Passwörter ohne zweiten Faktor. Gegenmittel: Passwort Manager, 2FA, Passkeys.
5. Nur den Login schützen, nicht die Berechtigungen dahinter. Gegenmittel: Serverseitige Prüfung bei jeder Anfrage, Zwei Konten Test.
6. Eingaben ungeprüft verwenden. Gegenmittel: Prepared Statements, Escaping, Validierung.
7. Uploads ohne Schutzschichten. Gegenmittel: Erlaubnisliste, Umbenennen, keine Ausführung im Ordner.
8. Zugangsdaten im Code oder Repository. Gegenmittel: Umgebungsvariablen, Rotation nach Leck.
9. Debug Modus und Fehlermeldungen in Produktion. Gegenmittel: Umzugs Checkliste, Logs statt Anzeige.
10. Offene Ports und öffentlich erreichbare Datenbanken. Gegenmittel: Firewall, Default Deny.
11. Vergessene DNS Einträge und fehlende Email Authentifizierung. Gegenmittel: Regelmäßiges Aufräumen, SPF, DKIM, DMARC.
12. Backups, die nie getestet wurden. Gegenmittel: Wiederherstellungsübung zweimal im Jahr.
13. Kein Monitoring. Gegenmittel: Wenige, wirksame Alarme mit klarem Zuständigen.

Fünf Sicherheitsmythen, die sich hartnäckig halten

Mythos 1: Wir sind zu klein, uns greift keiner an. Die meisten Angriffe sind automatisiert. Bots durchsuchen das Netz nach bekannten Lücken, ohne zu wissen, wem die Seite gehört. Klein schützt nicht, Aktualität schon.

Mythos 2: Es ist noch nie etwas passiert. Das zeigt nur, dass du es noch nicht bemerkt hast, oder dass du Glück hattest. Viele Kompromittierungen bleiben lange unentdeckt.

Mythos 3: Ein Sicherheits Plugin erledigt alles. Es kann helfen, ersetzt aber weder Updates noch gute Passwörter noch sauberen Code.

Mythos 4: Google würde mich warnen. Google warnt bei bekannten, erkannten Problemen, und oft erst, wenn der Schaden da ist. Ein Fehlen einer Warnung ist kein Sicherheitszeugnis.

Mythos 5: Passwörter müssen ständig gewechselt werden. Häufige erzwungene Wechsel führen zu schwächeren Passwörtern. Besser: lang, einzigartig, mit zweitem Faktor und Wechsel nach Verdacht.

Experten Tipps mit hohem Nutzwert

Wenn du nur zehn Minuten hast, nimm diese Tipps mit. Sie haben das beste Verhältnis von Aufwand zu Wirkung.

1. Schalte 2FA für alle Administratoren ein, heute. Das ist die einzelne wirksamste Maßnahme gegen Kontoübernahmen.
2. Lösche, was du nicht brauchst: alte Plugins, Testseiten, Backups im Webverzeichnis, verwaiste Subdomains.
3. Mache das Zwei Konten Experiment mit deiner Anwendung. Es dauert zwanzig Minuten und findet die teuersten Fehler.
4. Rotiere Geheimnisse, die jemals im Code oder in einem Chat gelandet sind.
5. Stelle ein Backup einmal komplett wieder her, auf einem Testsystem, und stoppe die Zeit.
6. Setze Security Header im Testmodus auf und verschärfe nach einer Woche.
7. Lege eine security.txt an, damit Sicherheitsforscher wissen, wohin mit einem Fund. Ein Fund bei dir ist besser als ein Fund bei Dritten.
8. Trenne Test und Live, inklusive Zugangsdaten.
9. Dokumentiere dein Setup: Was läuft wo, wer hat Zugang, wo liegen Backups, wer wird im Notfall angerufen. Wenn du es nicht aufschreiben kannst, kannst du es auch nicht schützen.
10. Gehe den Sicherheitscheck alle drei Monate erneut durch. Sicherheit ist ein Zustand, der ohne Pflege verfällt.

Häufige Fragen zur Website Sicherheit (FAQ)

Wie sicher ist eine Website mit HTTPS?

HTTPS schützt nur die Übertragung zwischen Browser und Server vor Mitlesen und Manipulation. Es macht die Website selbst nicht sicher. Lücken in Software, Logins, Zugriffsrechten, Eingaben und Konfiguration bleiben bestehen, auch mit gültigem Zertifikat.

Wie kann ich prüfen, ob meine Website sicher ist?

Gehe die Checkliste aus Kapitel 18 durch: TLS und Header mit kostenlosen Online Tests prüfen, Software Stände kontrollieren, Login, Zugriffsrechte, Uploads und Fehlerseiten testen, DNS und Email Einträge ansehen und die Wiederherstellung eines Backups üben. Prüfe nur eigene Seiten oder solche, für die du eine schriftliche Erlaubnis hast.

Was sind die häufigsten Sicherheitslücken bei Websites?

Veraltete Software und Plugins, schwache Passwörter ohne zweiten Faktor, fehlerhafte Zugriffskontrolle, ungeprüfte Eingaben (SQL Injection, XSS), unsichere Datei Uploads, Geheimnisse im Code, Fehlkonfigurationen wie Debug Modus oder offene Ports und fehlende Backups.

Woran erkenne ich, ob meine Website gehackt wurde?

Typische Hinweise sind fremde Weiterleitungen, unbekannte Administratoren, geänderte Dateien ohne dein Zutun, Google Warnungen, fremde Inhalte in Suchergebnissen, Spam Versand über deine Domain und auffällige Serverlast. Fehlen sie, heißt das nicht, dass alles in Ordnung ist, weil manche Angriffe gezielt unsichtbar bleiben.

Was ist der wichtigste Schutz für eine Website?

Den größten Hebel haben aktuelle Software, starke Anmeldung mit zweitem Faktor, korrekte Zugriffsrechte, getestete Backups und Monitoring. Eine einzelne Maßnahme reicht nie, die Kombination macht es.

Reicht ein Sicherheits Plugin aus?

Nein. Ein Plugin kann Login Schutz, Firewall Regeln und Dateiprüfung liefern, behebt aber keine schlecht programmierten Erweiterungen, keine veralteten Server und keine Bedienfehler. Es ist selbst Software, die aktuell gehalten werden muss.

Brauche ich eine Web Application Firewall?

Sie ist sinnvoll, vor allem bei Shops und Seiten mit vielen Besuchern, weil sie bekannte Angriffsmuster filtert und Lastspitzen abfedert. Sie ersetzt aber keine Updates und keinen sicheren Code, sondern ergänzt sie.

Was ist der Unterschied zwischen HTTP und HTTPS?

HTTP überträgt Daten im Klartext, HTTPS verschlüsselt sie mit TLS. Bei HTTPS können Dritte im Netzwerk weder mitlesen noch unbemerkt verändern, und das Zertifikat belegt, dass der Server zur Domain gehört.

Was ist eine Content Security Policy?

Eine Anweisung per HTTP Header, die dem Browser sagt, von welchen Quellen Skripte, Bilder und andere Inhalte geladen werden dürfen. Sie begrenzt den Schaden von XSS Angriffen, weil fremder Code nicht ausgeführt wird.

Wie oft sollte ich meine Website aktualisieren?

Sicherheitsupdates so schnell wie möglich, idealerweise automatisch oder innerhalb weniger Tage. Sonstige Updates mindestens einmal pro Woche oder Monat nach festem Rhythmus, größere Sprünge zuerst auf einer Testumgebung.

Was kostet Website Sicherheit?

Die Grundlagen kosten vor allem Zeit, nicht Geld: Updates, 2FA, Header, Backups, saubere Konfiguration. Zusätzliche Kosten entstehen für Hosting mit Schutzfunktionen, externe Backups, Monitoring Dienste oder professionelle Prüfungen bei sensiblen Anwendungen. Ein Schaden durch einen Vorfall ist in aller Regel deutlich teurer als Vorsorge.

Sind kleine Websites ein Ziel für Hacker?

Ja, weil Angriffe überwiegend automatisiert laufen. Bots suchen nach bekannten Schwachstellen in Software, Plugins und Konfigurationen, unabhängig von Größe und Branche. Kleine Seiten werden oft missbraucht, um Spam zu verschicken, Schadcode zu verteilen oder als Sprungbrett zu dienen.

Was ist SQL Injection einfach erklärt?

Die Anwendung baut eine Datenbankabfrage aus Benutzereingaben zusammen, und ein Angreifer schmuggelt dabei eigene Datenbankbefehle hinein. Verhindert wird das mit Prepared Statements, die Befehl und Daten strikt trennen.

Was sind SPF, DKIM und DMARC?

Drei DNS basierte Verfahren gegen gefälschte Emails. SPF legt fest, welche Server senden dürfen, DKIM signiert Mails kryptografisch, und DMARC bestimmt, wie mit Mails umgegangen wird, die beide Prüfungen nicht bestehen. Zusammen schützen sie deine Domain vor Missbrauch und verbessern die Zustellung.

Wie oft sollte ich Backups machen?

So oft, wie du Datenverlust verkraften kannst. Bei aktiven Shops täglich oder öfter, bei selten geänderten Seiten wöchentlich. Entscheidend sind Aufbewahrung an einem anderen Ort, Verschlüsselung und regelmäßige Test Wiederherstellungen.

Ist WordPress unsicher?

Nicht per se. Der Kern wird aktiv gepflegt und schnell gepatcht. Risiken entstehen meist durch veraltete oder schlechte Plugins und Themes, schwache Zugänge und fehlende Updates. Gut gepflegt kann WordPress solide betrieben werden.

Was tun, wenn meine Website gehackt wurde?

Seite eindämmen, Beweise sichern, alle Zugangsdaten ändern, die Ursache finden, sauber aus einem Backup wiederherstellen und Lücke schließen. Bei betroffenen personenbezogenen Daten gilt eine Meldefrist von 72 Stunden. Der ausführliche Ablauf steht im Kapitel 19.

Darf ich fremde Websites auf Sicherheit testen?

Nur mit ausdrücklicher Erlaubnis des Betreibers. Unbefugtes Testen kann strafbar sein. Passives Betrachten öffentlicher Informationen ist etwas anderes als aktives Scannen oder Ausprobieren von Schwachstellen, und im Zweifel gilt: lieber nicht, oder vorher fragen.

Zusammenfassung: Das nimmst du mit

• HTTPS ist der Anfang, nicht das Ziel. Es schützt den Transportweg, nicht die Anwendung.
• Sicherheit ist die Summe vieler Schichten: Server, Software, Login, Berechtigungen, Eingaben, Uploads, Daten, Geheimnisse, Netzwerk, DNS, Backups und Monitoring.
• Die meisten Angriffe sind banal: bekannte Lücken, schwache Passwörter, Fehlkonfigurationen, vergessene Dateien.
• Zugriffskontrolle ist das Kapitel mit dem größten Schaden: Prüfe jede Anfrage serverseitig, und teste mit zwei Konten.
• Nichts Sensibles gehört in Code, Frontend oder öffentlich erreichbare Dateien, und Geheimnisse in öffentlichen Repositories gelten als kompromittiert.
• Email Authentifizierung (SPF, DKIM, DMARC) und saubere DNS Einträge schützen Domain, Ruf und Zustellung.
• Ein Backup zählt erst, wenn es erfolgreich wiederhergestellt wurde.
• Was du nicht beobachtest, kannst du nicht erkennen: Monitoring macht aus einer geschützten eine überwachte Website.
• Hundert Prozent Sicherheit gibt es nicht, aber du kannst Risiken drastisch senken, Schäden begrenzen und im Ernstfall schnell wieder online sein.

Und noch einmal zur Ausgangsfrage, wie sicher eine Website wirklich ist: Eine Website ist nicht deshalb sicher, weil HTTPS aktiv ist, ein Virenscanner nichts findet, Google keine Warnung zeigt, der Browser ein Schloss anzeigt oder sie bisher noch nicht gehackt wurde. Sicherheit entsteht aus dem Zusammenspiel von Anwendung, Server, Netzwerk, Zugangsschutz, Daten, Konfiguration und Betrieb.

Dein nächster Schritt: Der 30 Minuten Plan

Du musst nicht alles heute erledigen. Aber du kannst heute anfangen. Hier ein Plan, der auch mit vollem Terminkalender funktioniert:

Heute, in 30 Minuten:

• Zwei Faktor Authentifizierung für alle Admin Konten einschalten, auch beim Hoster und Domain Anbieter
• SSL Labs Test und securityheaders.com für deine Domain durchführen und die Ergebnisse notieren
• Nachsehen, ob Dateien wie backup.zip, .env oder phpinfo.php abrufbar sind, und sie entfernen

Diese Woche:

• Alle Updates einspielen, ungenutzte Plugins und Testseiten löschen
• Zwei Konten Test durchführen
• SPF, DKIM und DMARC prüfen und DMARC auf none mit Berichten setzen

Diesen Monat:

• Wiederherstellung eines Backups auf einem Testsystem üben
• Security Header im Testmodus einführen, später verschärfen
• Monitoring und Zertifikatswarnung einrichten, eine security.txt anlegen
• Die komplette Checkliste aus Kapitel 18 ausfüllen und die offenen Punkte nach Risiko sortieren

Wenn dir dieser Guide geholfen hat, teile ihn mit Kolleginnen, Kunden oder der Webmasterin deines Vertrauens. Und wenn du bei einem der Punkte hängst, lohnt es sich, bei uns auf Dreamcodes weiterzustöbern: Wir bauen, testen und erklären, und zwar so, dass man es auch am Dienstagmorgen vor dem ersten Kaffee versteht.

Hinweis zur Einordnung: Alle Angaben in diesem Guide spiegeln den Stand 2026 wider. Standards, Laufzeiten und Empfehlungen entwickeln sich weiter, deshalb prüfe bei sicherheitskritischen Entscheidungen die aktuellen Dokumentationen der jeweiligen Hersteller und Standardisierungsstellen. Dieser Artikel ersetzt weder eine individuelle Sicherheitsberatung noch eine Rechtsberatung.