OWASP Top 10: Die häufigsten Sicherheitslücken in Webanwendungen und wirksame Gegenmaßnahmen

Was sind die OWASP Top 10 und vor welchen Risiken schützen sie?

Die OWASP Top 10 sind ein kostenloses, offenes Awareness Dokument, das die zehn kritischsten Sicherheitsrisiken für Webanwendungen als Kategorien ordnet. Die gemeinnützige OWASP Foundation stützt die Liste auf echte Testdaten und eine Community Umfrage. Also handelt es sich um eine Orientierung für Prioritäten, nicht um eine formale Norm.

Konkret arbeite ich seit 2012 an Unternehmenswebsites und E-Commerce Projekten. Dabei fiel kaum eine gehackte Website einem exotischen Angriff zum Opfer. Meist fehlte eine Berechtigungsprüfung, ein Plugin war veraltet oder das Admin Panel lief noch mit einem Standardpasswort. Deshalb nutze ich die OWASP Top 10 in jedem Projekt als Prüfrahmen.

In diesem Beitrag gehe ich die zehn Kategorien der aktuellen Liste einzeln durch. Zu jeder Kategorie erkläre ich, was sie bedeutet, wie sie in der Praxis aussieht und welche Schutzmaßnahmen Sie ergreifen können. Als Quelle dient mir vor allem die Liste auf der offiziellen Seite der OWASP Top 10:2025; von dort stammen Namen und Reihenfolge.

Zudem gilt: Dieser Text ist kein Handbuch für Penetrationstests. Mein Ziel ist konkret. Wer eine Website verantwortet, soll die Kategorien verstehen und dem Entwicklerteam die richtigen Fragen stellen können. Daher finden Sie am Ende jedes Abschnitts Prüfpunkte statt Codebeispiele.

Wie haben sich die OWASP Top 10 in der aktuellen Ausgabe verändert?

Die aktuelle Ausgabe heißt OWASP Top 10:2025. Im Vergleich zur Ausgabe von 2021 fällt vor allem eines auf: Fehler in der Software Lieferkette bilden nun eine eigene Kategorie auf Platz drei. Außerdem kommt der fehlerhafte Umgang mit Ausnahmesituationen als neue zehnte Kategorie hinzu.

Zudem hat OWASP einige Kategorien zusammengelegt. Zum Beispiel steht Server Side Request Forgery (SSRF) nicht mehr allein, sondern gehört jetzt zur fehlerhaften Zugriffskontrolle. Sicherheitsrelevante Fehlkonfiguration stieg zudem von Platz fünf auf Platz zwei. Kurz gesagt: Die Liste zeigt jetzt besser, wie moderne Websites tatsächlich angreifbar werden.

• A01: Broken Access Control, also fehlerhafte Zugriffskontrolle.
• A02: Security Misconfiguration.
• A03: Software Supply Chain Failures.
• A04: Cryptographic Failures.
• A05: Injection.
• A06: Insecure Design.
• A07: Authentication Failures.
• A08: Software or Data Integrity Failures.
• A09: Security Logging and Alerting Failures.
• A10: Mishandling of Exceptional Conditions.

Lesen Sie die Reihenfolge nicht wie eine Tabelle im Sport. Denn ein Risiko auf Platz zehn kann auf Ihrer Website trotzdem das größte sein. Daher empfehle ich, die Liste als Landkarte zu nutzen, die Sie an Ihre Anwendung anpassen.

Noch ein praktischer Hinweis: Wenn Sie Prüfberichte nach der alten Ausgabe haben, passen die Codes nicht mehr. Zum Beispiel: Die frühere A05 Fehlkonfiguration heißt jetzt A02. Vergleichen Sie Berichte deshalb nach Kategorienamen, nicht nach Codes.

Was ist fehlerhafte Zugriffskontrolle (A01) und wie verhindern Sie sie?

Fehlerhafte Zugriffskontrolle bedeutet, dass ein Nutzer Daten oder Funktionen erreicht, für die er keine Berechtigung hat. Das klassische Beispiel: Sie ändern die Bestellnummer in der Adresszeile und sehen plötzlich die Rechnung eines anderen Kunden. Fachleute nennen das IDOR, eine unsichere direkte Objektreferenz.

