OWASP - die Grundlage jeder Zeile Code, die wir schreiben
No more insecure software.
Vision des OWASP-Projekts
OWASP Kurz erklärt
Eine offene Community gegen unsichere Software
OWASP steht für Open Worldwide Application Security Project. Eine offene, gemeinnützige Community aus Fachleuten, die weltweit an einem Ziel arbeitet: Software soll nicht mehr unsicher sein.
Das bekannteste Ergebnis ist die OWASP Top 10. Dabei handelt es sich um eine Liste der zehn kritischsten Sicherheitsrisiken für Webanwendungen. OWASP selbst bezeichnet sie als Standard Awareness Document, also als gemeinsamen Wissensstand für alle, die Anwendungen bauen. Weltweit gilt sie als erster Schritt zu sichererem Code.
Alle Inhalte sind frei verfügbar, von jedem einsehbar und werden laufend aktualisiert. Kein Anbieter, keine Lizenz, keine Blackbox. Sie müssen uns nicht glauben, Sie können es nachlesen.
Vier Dinge, die OWASP und uns verbinden
- Open Source
Offene Standards, offen geprüft. Was tausende Fachleute gegenlesen, hält länger als jede Geheimrezeptur.
- Sicherheit
Sicherheit ist für uns nicht optional. OWASP benennt die Risiken, die wir in jedem Projekt ausschließen wollen, bevor jemand anderes sie findet.
- Transparenz
Sie können nachlesen, wogegen wir prüfen. Ein öffentlicher Maßstab statt eines Sicherheitsversprechens, das niemand überprüfen kann.
- Clean Code
Sicherheit entsteht in der Zeile Code, nicht im Nachhinein. OWASP macht aus gutem Vorsatz eine überprüfbare Routine.
Von der Idee bis zum Betrieb
Wo OWASP in unserem Prozess auftaucht
Warum Ihr Projekt von OWASP profitiert
- Weniger Risiko
Angreifer probieren nicht kreativ herum, sie fahren Listen ab. Automatisiert, ab dem ersten Tag nach dem Livegang. Wer die bekannten Wege schließt, fällt aus dem billigen Massenraster. Was übrig bleibt, ist Aufwand, den sich die wenigsten machen.
- Planbare Kosten
Eine Schwachstelle im Konzept kostet ein Gespräch. Dieselbe Schwachstelle nach dem Livegang kostet einen Hotfix, ein außerplanmäßiges Release und im Zweifel eine Meldung an Ihre Kunden. Der Unterschied liegt nicht in der Technik, sondern im Zeitpunkt.
- Prüfbar statt behauptet
Irgendwann kommt die Frage von außen: Ihre Versicherung, ein Ausschreibungsformular, das Security-Team Ihres größten Kunden. OWASP ist dort bekannt.
- Anschluss nach oben
OWASP ist kein Siegel, aber die Vorstufe zu einem. Soll aus Ihrem Projekt später ein zertifiziertes Produkt werden, fangen Sie nicht bei null an. Bis hin zu Common Criteria.
Der Werkzeugkasten
Sechs Projekte und was wir damit machen
- OWASP Top 10
- Die zehn kritischsten Risiken für Webanwendungen, alle drei bis vier Jahre neu erhoben. OWASP nennt sie ein Standard Awareness Document. Gemeinsamer Wissensstand, ausdrücklich kein Prüfplan.Bei uns im Einsatz: Maßstab in Konzept und Code-Review. Jede der zehn Kategorien wird gegen Ihr Projekt bewertet, statt pauschal abgehakt.
- Web Security Testing Guide
- Handbuch dafür, wie Anwendungen systematisch auf Schwachstellen geprüft werden. Der verwandte Application Security Verification Standard beschreibt in Stufen, was eine Anwendung können muss.Bei uns im Einsatz: Grundlage unserer Testfälle. Aus „wir haben getestet“ wird eine Liste, die zeigt, was geprüft wurde und was nicht.
- Dependency-Track
- Gleicht die Bibliotheken einer Anwendung laufend gegen bekannte Schwachstellen ab. Inklusive der Abhängigkeiten, die niemand bewusst eingebaut hat.Bei uns im Einsatz: Läuft produktiv gegen die Software Bill of Materials unserer Projekte. Wird eine Komponente über Nacht verwundbar, erfahren wir es vor Ihnen.
- ModSecurity
- Offene Web Application Firewall. Filtert bekannte Angriffsmuster ab, bevor sie die Anwendung erreichen.Bei uns im Einsatz: Produktiv im Einsatz, mit dem OWASP Core Rule Set. Ersetzt keine sichere Anwendung, sondern kauft die Zeit zwischen bekannter Lücke und ausgeliefertem Patch.
- Application Security
- Kein einzelnes Projekt, sondern der Rahmen dahinter: Sicherheit als Eigenschaft der Anwendung, nicht als Produkt, das man danebenstellt.Bei uns im Einsatz: Die Haltung, aus der die anderen fünf folgen. Sicherheit gehört bei uns in die Architektur, nicht in die Abnahme.
- Mobile Application Security
- Eigene Standards und ein Testleitfaden für Apps, vom Speicher auf dem Gerät bis zur Schnittstelle im Hintergrund.Bei uns im Einsatz: Auf dem Server gelten unsere Regeln, auf dem Gerät Ihrer Nutzer nicht. In App-Projekten stellen wir deshalb die unbequeme Frage zuerst: Was muss die App lokal überhaupt speichern und was passiert damit, wenn das Gerät selbst nicht mehr vertrauenswürdig ist?
Die technischen Details
Ab hier wird es etwas technischer. Wir zeigen, welche Risiken die OWASP Top 10 beschreiben, wie sie in realen Anwendungen entstehen und worauf wir bei einer Sicherheitsprüfung konkret achten. Die folgenden Erläuterungen helfen auch dabei, Risiken besser einzuordnen, technische Maßnahmen nachzuvollziehen und die richtigen Fragen an Entwicklungsteams oder Dienstleister zu stellen.
Stand: OWASP Top 10:2025. Die Liste wird alle drei bis vier Jahre überarbeitet, im Zweifel gilt die Quelle.
A01
Broken Access Control
Nutzer sehen oder tun mehr als vorgesehen: fehlende Autorisierungsprüfungen, unsichere direkte Objektreferenzen, Rechteausweitung. Seit 2025 gehört Server-Side Request Forgery ebenfalls hierher.
A02
Security Misconfiguration
Richtig gebaut, falsch verdrahtet. Standardkonten, offene Admin-Oberflächen, fehlende Security-Header, zu großzügige Berechtigungen in der Cloud.
A03
Software Supply Chain Failures
Neu. Nicht nur die verwundbare Bibliothek, sondern die gesamte Lieferkette: kompromittierte Build-Systeme, manipulierte Artefakte, transitive Abhängigkeiten, denen niemand mehr ansieht, wo sie herkommen.
A04
Cryptographic Failures
Fehlender oder schwacher Schutz von Daten im Transport und im Ruhezustand: veraltete Verfahren, schlechtes Schlüsselmanagement, Verschlüsselung an der falschen Stelle.
A05
Injection
Unvalidierte Eingaben landen dort, wo sie interpretiert werden. In der Datenbank, in der Shell, in der Template-Engine.
A06
Insecure Design
Der Fehler steckt nicht im Code, sondern im Entwurf. Kein Code-Review der Welt repariert ein Konzept, das Missbrauch nie mitgedacht hat.
A07
Authentication Failures
Anmeldung und Sitzungsverwaltung: schwache Passwortregeln, angreifbare Wiederherstellungswege, Sitzungen, die länger leben als der Nutzer sie braucht.
A08
Software or Data Integrity Failures
Updates, Pipelines und Daten ohne Integritätsprüfung. Wer Artefakte nicht signiert, vertraut auf gutes Wetter.
A09
Security Logging and Alerting Failures
Ein Angriff, den niemand bemerkt, läuft weiter. Ohne Protokollierung und Alarmierung gibt es weder Reaktion noch Forensik.
A10
Mishandling of Exceptional Conditions
Neu. Fehlerbehandlung, die im Zweifel öffnet statt schließt: verschluckte Ausnahmen, halbe Wiederherstellung, Fehlermeldungen, die zu viel verraten.
Bereit, den nächsten Schritt zu gehen?
Sie möchten wissen, wie sicher Ihre Anwendung wirklich ist oder wie sich OWASP sinnvoll in Ihr Projekt integrieren lässt? Wir schauen uns Architektur, Code und Prozesse an. Verständlich, pragmatisch und ohne Security-Theater.
Oliver Schweissgut
Gesellschafter-Geschäftsführer
Christian Seewald
Geschäftsführer