Eine Sicherheits-Checkliste für Webanwendungen ist eine feste Liste von Kontrollen, die ein Entwickler vor dem Launch und nach jedem größeren Release prüft. 2026 ist die OWASP Top 10:2025 die beste Grundlage, mit Broken Access Control auf Platz 1. Laut OWASP zeigten 100 % der getesteten Anwendungen eine Form von Broken Access Control. Eine vollständige Checkliste deckt fünf Ebenen ab. Schritt 1 ist die Zugriffskontrolle auf dem Server, die standardmäßig verweigert. Schritt 2 ist die Authentifizierung, mit MFA und sicheren Session-Cookies. Schritt 3 ist die Konfiguration mit HTTPS und Security-Headern. Schritt 4 ist Dependency-Monitoring, denn laut Patchstack steckten 2025 91 % der neuen WordPress-Schwachstellen in Plugins. Schritt 5 ist Logging, damit Sie eine Datenpanne innerhalb der 72-Stunden-Frist der DSGVO melden können. Ein Kundenportal für 200 Kunden mit Next.js und PostgreSQL braucht zum Beispiel alle fünf Ebenen.
Was ist eine Sicherheits-Checkliste für Webanwendungen?
Eine Sicherheits-Checkliste für Webanwendungen ist eine praktische Liste von Kontrollen, die jedes Release einer Web-App bestehen muss. Die Liste macht abstrakte Risiken greifbar, mit Ja-Nein-Fragen wie: Prüft jede API-Route die Rolle des Nutzers auf dem Server? Die OWASP Top 10:2025 ist 2026 die beste Grundlage für eine solche Liste. Für die Ausgabe 2025 haben Beitragende laut OWASP Daten zu mehr als 2,8 Millionen Anwendungen geliefert. Besonders wichtig ist eine Checkliste für kleine und mittlere Unternehmen, denn eine einzige geleakte Kundentabelle kann eine Meldepflicht, verlorenes Vertrauen und einen teuren Neubau auslösen. In der Praxis passt die folgende Checkliste zu jedem modernen Stack, zum Beispiel zu einem Kundenportal für 500 Nutzer mit Next.js, Node.js und PostgreSQL. Zuerst behandelt dieser Artikel die OWASP-Risiken. Danach folgen konkrete Kontrollen pro Ebene. Zum Schluss lesen Sie, was die DSGVO nach einer Datenpanne verlangt.
Was hat sich in der OWASP Top 10:2025 geändert?
Die OWASP Top 10:2025 ist die Rangliste der zehn kritischsten Sicherheitsrisiken für Webanwendungen, herausgegeben von der OWASP Foundation. Broken Access Control bleibt auf Platz 1, und Server-Side Request Forgery (SSRF) gehört jetzt zur selben Kategorie. In den Daten für 2025 zeigten laut OWASP 100 % der getesteten Anwendungen eine Form von Broken Access Control. Security Misconfiguration stieg von Platz 5 im Jahr 2021 auf Platz 2 im Jahr 2025. Zwei Kategorien sind neu: Software Supply Chain Failures und Mishandling of Exceptional Conditions. OWASP hat acht der zehn Kategorien aus gelieferten Daten abgeleitet und die übrigen zwei über eine Community-Umfrage ausgewählt. In der Praxis ist die Lehre für Unternehmer einfach. Die meisten Angriffe beginnen mit gewöhnlichen Fehlern bei Rechten, Einstellungen und Paketen von Dritten, nicht mit exotischen Methoden. Die Tabelle übersetzt jede Kategorie in eine konkrete Prüfung, zum Beispiel für eine Web-App mit Next.js.
Wie sichern Sie Zugriffskontrolle und Authentifizierung ab?
Zugriffskontrolle ist das Regelwerk auf dem Server, das festlegt, was jeder Nutzer sehen und ändern darf. Das Kernprinzip laut OWASP lautet: alles außer öffentlichen Ressourcen standardmäßig verweigern. OWASP ordnet der Kategorie 40 bekannte Schwachstellen zu und zählte in den Daten für 2025 insgesamt 1.839.701 Vorkommen. Die Prüfung muss in vertrauenswürdigem Servercode laufen, denn ein versteckter Button im Browser hält niemanden auf. Jede Abfrage sollte außerdem den Eigentümer eines Datensatzes prüfen. So kann Kunde A nie eine Rechnung von Kunde B öffnen, indem er eine ID in der URL ändert. Authentifizierung ist Schritt 2 der Checkliste. Die niederländische Datenschutzbehörde Autoriteit Persoonsgegevens (AP) definiert Multi-Faktor-Authentifizierung als Kombination aus mindestens 2 verschiedenen Arten von Authentifizierungsfaktoren. Ein Passwort plus ein Code aus Google Authenticator oder Microsoft Authenticator erfüllt diese Definition zum Beispiel. Begrenzen Sie zusätzlich die Anmeldeversuche pro IP-Adresse und pro Konto. Speichern Sie Sessions schließlich in Cookies mit den Flags Secure, HttpOnly und SameSite.
Welche Einstellungen und HTTP-Header sollten Sie prüfen?
Security Misconfiguration bedeutet, dass eine Anwendung mit unsicheren Standardwerten, offenem Speicher oder fehlenden Schutzmaßnahmen läuft, auch wenn der Code selbst sauber ist. In den Daten für 2025 zeigten laut OWASP 100 % der getesteten Anwendungen eine Form von Fehlkonfiguration. Die Kategorie stieg von Platz 5 auf Platz 2. Erstens: Liefern Sie jede Seite über HTTPS aus und ergänzen Sie einen HSTS-Header, damit Browser nie auf unverschlüsseltes HTTP zurückfallen. Zweitens: Setzen Sie eine Content-Security-Policy, die festlegt, woher Skripte laden dürfen, und so Cross-Site-Scripting bremst. Drittens: Ergänzen Sie X-Content-Type-Options, eine Referrer-Policy und frame-ancestors gegen Clickjacking. OWASP rät außerdem, Geheimnisse aus Code und Pipelines herauszuhalten und stattdessen kurzlebige Zugangsdaten oder rollenbasierten Zugriff zu nutzen. In der Praxis definieren Sie mit Next.js alle Header in einer einzigen Konfigurationsdatei. Prüfen Sie das Ergebnis nach jedem Deployment mit einem Scanner, denn ein Hosting-Wechsel kann unbemerkt einen Header entfernen.
Wie schützen Sie Abhängigkeiten, Eingaben und Fehlerbehandlung?
Ein Software Supply Chain Failure ist eine Kompromittierung der Pakete, Build-Tools oder Vertriebswege, auf die eine Anwendung angewiesen ist. OWASP hat die Kategorie 2025 aufgenommen, und genau 50 % der Umfrageteilnehmer setzten dieses Risiko auf Platz 1. Der npm-Wurm Shai-Hulud erreichte 2025 laut OWASP mehr als 500 Paketversionen. Schritt 1 ist ein committetes Lockfile. Schritt 2 ist eine Software Bill of Materials (SBOM). Schritt 3 sind automatische Warnungen über Dependabot oder Renovate. Injection ist das nächste Risiko. Bauen Sie SQL nie durch das Zusammenkleben von Strings, sondern nutzen Sie parametrisierte Abfragen über den Datenbanktreiber oder ein ORM wie Prisma. Validieren Sie jede Eingabe auf dem Server mit einem Schema, zum Beispiel mit Zod. Zum Schluss behandelt die neue Kategorie Mishandling of Exceptional Conditions Code, der im Fehlerfall offen bleibt. Eine abgestürzte Rechteprüfung muss die Anfrage blockieren, und Nutzer sehen eine neutrale Fehlermeldung ohne Stacktrace.
Was verlangt die DSGVO bei einer Datenpanne?
Die DSGVO verpflichtet den Verantwortlichen, eine Datenpanne unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden an die Aufsichtsbehörde zu melden. Die einzige Ausnahme ist eine Panne, bei der ein Risiko für die Betroffenen unwahrscheinlich ist. Fehlen anfangs Informationen, dürfen diese laut dem Bundesbeauftragten für den Datenschutz (BfDI) schrittweise nachgereicht werden. Bei Verstößen gegen die Meldepflichten drohen laut BfDI Bußgelder bis 10 Millionen Euro oder bis 2 % des weltweiten Jahresumsatzes. Die niederländische Behörde AP betont, dass Wochenende, Urlaub oder Krankheit keine gültigen Gründe für eine späte Meldung sind. Auch bei einem komplexen Vorfall wie Ransomware muss die erste, vorläufige Meldung innerhalb der 72 Stunden erfolgen. Schnelles Melden setzt gutes Logging voraus. OWASP führt Security Logging and Alerting Failures als A09:2025. Loggen Sie zum Beispiel Anmeldungen, Rechtefehler und Datenexporte, und halten Sie personenbezogene Daten aus den Logs heraus. Schicken Sie Alarme per Slack oder E-Mail an jemanden, der wirklich reagiert.
Häufig gestellte Fragen
Wie oft sollten Sie die Sicherheit einer Webanwendung prüfen?
Eine Sicherheitsprüfung ist ein wiederkehrender Review, keine einmalige Aufgabe vor dem Launch. Ein sinnvoller Rhythmus besteht 2026 aus drei Ebenen. Erstens laufen automatische Warnungen zu Abhängigkeiten dauerhaft, denn jede Woche erscheinen neue Schwachstellen. Zweitens prüfen Sie die vollständige Checkliste vor jedem größeren Release, zum Beispiel wenn eine neue Nutzerrolle, ein Zahlungsablauf oder eine API-Schnittstelle live geht. Drittens folgt mindestens einmal pro Jahr ein tieferer Review oder ein externer Penetrationstest für Anwendungen mit personenbezogenen oder finanziellen Daten. Konfigurationen sollten laut OWASP in jeder Umgebung automatisiert geprüft werden. Auch kleine Web-Apps mit Next.js oder WordPress brauchen monatliche Updates von Framework und Plugins. Patchstack zählte 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem. Zudem erhielten 46 % dieser Schwachstellen bis zur öffentlichen Bekanntgabe keinen Fix (Patchstack 2026). Halten Sie diese Arbeit in einer Wartungsvereinbarung fest, damit nach dem Launch immer jemand verantwortlich ist.
Reicht HTTPS, um eine Webanwendung abzusichern?
HTTPS ist notwendig, deckt aber nur eine Ebene der Sicherheit einer Webanwendung ab. HTTPS verschlüsselt den Verkehr zwischen Browser und Server und schützt so Passwörter und personenbezogene Daten vor dem Mitlesen im öffentlichen WLAN. Gegen Broken Access Control, das größte Risiko der OWASP Top 10:2025, hilft HTTPS nicht. Ein Angreifer mit gültigem Konto kann über eine sauber verschlüsselte Verbindung trotzdem die Daten eines anderen Kunden abrufen. HTTPS schützt auch nicht vor Injection, verwundbaren npm-Paketen oder schwachen Passwörtern. Laut OWASP zeigten 100 % der für die Ausgabe 2025 getesteten Anwendungen eine Form von Broken Access Control. Betrachten Sie das Schloss-Symbol also als ersten Punkt der Checkliste, nicht als letzten. Ergänzen Sie danach serverseitige Rechteprüfungen, MFA, Security-Header, Dependency-Monitoring und Logging, wie oben beschrieben. In der Praxis bekommt eine Next.js-App beim Hosting über Vercel oder Netlify standardmäßig HTTPS, alle anderen Prüfungen bleiben aber nötig.
Wer ist für die Sicherheit verantwortlich, wenn Sie die Entwicklung auslagern?
Der Auftraggeber ist die Partei, die nach der DSGVO für die Sicherheit verantwortlich bleibt, denn das Unternehmen, dem Anwendung und personenbezogene Daten gehören, bleibt Verantwortlicher. Schritt 1 ist, die Rollen zu klären. Hostet oder wartet die Agentur die Anwendung mit Zugriff auf personenbezogene Daten, kann die Agentur Auftragsverarbeiter sein. Verantwortlicher und Auftragsverarbeiter brauchen dann einen Vertrag zur Auftragsverarbeitung nach Artikel 28 DSGVO. Schritt 2 ist, darin konkrete Maßnahmen festzulegen, zum Beispiel MFA für Admin-Konten, verschlüsselte Backups und eine Reaktionszeit bei Sicherheitsvorfällen. Schritt 3 ist ein gemeinsamer Durchgang durch die OWASP Top 10:2025 vor dem Launch, denn laut OWASP zeigten 100 % der getesteten Anwendungen eine Form von Broken Access Control. VirtuoLab arbeitet mit einem Festpreis vorab und direktem Kontakt zum Entwickler, der die Anwendung baut. Schließlich gehören Ihnen nach der Übergabe Quellcode und Daten, sodass ein unabhängiges Audit jederzeit möglich bleibt.