Am häufigsten sehe ich eine Prüfung, die nur in der Oberfläche existiert. Die Website blendet etwa den Admin Button für normale Nutzer aus, doch die API Adresse dahinter bleibt offen. Ein Angreifer braucht den Button allerdings gar nicht. Er schickt die Anfrage also einfach von Hand. Deshalb muss jede Prüfung auf dem Server laufen, und zwar bei jeder Anfrage.

• Legen Sie "verweigern" als Standardregel fest und erteilen Sie Rechte ausdrücklich.
• Prüfen Sie bei jedem Datensatz, ob er dem aktuellen Nutzer gehört.
• Nutzen Sie nicht erratbare Kennungen statt fortlaufender Nummern, aber verlassen Sie sich nicht allein darauf.
• Schützen Sie den Adminbereich mit eigenem Pfad, IP Freigabeliste oder zusätzlicher Prüfung.
• Begrenzen Sie ausgehende Anfragen Ihres Servers auf eine Freigabeliste; SSRF gehört jetzt hierher.

Nehmen Sie außerdem Rollenwechsel in Ihre Testfälle auf. Behält ein herabgestufter Nutzer in seiner alten Sitzung Adminrechte, liegt der Fehler in der Sitzungsverwaltung.

In der Praxis erleichtert eine zentrale Berechtigungsschicht vieles. Schreibt jede Seite ihren eigenen Prüfcode, vergisst irgendwann jemand eine Stelle. Eine zentrale Prüfung erfasst dagegen jeden neuen Endpunkt automatisch.

Warum ist Fehlkonfiguration (A02) so verbreitet?

Sicherheitsrelevante Fehlkonfiguration heißt: Der Code mag stimmen, aber Server, Framework oder Cloud Einstellungen lassen eine Tür offen. Ausführliche Fehlerseiten, Standardkonten, Verzeichnislisten und unnötige Dienste gehören dazu. Die aktuelle Ausgabe setzt diese Kategorie auf Platz zwei.

Der Grund ist einfach, denn Konfiguration liegt außerhalb des Codes und niemand fühlt sich zuständig. Zunächst verweist der Entwickler auf den Hoster, der Hoster auf die Anwendung. Dazwischen liegt dann eine vergessene Sicherungsdatei frei zugänglich im Webverzeichnis. Genau das habe ich in eigenen Projekten mindestens einmal selbst entdeckt.

• Schalten Sie ausführliche Fehlermeldungen im Livebetrieb ab und zeigen Sie eine allgemeine Meldung.
• Deaktivieren Sie Verzeichnislisten und entfernen Sie Sicherungen, .env und .git Ordner aus dem Webverzeichnis.
• Setzen Sie Sicherheitsheader wie Content Security Policy und HSTS.
• Entfernen Sie Dienste, Ports und Beispielseiten, die Sie nicht nutzen.
• Richten Sie Umgebungen aus einer wiederholbaren Vorlage ein, nicht von Hand.

Auch Weiterleitungsketten sind ein stilles Konfigurationsproblem. Ob HTTP direkt auf HTTPS führt, prüfen Sie in Sekunden mit dem Redirect Checker.

Achten Sie zudem besonders auf Cloud Speicher. Denn ein öffentlich lesbarer Speicherbereich kann Rechnungen und Ausweiskopien binnen Minuten offenlegen. Ich empfehle dafür eine kurze monatliche Checkliste.

Wie wirken sich Fehler in der Software Lieferkette (A03) auf Ihre Website aus?

Diese Kategorie umfasst das Risiko in Code, den Sie nicht selbst geschrieben haben, aber trotzdem ausführen. Bibliotheken, Plugins, Themes, Paketabhängigkeiten und Build Werkzeuge bilden die Glieder dieser Kette. Der frühere Punkt zu veralteten Komponenten ist in dieser breiteren Kategorie aufgegangen.

Eine WordPress Website kann zum Beispiel dreißig Plugins nutzen. Zudem stammt jedes von einem anderen Entwickler und folgt einem eigenen Updaterhythmus. Stellt einer davon die Pflege ein, bleibt Ihre Tür offen. Schlimmer noch: Ein kompromittiertes Paket landet somit über ein normales Update direkt auf Ihrem Server.

