Von Hakan Akcan · Reepa Solutions
Die OWASP Top 10 ist die wichtigste Awareness-Liste in der Web-Sicherheit — eine alle paar Jahre aktualisierte Sammlung der zehn häufigsten und folgenreichsten Schwachstellen-Klassen in Web-Anwendungen. Sie wird vom Open Worldwide Application Security Project (OWASP), einer gemeinnützigen Stiftung, auf Basis empirischer Daten aus Bug-Bounty-Programmen, Pentest-Berichten und Sicherheits-Vorfällen erstellt. Für Auftraggeber, Entwicklungsteams und Sicherheits-Verantwortliche im Mittelstand ist sie der praktische Einstieg in die Frage „wo sind unsere Anwendungen am ehesten verwundbar?“ — und sie ist der faktische Referenzrahmen für „Stand der Technik“ bei Web-Anwendungs-Sicherheit, an dem sich auch DSGVO-Audits und NIS2-Bewertungen orientieren. Wie diese regulatorische Verzahnung im Detail funktioniert, beschreiben wir im Cybersecurity-Guide für den Mittelstand.
Wichtig vorab: die OWASP Top 10 ist keine Checkliste, nach deren Abarbeitung eine Anwendung „sicher“ ist. Sie ist eine Awareness-Ebene mit zehn breiten Kategorien — jede einzelne enthält wiederum dutzende konkrete Schwachstellen-Muster. Wer einen vollständigen Sicherheits-Nachweis braucht (etwa für ISO 27001 oder als Vertrags-Nachweis gegenüber Großkunden), greift zusätzlich zum detaillierteren OWASP Application Security Verification Standard (ASVS). Die Top 10 sagt „achtet auf diese zehn Kategorien“; der ASVS sagt „prüft konkret diese 250 Anforderungen“.
Die zehn Kategorien im Überblick
Die folgende Tabelle listet die zehn Kategorien der OWASP Top 10:2021 mit ihren offiziellen Bezeichnungen und einer deutschen Kurzbeschreibung. Im Anschluss erklären wir jede Kategorie ausführlicher mit Beispielen aus der Pentest-Praxis.
| ID | Englische Bezeichnung | Worum es geht (DE) |
|---|---|---|
| A01 | Broken Access Control | Nutzer kommen an Daten und Funktionen, die ihnen nicht zustehen |
| A02 | Cryptographic Failures | Verschlüsselung fehlt, ist schwach oder falsch implementiert |
| A03 | Injection | Benutzer-Eingaben werden als Code interpretiert (SQL, NoSQL, OS, LDAP) |
| A04 | Insecure Design | Sicherheits-Lücken bereits in der Architektur, nicht im Code |
| A05 | Security Misconfiguration | Default-Einstellungen, Debug-Modi, offene Admin-Interfaces in Produktion |
| A06 | Vulnerable and Outdated Components | Bekannte Schwachstellen in eingesetzten Bibliotheken und Frameworks |
| A07 | Identification and Authentication Failures | Schwache Passwörter, fehlende MFA, defekte Session-Verwaltung |
| A08 | Software and Data Integrity Failures | Updates und Pipelines ohne Integritäts-Prüfung, unsichere Deserialisierung |
| A09 | Security Logging and Monitoring Failures | Angriffe bleiben unentdeckt, weil niemand protokolliert oder hinschaut |
| A10 | Server-Side Request Forgery | Server lädt vom Nutzer kontrollierte URLs und greift dabei interne Systeme an |
Broken Access Control
Die mit Abstand häufigste Kategorie in Mittelstands-Anwendungen. Es geht darum, dass Nutzer Zugriff auf Daten oder Funktionen bekommen, die ihnen nicht zustehen — entweder Daten anderer Kunden, Funktionen anderer Rollen oder Admin-Bereiche ohne entsprechende Berechtigung.
Ein klassischer Befund: in der URL /api/orders/12345 ändert ein angemeldeter Nutzer die ID auf /api/orders/12346 und sieht die Bestellung eines fremden Kunden. Oder: das Admin-Panel /admin prüft, ob ein gültiges Login vorliegt, vergisst aber zu prüfen, ob die Rolle Admin ist — jeder eingeloggte Standard-Nutzer kommt rein.
- Zentrale Autorisierungs-Schicht statt Berechtigungs-Logik in jedem Controller wiederholt
- Default-deny: ohne explizite Berechtigung kein Zugriff
- Objekt-bezogene Prüfungen — nicht nur „darf der Nutzer Bestellungen sehen?“, sondern „darf der Nutzer DIESE Bestellung sehen?“
- Tests mit zwei Test-Accounts unterschiedlicher Rolle — wenn beide dieselbe Ressource sehen, ist die Prüfung defekt
Cryptographic Failures
Früher hieß diese Kategorie „Sensitive Data Exposure“. Sie umfasst alle Fälle, in denen sensible Daten unverschlüsselt übertragen oder gespeichert werden, in denen veraltete Algorithmen verwendet werden oder in denen die Schlüsselverwaltung kaputt ist.
Passwörter in der Datenbank im Klartext oder mit schwachem Hash (MD5, SHA-1). HTTP statt HTTPS auf Login-Seiten. TLS-Zertifikate mit veraltetem RSA-1024 oder schwachen Cipher-Suites. Verschlüsselungs-Schlüssel im Repository eingecheckt. JWT-Tokens mit dem Algorithmus „none“ akzeptiert. Wir sehen das regelmäßig in älteren PHP-Anwendungen und in selbst gebauten Authentifizierungs-Lösungen.
- HTTPS überall, HSTS mit Preload, keine HTTP-Endpoints in Produktion
- Passwörter mit bcrypt, scrypt oder Argon2 — niemals selbst hashen, niemals MD5/SHA-1
- Aktuelle TLS-Konfiguration prüfen (Mozilla SSL Configuration Generator als Referenz)
- Secrets in einem dedizierten Secret-Store (Vault, AWS KMS, Azure Key Vault) — nie im Code
Injection
Der Klassiker. Benutzer-Eingaben werden ohne sichere Trennung als Code interpretiert — sei es als SQL-Befehl, als Betriebssystem-Kommando, als LDAP-Query oder als NoSQL-Filter. Moderne Frameworks haben SQL-Injection messbar zurückgedrängt; dafür finden wir vermehrt NoSQL-, GraphQL-, Template- und Command-Injection.
Eine Suchfunktion baut SQL per String-Konkatenation: "SELECT * FROM users WHERE name = '" + input + "'". Wer als Eingabe ' OR '1'='1 schickt, bekommt alle Nutzer zurück. Oder: ein PDF-Renderer baut eine LaTeX-Datei aus Nutzer-Input, was bei manchen Engines zur Code-Ausführung führt. Oder: ein Logging-Framework wie log4j interpretiert ${jndi:ldap://...} als Ausdruck (Log4Shell-Klasse).
- Parameterisierte Abfragen / Prepared Statements überall (das ist der wirksamste Schutz)
- ORM-Layer korrekt nutzen — keine String-Konkatenation in Custom-Queries
- Allowlist-Validierung für strukturierte Eingaben (E-Mail-Format, Datumsformat, numerisch)
- Bei OS-Calls keine String-Konkatenation, sondern Parameter-Arrays an die Shell übergeben
Insecure Design
Neu seit der 2021er-Version. Diese Kategorie unterscheidet sich von den anderen, weil sie nicht eine Implementierungs-Schwäche beschreibt, sondern einen architektonischen Fehler — die Anwendung wurde so entworfen, dass sie eine bestimmte Schutzbedürftigkeit gar nicht erfüllen kann.
Eine E-Commerce-Plattform erlaubt unbegrenzte Login-Versuche auf einem Kunden-Konto. Keine Implementierung kann das später retten — es muss ein Rate-Limit oder Lockout-Konzept her, der erst in die Architektur eingebaut werden muss. Oder: ein Password-Reset-Flow sendet das neue Passwort per E-Mail — egal wie sauber die E-Mail-Auslieferung ist, das Design ist anfällig, weil die E-Mail-Strecke nicht als sicherer Kanal gilt.
- Threat-Modeling vor der Implementierung (STRIDE oder OWASP Threat-Modeling-Methodik)
- Security-Anforderungen genauso behandeln wie funktionale Anforderungen — mit Akzeptanz-Kriterien
- Architektur-Reviews mit explizitem Sicherheits-Fokus
- OWASP ASVS Level 1 als Mindest-Designkontrolle für jede Anwendung mit personenbezogenen Daten
Security Misconfiguration
Falsche oder default-belassene Konfigurationen. In unserer Pentest-Praxis die zweithäufigste Befund-Klasse nach Broken Access Control. Sie ist deshalb so verbreitet, weil moderne Software-Stacks aus dutzenden Komponenten bestehen, jede mit eigenen Konfigurations-Optionen, und kaum ein Team alle sicheren Defaults kennt.
Debug-Modi in Produktion, die ausführliche Stack-Traces leaken. Verwaltungs-Interfaces (phpMyAdmin, Adminer, Tomcat-Manager, Grafana) ohne Schutz im Internet erreichbar. Standard-Passwörter in CMS und Datenbank. CORS-Header zu locker konfiguriert. Cloud-Storage-Buckets versehentlich öffentlich. Header für Sicherheits-Kontrollen (CSP, HSTS, X-Frame-Options) fehlen.
- Härtungs-Baselines pro Technologie-Stack, automatisiert in Deploy-Pipelines geprüft
- Infrastructure as Code mit Sicherheits-Linting (tfsec, checkov, Snyk IaC)
- Continuous External Attack Surface Monitoring — etwa mit Reepa Security — um neu exponierte Konfigurations-Fehler binnen Tagen zu finden
- Regelmäßige Konfigurations-Reviews nicht nur in Produktion, sondern auch in Staging und Pre-Prod
Wo steht Ihre Web-Anwendung gegen die OWASP Top 10?
Ein fokussierter Web-Application-Pentest mit OWASP-Top-10-Ausrichtung liefert in zwei bis drei Wochen ein klares Bild — pro Kategorie geprüft, jeder Befund mit Reproduktion und Priorisierung. Festpreis-Optionen für Mittelstands-Anwendungen.
Web-Pentest anfragenVulnerable and Outdated Components
Anwendungen bestehen heute zu 60 bis 90 Prozent aus Drittanbieter-Code: Bibliotheken, Frameworks, Container-Images, Plattform-Komponenten. Jede dieser Komponenten kann Schwachstellen haben, und wenn die Versionen nicht systematisch aktualisiert werden, sammeln sich bekannte CVEs an. Log4Shell (Dezember 2021) hat exemplarisch gezeigt, wie weit eine einzelne anfällige Bibliothek reichen kann.
Ein Spring-Framework in Version 5.2 mit dem Spring4Shell-Issue, der nicht gepatcht wurde. Ein WordPress-Plugin von 2019, das seitdem keine Updates erhält. Eine Node-Anwendung mit hunderten transitiver Abhängigkeiten, von denen ein Drittel veraltet ist. Ein Docker-Image, das auf einer alten Alpine-Base mit bekannten Library-CVEs basiert. Schwachstellen-Scanner finden das innerhalb von Minuten — sobald jemand sie laufen lässt.
- Software-Bill-of-Materials (SBOM) für jede Anwendung führen, automatisiert generiert beim Build
- Continuous Dependency-Scanning in CI/CD (Snyk, Dependabot, GitHub Advanced Security, OWASP Dependency-Check)
- Patch-Policy mit Kategorisierung — kritisch innerhalb 7 Tagen, hoch innerhalb 30, mittel innerhalb 90
- Bei nicht patchbaren Komponenten — etwa Legacy-Anwendungen — kompensierende Kontrollen wie WAF-Regeln dokumentieren
Identification and Authentication Failures
Alles rund um „wer ist da“. Schwache Passwort-Policies, fehlende oder schlecht implementierte Mehrfaktor-Authentifizierung, kaputte Session-Verwaltung, vorhersagbare Session-IDs, Tokens ohne Ablauf, fehlerhafte Logout-Logik. Eine Klasse, die historisch zu vielen großen Daten-Lecks geführt hat.
Passwort-Reset-Tokens, die unbegrenzt gültig bleiben. JWT-Tokens, die nicht serverseitig invalidierbar sind, sodass ein gestohlener Token bis zum Ablauf nutzbar bleibt. „Remember me“-Cookies, die einen permanenten Login-Token enthalten ohne weitere Faktoren. Login-Endpoints ohne Rate-Limit, die Credential-Stuffing-Angriffe ermöglichen. MFA-Bypass durch parallelen Recovery-Flow, der weniger streng prüft.
- MFA verpflichtend für privilegierte Konten, optional für alle
- Passkeys / WebAuthn als modernste Form, wo Browser- und Geräte-Support es zulässt
- Session-Verwaltung serverseitig steuerbar (Token-Revocation-Liste, server-side Sessions)
- Rate-Limit auf Login, Password-Reset und 2FA-Verifikation — jedes Endpoint einzeln
Software and Data Integrity Failures
Eine eher technische Kategorie, die zwei verwandte Themen bündelt: unsichere Deserialisierung (klassisch Java/PHP/Python pickle) und integritätslose Software-Lieferketten (Updates, Plugins, CI/CD-Pipelines). Stark in den Fokus geraten durch die SolarWinds- und Codecov-Vorfälle.
Eine Java-Anwendung deserialisiert ein vom Nutzer gesendetes Objekt — wenn die Classpath die richtigen „Gadget-Chains“ enthält, führt das zu Remote-Code-Execution. Oder: ein CI/CD-Pipeline zieht ein Build-Artifact von einer öffentlichen npm-Mirror-URL ohne Signatur-Prüfung. Wer den Mirror übernimmt, kompromittiert alle Builds. Oder: WordPress lädt Plugin-Updates von einer URL ohne TLS-Pinning, anfällig für MITM in feindlichen Netzen.
- Keine Deserialisierung von Nutzer-kontrollierten Daten, oder ausschließlich getypte / sichere Formate (JSON-Schema-validiert)
- Signatur-Prüfungen für Software-Updates und CI/CD-Artefakte
- Provenance-Standards wie SLSA für die eigene Lieferkette anstreben
- Plugin- und Modul-Quellen aktiv kuratieren — nicht „erstbestes Ergebnis aus dem Marketplace“
Security Logging and Monitoring Failures
Ohne Logging und Monitoring werden Angriffe entweder nicht oder erst Monate später entdeckt. Die Mandiant- und IBM-Reports zur Dwell-Time zeigen, dass Mittelständler durchschnittlich 200+ Tage brauchen, um eine Kompromittierung zu erkennen — und der Hauptgrund ist immer derselbe: niemand sieht hin oder es wird gar nicht erst protokolliert.
Login-Versuche werden nicht geloggt, daher unbemerkt: Credential-Stuffing-Wellen. Authentifizierungs-Fehler werden geloggt, aber landen in keinem zentralen System, sondern in lokalen Files auf je 80 Servern. Logs enthalten zu viele Daten (PII, Passwörter), zu wenige (kein User-Agent, keine Quell-IP). Alerts triggern jeden Tag 500-mal, daher reagiert niemand mehr.
- Strukturiertes Logging (JSON) mit klar definierten Sicherheits-Events
- Zentrale Aggregation in einem SIEM oder einer Log-Plattform, idealerweise mit längerer Aufbewahrungsfrist
- Wenige, präzise Alerts mit klarem Runbook — nicht Schrotflinte
- Regelmäßige Tabletop-Übungen, um die Detection-Kette in Trockenphase zu testen — bevor der Ernstfall passiert
Server-Side Request Forgery (SSRF)
Neu in der 2021er-Top-10. Bei SSRF wird der Server dazu gebracht, eine URL aufzurufen, die der Angreifer kontrolliert — und dabei greift er auf interne Systeme zu, die von außen nicht erreichbar wären. In Cloud-Umgebungen besonders kritisch, weil die Metadata-Endpoints (AWS, Azure, GCP) lokale temporäre Credentials liefern, die ein erfolgreicher SSRF-Angriff abgreifen kann.
Ein Bildupload-Service akzeptiert eine URL und holt das Bild serverseitig nach. Statt einer Bild-URL übergibt der Angreifer http://169.254.169.254/latest/meta-data/iam/security-credentials/ — und bekommt AWS-Credentials des EC2-Instance-Profils zurück. Capital One 2019 ist der bekannteste Fall dieses Musters, mit über 100 Millionen kompromittierten Daten-Sätzen.
- Ausgehende HTTP-Calls aus dem Backend nur auf Allowlist erlaubter Hosts
- IMDSv2 in AWS erzwingen (Token-basiert, nicht passiv abrufbar)
- Netzwerk-Segmentierung: Backend-Services dürfen Cloud-Metadata nicht erreichen, wenn nicht zwingend nötig
- URL-Parsing und -Validierung gegen DNS-Rebinding härten — nicht nur den ersten Resolve prüfen, sondern auch nachfolgende
Was die Top 10 nicht abdeckt
Drei wichtige Lücken sollte jeder kennen, der die Top 10 als Orientierung nutzt.
API-spezifische Schwachstellen. Die klassische Top 10 fokussiert auf klassische Web-Anwendungen. Für reine APIs gibt es die separate OWASP API Security Top 10 (zuletzt 2023), die zusätzliche Klassen wie Broken Object Property Level Authorization, Unrestricted Resource Consumption und Improper Inventory Management adressiert. Wer eine REST- oder GraphQL-API betreibt, sollte beide Listen heranziehen.
KI-spezifische Risiken. Mit der Welle generativer KI-Anwendungen hat OWASP eine eigene LLM Top 10 veröffentlicht, die Prompt-Injection, Insecure Output Handling, Training-Data-Poisoning und ähnliche LLM-Risiken beschreibt. Wer Chatbots, RAG-Systeme oder eingebettete KI nutzt, kommt um die LLM-Liste nicht herum. Mehr dazu, sobald wir den entsprechenden Cluster im KI-Pillar veröffentlichen.
Geschäftslogik-Spezifika. Die Top 10 beschreibt generische Klassen — sie sagt nichts darüber, ob in einer Buchhaltungs-Anwendung jemand fremde Rechnungen freigeben kann oder ob in einem Logistik-System Sendungen umgeleitet werden können. Solche Geschäftslogik-Fehler finden nur menschliche Pentester, die die Domäne verstehen. Generische Scanner finden sie nicht. Mehr zum Verhältnis von automatisierten Tools und manuellen Tests im Cluster Penetrationstest Ablauf.
OWASP Top 10 vs OWASP ASVS — wann was?
Die Top 10 ist Awareness, der ASVS ist Prüfungs-Standard. Wer eine Software-Anwendung baut, sollte sich für ein ASVS-Level festlegen und dieses als Akzeptanz-Kriterium definieren:
- ASVS Level 1 — Basis-Anforderungen, die mit Black-Box-Test prüfbar sind. Für nicht-kritische öffentliche Anwendungen ohne personenbezogene Daten.
- ASVS Level 2 — Empfohlener Standard für die meisten Anwendungen mit personenbezogenen Daten oder finanziellen Transaktionen. Setzt Grey-Box-Test mit Code-Einsicht voraus.
- ASVS Level 3 — Für hochkritische Anwendungen (Bank, Gesundheit, kritische Infrastruktur). Erfordert umfangreiche Architektur-Reviews und White-Box-Tests.
In unserer Praxis empfehlen wir Mittelstands-Kunden mit Web-Anwendungen, die personenbezogene Daten verarbeiten, ASVS Level 2 als Mindest-Standard für Neuentwicklungen. Das ist deutlich konkreter als „wir haben die OWASP Top 10 berücksichtigt“ — und in Audits und Vertragsverhandlungen ein nachweisbares Niveau.
Was Sie heute konkret tun können
Drei pragmatische Schritte für ein Mittelstands-Unternehmen, das die OWASP Top 10 ernst nehmen will:
Erstens — automatisierte Baseline. OWASP ZAP oder Burp Suite Community auf der eigenen Hauptanwendung laufen lassen, monatlich. Bekannte Konfigurations-Probleme und einfache Eingabe-Validierungs-Lücken werden so sichtbar, bevor sie ein Angreifer findet. Dauer: 1-2 Stunden Setup, dann automatisierbar.
Zweitens — Abhängigkeits-Inventar. Dependabot oder Renovate auf jedes Repository, GitHub Advanced Security oder Snyk für tiefere Analyse. Veraltete Komponenten mit bekannten Schwachstellen werden so wöchentlich sichtbar, statt jährlich bei einem Pentest aufzutauchen.
Drittens — gezielter Pentest. Einmal jährlich (mindestens) einen externen Web-Pentest mit OWASP-Top-10-Ausrichtung beauftragen. Das deckt die Klassen ab, die Scanner nicht finden — Geschäftslogik, komplexe Zugriffs-Kontrollen, Architektur-Schwächen. Mehr zu Budget und Auswahl im Cluster Pentest Kosten.
Wer diese drei Schritte umsetzt, ist gegen die häufigsten Befund-Klassen der OWASP Top 10 erheblich besser aufgestellt als 90 Prozent der Mittelstands-Anwendungen, die wir in Erstgesprächen sehen.
Häufige Fragen
Was ist die OWASP Top 10?
Die OWASP Top 10 ist eine alle paar Jahre aktualisierte Liste der am weitesten verbreiteten und folgenreichsten Schwachstellen-Kategorien in Web-Anwendungen. Sie wird vom Open Worldwide Application Security Project (OWASP) — einer gemeinnützigen Stiftung — auf Basis empirischer Auswertung von Sicherheits-Reports, Bug-Bounty-Daten und Pentest-Befunden zusammengestellt. Sie ist kein vollständiger Sicherheits-Standard, sondern eine Awareness-Liste, die Entwicklerinnen und Entwicklern, Sicherheitsverantwortlichen und Auftraggebern die wichtigsten Klassen ins Bewusstsein rufen soll.
Reicht es, die OWASP Top 10 abzuhaken, um eine sichere Anwendung zu haben?
Nein. Die Top 10 ist eine Awareness-Liste, kein Sicherheits-Standard. Wer einen vollständigen Sicherheits-Nachweis braucht — etwa für ISO 27001, NIS2 oder Großkunden-Anforderungen — sollte zusätzlich den OWASP Application Security Verification Standard (ASVS) heranziehen, der je nach Level rund 200 bis 300 prüfbare Anforderungen enthält. Die Top 10 ist die Aufmerksamkeits-Ebene, der ASVS die Prüf-Ebene.
Wie alt ist die aktuelle OWASP Top 10?
Die letzte vollständige Aktualisierung erschien 2021 als „OWASP Top 10:2021“. Eine Folge-Version ist für die nähere Zukunft geplant und wird zusätzliche Kategorien aus den Bereichen API-Sicherheit, Supply-Chain und KI-spezifische Risiken einarbeiten. Praktiker beziehen sich heute meist auf die 2021er-Liste, ergänzt um die separate OWASP API Top 10 (zuletzt 2023) und die OWASP LLM Top 10 für KI-Anwendungen.
Welche OWASP-Kategorie ist am häufigsten?
In Mittelstands-Web-Anwendungen sehen wir in Pentests am häufigsten A01 Broken Access Control und A05 Security Misconfiguration — beide tauchen in über zwei Dritteln aller Engagements auf. Direkt dahinter folgt A06 Vulnerable Components, also veraltete Bibliotheken mit bekannten Schwachstellen. Klassische SQL-Injection (Teil von A03) sehen wir seltener als früher, weil moderne Frameworks Prepared Statements meist standardmäßig nutzen — dafür finden wir vermehrt NoSQL-, GraphQL- und OS-Command-Injection-Varianten.
Wie testet man auf OWASP-Top-10-Schwachstellen?
Eine Kombination aus automatisierten Scannern und manuellen Tests ist nötig. Scanner wie OWASP ZAP, Burp Suite Pro oder Acunetix decken Konfigurations- und einfache Eingabe-Validierungs-Probleme breit ab. Tiefergehende Schwachstellen — insbesondere Geschäftslogik-Fehler bei Zugriffs-Kontrollen und Authentifizierung — finden Scanner nicht. Hier ist manueller Test durch erfahrene Pentester unverzichtbar. Details zum Ablauf siehe unseren Artikel zum Pentest-Ablauf.
Sind die OWASP Top 10 für DSGVO oder NIS2 relevant?
Indirekt, ja. Weder DSGVO Artikel 32 noch NIS2 nennen die OWASP Top 10 explizit. Aber beide verlangen technische Maßnahmen, die dem Stand der Technik entsprechen, und für Web-Anwendungen ist die OWASP Top 10 faktisch der akzeptierte Stand-der-Technik-Referenzrahmen. Eine Anwendung mit unbehandelten A01-Befunden wird in einem Datenschutz-Audit nicht als angemessen geschützt durchgehen.
Lassen Sie Ihre Web-Anwendung gegen die OWASP Top 10 prüfen.
Ein fokussierter Web-Pentest deckt in zwei bis drei Wochen jede Kategorie der OWASP Top 10 ab — inklusive Geschäftslogik-Tests, die kein Scanner findet. Festpreis-Angebot innerhalb von 24 Stunden nach Scope-Klärung.
Web-Pentest anfragen
IT-Sicherheits- und Cloud-Architekt mit über zehn Jahren Erfahrung. Entwickelt mit seinem Team Reepa Security, eine offensive Audit-Plattform für den Mittelstand. Schreibt regelmäßig über Web-Security, OWASP-Methodik, NIS2 und Cloud-Security.
Geprüft am: 22. Mai 2026 · Mehr über Hakan