Referenzen & Quellen

OWASP-Quellen

Woher das Wissen der integrierten OWASP-Spezialisierungen stammt, zugeordnet zu den kanonischen OWASP-Seiten der Angriffe und Cheat Sheets.

Dieses Dokument ordnet jeden Angriff (www-community) und jedes Cheat Sheet (CheatSheetSeries) von OWASP einer Sicherheitskategorie zu, jeweils mit einem Link auf die kanonische öffentliche Seite. Innerhalb einer Kategorie teilen sich gleichwertige Einträge eine einzige Zeile der Checkliste: Angriffe und Cheat Sheets, die dasselbe Risiko behandeln, stehen kommagetrennt zusammen. Einträge ohne direktes Gegenstück stehen in einer eigenen Zeile.

  • Die Urheberschaft liegt bei OWASP. Die Angriffe stehen unter https://owasp.org/www-community/attacks/<attack>, die Cheat Sheets unter https://cheatsheetseries.owasp.org/cheatsheets/<cheat>.html.

1. Injection (allgemein)​


2. SQL- und Datenbank-Injection​


3. OS-Command-Injection​


4. LDAP-, XPath- und XML-Injection​


5. Cross-Site Scripting (XSS)​


6. Cross-Site Request Forgery (CSRF) und Clickjacking​


7. Um- und Weiterleitungen​


8. Zugriffskontrolle und Autorisierung​


9. Authentifizierung und Zugangsdaten​


10. Session-Management​


11. Identitätsföderation (OAuth, SAML und JWT)​


12. Kryptografie und Transportsicherheit​


13. Server-Side Request Forgery (SSRF)​


14. Path Traversal und Dateiverarbeitung​


15. Missbrauch des HTTP-Protokolls (Header, Caching, Splitting)​


16. Kodierung und Content-Spoofing​


17. CSV- und Tabellenkalkulations-Injection​


18. CORS (Cross-Origin Resource Sharing)​


19. Denial of Service​


20. Speichersicherheit und nativer Code​


21. Mobile Code und Ausführung nicht vertrauenswürdigen Codes​


22. Deserialisierung​


23. Malware und clientseitige Bedrohungen​


24. Logging, Abstreitbarkeit und Fehlerbehandlung​


25. Geschäftslogik und Missbrauch von Funktionen​

Geschäftslogik und Missbrauch von Funktionen haben keine einzelne Angriffsfläche im Code, die eine Spezialisierung pro Angriffsfläche verteidigen könnte: Die Abwehr liegt im anwendungsspezifischen Design, nach derselben Überlegung, die auch die Bedrohungsmodellierung des Projekts leitet. Verschoben nach "Außerhalb des Geltungsbereichs".


26. KI-, LLM- und Agentensicherheit​


27. Prototype Pollution und Cross-Site Leaks​


28. Frameworks und Sprachplattformen​


29. Web-Frontend und Browser​


30. APIs und Dienste​


31. Cloud, Container und Infrastruktur​

Die Konfiguration von Containern und Workloads ist Configuration as Code, die Entwickler mit der App ausliefern (Dockerfile, Compose, securityContext des Pods), eine echte Angriffsfläche, die harden behebt und verify nachweist, und gehört deshalb zum Geltungsbereich. Die Cluster-Administration (RBAC, etcd, API-Server, Admission, Netzwerksegmentierung) ist Sache der Betreiber und bleibt außerhalb des Geltungsbereichs.


32. Lieferkette und CI/CD​


33. Secrets und Konfiguration​

Die Verwaltung von Secrets ist Betriebsaufgabe: Vaults, CI/CD, Cloud-Konfiguration, Rotation. Der einzige Aspekt auf Code-Ebene (ein fest im Quellcode hinterlegtes Secret) ist Sache eines deterministischen Durchlaufs, keiner Risiko-Spezialisierung. Verschoben nach "Außerhalb des Geltungsbereichs".


34. Prozesse, Design und Governance​

Der Schutz der Privatsphäre von Nutzern ist eine Frage von Richtlinien und Design (Datenminimierung, Transparenz, Aufbewahrung), keine Angriffsfläche im Code, die eine Spezialisierung verteidigt. Verschoben nach "Außerhalb des Geltungsbereichs".


35. Zahlungen und Compliance​


36. Embedded-Systeme, IoT und Spezialgebiete​

Die Sicherheit von Fahrzeugen und Drohnen gehört zum Gebiet der Embedded-Systeme (CAN-Bus, OTA-Firmware, Integrität von Sensoren und Funk, physischer Zugang), nicht zum Quellcode von Web- und API-Anwendungen, den Lagune auditiert. Verschoben nach "Außerhalb des Geltungsbereichs".


Außerhalb des Geltungsbereichs (keine Angriffsfläche im Code)​

Diese Einträge sind kein Einsatzgebiet für Spezialisierungen und haben kein Kontrollkästchen: Es geht um Governance, Prozesse, betriebliche Härtung oder die Nutzung von Frameworks, ohne eine einzelne Angriffsfläche im Code, die eine Spezialisierung pro Angriffsfläche verteidigen könnte. Ihr Sicherheitswert ist real, liegt aber in Prozessen und Architektur (oder, bei einem Framework, im eigenen Skill der jeweiligen Sprache), nicht in einer Abwehr, die dieser Katalog mitliefert. Sie stehen hier als Referenz, nicht als offene Aufgaben.