• Führen Sie ein Verzeichnis aller Komponenten und Versionen; man nennt es Software Stückliste (SBOM).
• Bauen Sie einen Abhängigkeitsscan in den Build ein und stoppen Sie ihn bei kritischen Funden.
• Legen Sie Lockfiles wie composer.lock ins Repository und fixieren Sie Versionen.
• Ersetzen Sie Plugins und Pakete, die lange kein Update erhalten haben.

Kurz gesagt: "Was läuft, fasst man nicht an" funktioniert in der Sicherheit nicht. Regelmäßige Pflege hilft außerdem der Sichtbarkeit, wie ich im Beitrag zum Aktualisieren von Inhalten beschreibe.

Bedenken Sie allerdings, dass auch Updates Risiken tragen. Testen Sie sie zunächst auf einer Stagingkopie und spielen Sie sie dann live ein. So schließen Sie die Lücke, ohne die Website zu beschädigen.

Welche Daten legen kryptografische Fehler (A04) offen?

Kryptografische Fehler entstehen, wenn sensible Daten ohne oder mit schwacher Verschlüsselung übertragen oder gespeichert sind. Passwörter, Kartendaten, Ausweisnummern und Gesundheitsdaten tragen das höchste Risiko. Meist fehlt die Verschlüsselung nicht ganz. Vielmehr setzen Teams sie an der falschen Stelle oder mit veralteten Algorithmen ein.

Das häufigste Beispiel aus meiner Praxis: Passwörter liegen als MD5 oder SHA1 ohne Salt in der Datenbank. Diese Verfahren sind schnell, allerdings ist genau das beim Speichern von Passwörtern ein Nachteil. Nach einem Leck probiert ein Angreifer Milliarden Kombinationen pro Sekunde. Nutzen Sie daher Argon2, bcrypt oder scrypt, denn diese Verfahren sind absichtlich langsam.

• Übertragen Sie den gesamten Verkehr per TLS und aktivieren Sie HSTS.
• Speichern Sie Passwörter nur mit Argon2, bcrypt oder scrypt.
• Halten Sie Schlüssel aus dem Quellcode heraus und legen Sie sie in einen Tresor für Geheimnisse.
• Speichern Sie keine sensiblen Daten, die Sie nicht brauchen; was Sie nicht speichern, kann nicht abfließen.

Starke Passwörter gehören ebenfalls dazu. Zum Beispiel kann Ihr Team Passwörter für das Panel mit dem Passwort Generator erzeugen. SPF, DKIM und DMARC für die Firmenadresse erkläre ich im Beitrag zur E-Mail mit eigener Domain.

Auch die Aufbewahrungsdauer ist ein Thema. Wer alte Kundendaten jahrelang hält, vergrößert den Schaden im Ernstfall. Mit Blick auf die DSGVO entsteht dadurch zudem ein eigenes Risiko; legen Sie deshalb früh eine Löschregel fest.

Wie schließen Sie Injection Lücken wie SQL Injection und XSS (A05)?

Injection bedeutet, dass eine Anwendung Nutzereingaben als Befehl behandelt. SQL Injection zielt auf Datenbankabfragen, Cross Site Scripting (XSS) auf die Seite im Browser. Auch Befehle an das Betriebssystem oder an LDAP fallen in diese Gruppe. Die aktuelle Ausgabe führt die Kategorie auf Platz fünf.

Die Grundregel lautet: Mischen Sie niemals Daten und Befehle. Das heißt, bauen Sie keine Abfrage, indem Sie Nutzertext in den Abfragestring kleben. Nutzen Sie stattdessen parametrisierte Abfragen, damit der Treiber Daten getrennt vom Befehl transportiert. Moderne ORM Werkzeuge tun das standardmäßig, bei eigenen Rohabfragen sollten Sie trotzdem genau hinsehen.

Bei XSS kommt es auf kontextgerechtes Escaping an. Denn innerhalb von HTML, Attributen und JavaScript gelten unterschiedliche Regeln. Schalten Sie deshalb das automatische Escaping Ihrer Template Engine nie ab. Zusätzlich begrenzt eine Content Security Policy den Schaden einer übersehenen XSS Lücke deutlich.

1. Stellen Sie jeden Datenbankzugriff auf parametrisierte Abfragen um.
2. Prüfen Sie Eingaben gegen eine Freigabeliste statt gegen eine Sperrliste.
3. Escapen Sie Ausgaben passend zum Kontext.
4. Geben Sie dem Datenbanknutzer nur die Rechte, die er braucht.

Auch Upload Felder sind ein Einfallstor. Prüfen Sie Dateiname und Dateityp erneut auf dem Server und speichern Sie Uploads in einem Ordner ohne Ausführungsrechte. Konkrete Muster finden Sie in der OWASP Cheat Sheet Series.

Lässt sich unsicheres Design (A06) mit besserem Code beheben?

Unsicheres Design heißt, dass die Logik selbst fehlerhaft ist, egal wie sauber der Code aussieht. Stützt sich etwa das Zurücksetzen eines Passworts nur auf die Frage nach dem Geburtsnamen der Mutter, kann perfekter Code diese Schwäche nicht retten. Somit betrifft diese Kategorie Entscheidungen, die vor der ersten Codezeile fallen.

In Projekten begegnet mir das am häufigsten bei Geschäftsregeln. Ein Rabattcode, der sich zehnmal auf dieselbe Bestellung anwenden lässt, ist ein gutes Beispiel. Ein Warenkorb, der negative Mengen akzeptiert, ein weiteres. Trotzdem meldet kein Scanner so etwas, denn technisch funktioniert alles.

• Führen Sie in der Konzeptphase eine Bedrohungsanalyse durch und fragen Sie: "Wie könnte jemand diesen Ablauf missbrauchen?"
• Schreiben Sie Missbrauchsfälle als Testfälle.
• Setzen Sie bei kritischen Aktionen Ratenbegrenzung und Wiederholungsprüfung ein.
• Wählen Sie Sicherheitsanforderungen aus einem Prüfstandard wie OWASP ASVS.

Deshalb setze ich Sicherheit an den Anfang eines Projekts, nicht ans Ende. Wie ich Architekturentscheidungen festhalte, zeigt mein Beitrag über Micro Frontends.

Zusammengefasst sind Designfehler die teuersten Fehler. Einen laufenden Ablauf neu zu bauen, kostet weit mehr Aufwand als eine zusätzliche Frage in der Entwurfsphase.

Wie verhindern Sie Fehler bei der Authentifizierung (A07)?

Authentifizierungsfehler erlauben es einem Angreifer, sich als jemand anderes anzumelden. Anmeldeformulare ohne Schutz vor Brute Force, Credential Stuffing mit geleakten Passwortlisten und schwache Sitzungsverwaltung gehören hierher.

Die wirksamste Einzelmaßnahme ist die Mehrfaktorauthentifizierung. Ich mache die Zweifaktoranmeldung für jedes Admin Panel verpflichtend, das ich betreue. Allein reicht sie allerdings nicht, denn Angreifer suchen andere Wege. Sie brauchen außerdem sichere Sitzungscookies und eine Grenze für Fehlversuche.

• Machen Sie Mehrfaktorauthentifizierung für Adminkonten zur Pflicht.
• Begrenzen Sie Fehlversuche pro IP und pro Konto.
• Prüfen Sie neue Passwörter gegen bekannte Leaklisten.
• Setzen Sie Secure, HttpOnly und SameSite für Sitzungscookies.
• Beenden Sie alle Sitzungen beim Abmelden und bei einer Passwortänderung.

Auch Fehlermeldungen verraten Informationen. "Diese Adresse ist nicht registriert" zeigt einem Angreifer, welche Konten existieren. Wählen Sie stattdessen eine neutrale Meldung wie "E-Mail oder Passwort falsch".

Folgen Sie zudem den aktuellen Empfehlungen zu Passwörtern. Lange Passphrasen plus Leakprüfung wirken besser als komplizierte Zeichenregeln. So schreiben Nutzer ihre Passwörter nicht mehr auf Notizzettel.

Was sind Fehler der Software oder Datenintegrität (A08)?

Integritätsfehler entstehen, wenn eine Anwendung Code oder Daten vertraut, die sie nie geprüft hat. Automatische Updates ohne Signaturprüfung, externe Skripte ohne Integritätsprüfung und unsichere Deserialisierung fallen darunter.

Die Kategorie überschneidet sich mit der Lieferkette, deshalb kurz der Unterschied. Zunächst betrachtet A03 das Risiko in der Komponente selbst. A08 fragt dagegen, ob sich Code oder Daten auf dem Weg zu Ihnen verändert haben. Lädt Ihre Seite zum Beispiel eine JavaScript Datei von einem fremden Server, trifft ein Angriff auf diesen Server sofort Ihre Besucher.

• Nutzen Sie Subresource Integrity (das Attribut integrity) für externe Skripte.
• Verlangen Sie signierte Pakete und geschützte Branches in Ihrer Build Pipeline.
• Deserialisieren Sie niemals Objekte, die direkt von Nutzern stammen.

Seien Sie also auch bei Marketing Tags vorsichtig. Jedes neue Trackingskript ist fremder Code, der auf Ihrer Seite laufen darf. Prüfen Sie regelmäßig, wer Zugriff auf Ihren Tag Manager hat.

Ein Fall, den ich oft sehe: ein Tag aus einer alten Kampagne, an das sich niemand erinnert. Schließt der Anbieter, kann seine Domain den Besitzer wechseln. Dann führt Ihre Seite weiterhin den Code eines Fremden aus.

Warum verlängern fehlende Protokolle und Alarme (A09) einen Angriff?

Fehler bei Protokollierung und Alarmierung bedeuten, dass ein Angriff keine Spur hinterlässt oder die Spur keinen Menschen erreicht. Die aktuelle Ausgabe hat das Wort "Alerting" bewusst ergänzt. Schließlich ist ein Protokoll, das niemand liest, kaum besser als gar keines.

In einem Kundenprojekt lief ein Angriff wochenlang, während die Logs alles festhielten. Allerdings schaute niemand hinein. Aufmerksam wurde das Team erst durch eine seltsame Kundenbeschwerde, nicht durch ein Sicherheitswerkzeug. Seitdem richte ich für kritische Ereignisse immer Sofortbenachrichtigungen ein.

• Protokollieren Sie fehlgeschlagene Anmeldungen, verweigerte Zugriffe und Adminaktionen.
• Speichern Sie Logs getrennt von der Anwendung an einem manipulationssicheren Ort.
• Richten Sie Alarme per E-Mail oder Chat für kritische Ereignisse ein.
• Schreiben Sie niemals Passwörter oder Kartennummern in Logs.

Beobachten Sie außerdem die Signale von Google. Die Search Console meldet Malware und gehackte Inhalte im Bericht zu Sicherheitsproblemen. Die Einrichtung beschreibe ich in meiner Search Console Anleitung.

Legen Sie zudem die Aufbewahrungsdauer der Logs vorab fest. Denn manche Angriffe fallen erst nach Wochen auf. Verschwinden die Logs nach wenigen Tagen, können Sie den Beginn des Vorfalls nicht mehr nachvollziehen.

Was bedeutet fehlerhafter Umgang mit Ausnahmesituationen (A10)?

Diese neue Kategorie beschreibt Anwendungen, die sich bei unerwarteten Ereignissen unsicher verhalten. Dazu zählen nicht abgefangene Fehler, detaillierte Fehlermeldungen für Nutzer und Fehlerpfade, die "fail open" arbeiten, also im Zweifel durchlassen.

Stellen Sie sich Code vor, der eine Bestellung als bezahlt markiert, wenn der Dienst zur Zahlungsprüfung nicht rechtzeitig antwortet. Im Normalbetrieb passiert also nichts. Kann ein Angreifer diesen Dienst jedoch verlangsamen, bestellt er gratis. Sicherer ist "fail closed": Im Zweifel lehnen Sie die Aktion ab.

• Kehren Sie in unklaren Zuständen zu einem sicheren Standard zurück: ablehnen oder anhalten.
• Zeigen Sie Nutzern eine allgemeine Meldung und schreiben Sie Details nur ins Log.
• Machen Sie halb abgeschlossene Vorgänge mit Datenbanktransaktionen rückgängig.
• Lösen Sie Ausfälle externer Dienste in der Testumgebung gezielt aus.

Besonders wichtig ist diese Kategorie bei Zahlungen, Lagerbeständen und Berechtigungen. Denn dort bedeutet ein halber Vorgang direkten Verlust von Geld oder Daten. Ergänzen Sie Ihren Testplan daher um die Frage: "Was passiert, wenn der Dienst nicht antwortet?"

Anders gesagt fragt A10 nicht "was, wenn alles klappt", sondern "was passiert, wenn etwas schiefgeht".

Die OWASP Top 10 Kategorien und Maßnahmen im Überblick

Die folgende Tabelle fasst die OWASP Top 10 mit einem typischen Beispiel aus meiner Arbeit und einer ersten Maßnahme zusammen. Sie können sie direkt in einer Prüfrunde mit Ihrem Team nutzen.

Verstehen Sie die Tabelle als Startpunkt. Hinter jeder Zeile stecken Dutzende Details, deshalb lohnt sich der Blick in die offizielle Quelle.

Ergänzen Sie außerdem eine Statusspalte: erledigt, geplant oder unbekannt. Ehrlich gesagt ist "unbekannt" die gefährlichste Antwort, denn sie zeigt, dass niemand für das Risiko zuständig ist.

Wo sollte ein kleines Team mit den OWASP Top 10 anfangen?

Kleine Teams können nicht alles gleichzeitig erledigen. Ich beginne meist mit Schritten, die viel bewirken und wenig kosten. Die folgende Reihenfolge beruht auf meiner Praxiserfahrung und ist keine Garantie; Ihr System kann andere Prioritäten verlangen.

1. Aktivieren Sie Mehrfaktorauthentifizierung für Adminkonten.
2. Aktualisieren Sie alle Plugins, Frameworks und Serverpakete und löschen Sie ungenutzte.
3. Entfernen Sie Sicherungen und Konfigurationsdateien aus dem Webverzeichnis.
4. Verbergen Sie Fehlerdetails im Livebetrieb und setzen Sie Sicherheitsheader.
5. Begrenzen Sie Anmeldeversuche.
6. Richten Sie Sofortalarme für kritische Ereignisse ein.
7. Stellen Sie Datenbankzugriffe auf parametrisierte Abfragen um.
8. Testen Sie Berechtigungen serverseitig.

Auf den meisten kleinen Websites dauern diese acht Schritte einige Arbeitstage. Der tatsächliche Aufwand hängt allerdings vom Alter des Systems und der Codequalität ab. Danach können Sie zu tieferen Tests übergehen.

Arbeiten Sie die Liste nicht nur einmal ab, sondern wiederholen Sie sie bei jedem größeren Release. Halten Sie zudem Datum und Verantwortlichen jedes Schritts in einer gemeinsamen Tabelle fest. So sieht jeder nach sechs Monaten ohne Diskussion, was erledigt ist.

Mit welchen Werkzeugen testen Sie auf OWASP Top 10 Schwachstellen?

Automatische Scanner finden technische Probleme wie Fehlkonfiguration und bekannte Injection Muster schnell. ZAP ist ein quelloffener Scanner und ein guter Einstieg. Setzen Sie Scanner allerdings nur auf Ihre eigene Website oder auf Systeme an, für die Sie eine schriftliche Erlaubnis haben.

Werkzeuge haben zudem blinde Flecken. Fehlerhafte Zugriffskontrolle und unsicheres Design sind Fehler der Geschäftslogik, und meist findet sie nur ein Mensch. Deshalb empfehle ich, automatische Scans mit einer manuellen Prüfung zu kombinieren.

• Statische Analyse (SAST): liest Code, ohne ihn auszuführen, und findet Injection Muster früh.
• Dynamische Analyse (DAST): schickt Anfragen an die laufende Website und findet Fehlkonfiguration.
• Analyse der Komponenten (SCA): listet Pakete mit bekannten Schwachstellen.
• Manueller Test: findet Fehler bei Berechtigungen und Geschäftslogik.

Zum Beispiel können Sie bei jedem Release automatisch scannen und einmal im Jahr oder nach großen Änderungen manuell testen.

Übernehmen Sie Scanergebnisse außerdem nicht blind. Denn Scanner erzeugen Fehlalarme. Ordnen Sie jeden Fund nach Schwere, schließen Sie ausnutzbare Lücken zuerst und dokumentieren Sie Fehlalarme mit Begründung.

Verliert eine über OWASP Top 10 Lücken gehackte Website ihre Rankings?

Ja, indirekt, aber spürbar. Angreifer, die über Injection oder Fehlkonfiguration eindringen, fügen oft Spamseiten, versteckte Links oder Weiterleitungen ein. Erkennt Google solche Inhalte, kann es Warnungen in den Suchergebnissen anzeigen, und das Vertrauen der Nutzer sinkt schnell.

In meiner SEO Beratung gehört Sicherheit zu den ersten Punkten, die ich nach einem plötzlichen, unerklärlichen Traffic Einbruch prüfe. Tauchen zum Beispiel Tausende unbekannte URLs in Ihrer Sitemap auf, liegt das Problem eher bei der Sicherheit als beim Inhalt. Weitere technische Prüfpunkte finden Sie in meinen Tipps zum technischen SEO.

Nach der Bereinigung können Sie über die Search Console eine Überprüfung beantragen. Schließen Sie die Lücke jedoch nicht, kommt der Angreifer auf demselben Weg zurück. Suchen Sie also zuerst den Einstiegspunkt und entfernen Sie dann die Inhalte.

Sicherheit und SEO wirken wie getrennte Abteilungen, dienen aber demselben Ziel. Bei der Erholung nach einer Bereinigung unterstütze ich im Rahmen meiner SEO Beratung.

Wie verankern Sie Sicherheit im Webdesign Prozess?

Die günstigste Schwachstelle ist die, die nie jemand schreibt. Deshalb halte ich in meinen Webdesign Projekten Sicherheitsanforderungen schon im Angebot fest. Welche Daten wir erfassen, wer worauf zugreift und welche Plugins wir einsetzen, klären wir gleich zu Beginn.

Vor der Übergabe gehe ich dann eine kurze Checkliste durch: Adminkonten, Sicherheitsheader, Backups und Updateplan. Somit erhält der Kunde nicht nur ein Design, sondern ein System mit klar geregelter Wartung.

• Halten Sie Datenbestand und Nutzerrollen im Angebot fest.
• Prüfen Sie die Wartungshistorie, bevor Sie ein Plugin oder Paket wählen.
• Benennen Sie bei der Übergabe eine verantwortliche Person für Updates.

Im ersten Monat nach dem Start führe ich Updates gern gemeinsam mit dem Team des Kunden durch, damit es die Routine direkt lernt. Außerdem schränken Sicherheitsanforderungen das Design nicht ein. Ein gut geplanter Login kann sicher und bequem zugleich sein.

Denken Sie daran: Sicherheit ist keine einmalige Aufgabe. Eine Website ohne Wartungsplan wird innerhalb weniger Monate zum Kandidaten für A03.

Fazit: Die OWASP Top 10 sind ein Prüfrahmen

Die OWASP Top 10 machen Ihre Website nicht sicher; sie zeigen Ihnen, wo Sie hinschauen sollten. Vor allem ist ihre eigentliche Stärke eine gemeinsame Sprache. Hören Entwickler, Designerin und Geschäftsführung "A01", denken alle an dasselbe Risiko.

Mein Vorschlag: Nehmen Sie die Tabelle oben, stellen Sie zu jeder Zeile die Frage "Wie steht es bei uns?" und ordnen Sie jeder Antwort eine verantwortliche Person zu. Prüfen Sie die Liste mindestens einmal im Jahr gemeinsam mit Ihrem Team.

Gute Sicherheit ist wie gutes Design dann erfolgreich, wenn niemand sie bemerkt. Ihre Besucher sehen nichts Ungewöhnliches, während Daten, Rankings und Ruf geschützt bleiben. Wenn Sie Sicherheit und SEO in Ihrem Projekt gemeinsam angehen möchten, erreichen Sie mich über die Kontaktseite.