OWASP ASVS erklärt: die Sicherheitscheckliste, nach der ich Webanwendungen baue

Der Kern: ASVS ist eine Checkliste, nach der ich baue, kein Abzeichen, das man besitzt

Der OWASP Application Security Verification Standard (ASVS) ist eine offene, von der Community geschriebene Liste von Sicherheitsanforderungen für Webanwendungen und die Dienste dahinter.¹ Du nutzt ihn auf drei Arten: um eine Anwendung sicher zu entwerfen und zu bauen, um den Umfang der Prüfung festzulegen, und als Einkäufer, um eine klare Sicherheitsanforderung in einen Vertrag zu schreiben.²

Jetzt der ehrliche Teil, und genau den bekommen die meisten Verkaufsseiten falsch. ASVS ist keine Zertifizierung, die man besitzt. Es gibt keine akkreditierte Stelle, die ein "ASVS Zertifikat" ausstellt, und OWASP sagt das selbst klar: als herstellerneutrale Non Profit Organisation zertifiziert OWASP weder Anbieter noch Prüfer noch Software, und jedes Gütesiegel, das eine offizielle ASVS Zertifizierung behauptet, ist von OWASP nicht anerkannt.³ Wenn ich also sage, dass ich nach ASVS baue, meine ich etwas Genaues. Ich entwickle die Anwendung gegen die Anforderungen des Standards, und ein unabhängiger Penetrationstester prüft die Anwendung gegen genau dieselben Anforderungen und hält fest, was bestanden hat und was nicht. Der Beweis ist der Prüfbericht und die behobenen Findings, nicht ein Logo.

Diese Unterscheidung ordnet ASVS klar der Ingenieursdisziplin zu, der Tier 4 Sorgfalt, nach der ich baue, und nicht den organisatorischen Zertifizierungen wie SOC 2 oder ISO 27001, die sich auf die Kontrollen einer Organisation beziehen und von externen Auditoren ausgestellt werden, die der Kunde beauftragt. Auf diesen Unterschied komme ich unten zurück, denn oft braucht man beides aus verschiedenen Gründen. Das Unternehmen im Beispiel ist erfunden. Der Standard und seine Zahlen sind mit Fußnoten belegt.

Wer ihn herausgibt, und was "offener Standard" wirklich heißt

ASVS ist ein Projekt des Open Worldwide Application Security Project (OWASP), derselben Non Profit Organisation hinter den oft zitierten OWASP Top 10, der Liste häufiger Risiken in Webanwendungen.¹⁴ Der Standard ist kostenlos. Du kannst ihn lesen, in mehreren Formaten herunterladen und darauf aufbauen, ohne eine Lizenzgebühr zu zahlen, denn er erscheint unter einer Creative Commons Attribution ShareAlike Lizenz.¹⁵

Die aktuelle Version ist ASVS 5.0.0, veröffentlicht am 30. Mai 2025 beim Global AppSec Event in Barcelona.¹ Das ist wichtig, denn 5.0.0 war eine grundlegende Überarbeitung. Die eigene Versionsregel von OWASP sagt, dass eine Hauptversion fast alles umstellen kann, auch die Nummern der Anforderungen, sodass eine Anwendung, die gegen das ältere 4.0.3 geprüft wurde, neu gegen 5.0.0 bewertet werden muss und nicht einfach als übertragbar gilt.² Wenn du ältere Beschreibungen mit vierzehn Kapiteln liest, beziehen die sich auf 4.0.3. Der aktuelle Standard hat siebzehn.

"Offen" heißt auch, dass du ausdrücklich anpassen darfst. OWASP empfiehlt sogar aktiv, dass eine Organisation den Standard forkt: beginne mit Level 1 als Basis, lass die Kapitel weg, die für dich nicht gelten, etwa OAuth oder WebRTC, wenn du beides nicht verwendest, und hebe die Latte je Anwendung nach Risiko an.² Ein angepasster ASVS, der die ursprünglichen Nummern der Anforderungen behält, ist ein Merkmal des Standards, kein Missbrauch.

Die drei Level, und wer welches wählt

ASVS sortiert seine Anforderungen in drei Level mit zunehmender Tiefe. Sie bauen aufeinander auf: um Level 2 zu erfüllen, setzt du alles aus Level 1 und Level 2 um, und Level 3 fügt den Rest hinzu.²

Level 1 ist das Minimum, ein kritischer Startpunkt mit rund 20 % der Anforderungen, bewusst klein gehalten, um die Einstiegshürde niedrig zu lassen. Das sind die Abwehrmaßnahmen der ersten Reihe gegen häufige Angriffe, die keine besondere Voraussetzung brauchen, um ausnutzbar zu sein.²

Level 2 ist das Ziel für die meisten Anwendungen, die sinnvolle Daten verarbeiten. Rund 50 % der Anforderungen liegen auf Level 2, Level 2 zu erfüllen bedeutet also, etwa 70 % des Standards umzusetzen, Level 1 und Level 2 zusammen. Diese Anforderungen decken seltenere Angriffe und die aufwendigeren Schutzmaßnahmen gegen häufige Angriffe ab.²

Level 3 ist für Systeme mit dem höchsten Wert oder der höchsten Sensibilität. Es fügt die letzten rund 30 % der Anforderungen hinzu, überwiegend tiefengestaffelte Verteidigung und Kontrollen, die nützlich, aber schwerer umzusetzen sind.²

OWASP schreibt dir nicht vor, welches Level du erreichen musst. Du sollst dein eigenes Risiko und die Erwartungen deiner Nutzer anschauen und dann entscheiden. Das eigene Beispiel von OWASP ist eindeutig: ein junges Start Up, das wenig sensible Daten sammelt, setzt sich vernünftigerweise Level 1 als erstes Ziel, während eine Bank für ihr Online Banking kaum etwas unter Level 3 rechtfertigen könnte.² Für die meisten SaaS Plattformen und Online Shops, die ich baue, ist Level 2 die richtige Vorgabe, und für die Teile, die die sensibelsten Daten berühren, greife ich in Level 3 hinein.

Die siebzehn Kapitel, und wovor jedes schützt

Die rund 350 Anforderungen sind in siebzehn Kapitel gegliedert, jedes in Abschnitte unterteilt.² Die Gliederung ist praktisch: du kannst ein ganzes Kapitel abschalten, das für dich nicht gilt, etwa das Kapitel zum Web Frontend für eine reine Maschine zu Maschine API.² Hier ist, worum es in jedem Kapitel geht, in einfachen Worten.

Kapitel	Wovor es schützt
V1 Encoding and Sanitization	Injection und Cross Site Scripting: Daten werden für die Stelle kodiert, an der sie landen, damit Eingaben nie als Code gelesen werden.6
V2 Validation and Business Logic	Fehlerhafte Eingaben und gebrochene Geschäftsregeln, damit niemand einen Schritt überspringt oder einen unmöglichen Wert einschickt.
V3 Web Frontend Security	Angriffe, die im Browser laufen, abgewehrt mit Security Headern, einer Content Security Policy und sicherem Umgang mit der Seite.
V4 API and Web Service	Schwache APIs hinter der Anwendung, inklusive REST und GraphQL, damit kein Endpunkt zur offenen Hintertür wird.
V5 File Handling	Unsicheres Hochladen, Speichern und Ausliefern von Dateien, damit ein Upload keinen Code ausführt und keine fremden Dateien liest.
V6 Authentication	Schwacher Identitätsnachweis: Passwortregeln, Mehrfaktor Authentifizierung und Schutz gegen Raten und Credential Stuffing.
V7 Session Management	Gestohlene oder veraltete Sitzungen, durch korrektes Ausstellen, Schützen und Beenden von Sitzungen.
V8 Authorization	Gebrochene Zugriffskontrolle, damit niemand an fremde Daten oder eine reine Admin Aktion kommt.
V9 Self contained Tokens	Gefälschte oder wiedereingespielte Tokens wie JWTs, die ihre Angaben selbst tragen.
V10 OAuth and OIDC	Falsche Nutzung der Protokolle OAuth und OpenID Connect für delegierten Zugriff und Single Sign On.
V11 Cryptography	Falsche oder schwache Verschlüsselung, Hashing und Schlüsselverwaltung, damit geschützte Daten geschützt bleiben.
V12 Secure Communication	Daten, die unterwegs gelesen oder verändert werden, durch korrekte Transportsicherheit (TLS).
V13 Configuration	Eine Anwendung, die offen ausgeliefert wird: sichere Voreinstellungen, Umgang mit Geheimnissen und Abhängigkeiten.
V14 Data Protection	Nachlässiger Umgang mit sensiblen Daten in Speicher, Caches und Antworten, eng am Datenschutzrecht.
V15 Secure Coding and Architecture	Ganze Fehlerklassen, durch Architektur und sichere Programmierentscheidungen, die festgehalten und geprüft werden.
V16 Security Logging and Error Handling	Blinde Flecken und Lecks: Sicherheitsereignisse nützlich protokollieren, ohne Geheimnisse preiszugeben, und sicher scheitern.
V17 WebRTC	Schwache Echtzeit Audio und Video Verbindungen, für Anwendungen, die sie nutzen.

Zwei Entwurfsentscheidungen in 5.0.0 solltest du kennen. Erstens gibt es "Dokumentationsanforderungen": statt zu verlangen, dass jede Anwendung alles verschlüsselt oder jede Sitzung gleich abläuft, verlangt der Standard, dass du die getroffene Entscheidung festhältst, etwa welche Dateitypen du akzeptierst, damit ein Prüfer beides kontrollieren kann, dass die Entscheidung existiert und dass der Code dazu passt.² Zweitens ist jede Anforderung so formuliert, dass sie erreicht werden muss und ein klares Bestanden oder Nicht bestanden ergibt, und genau das macht den Standard überhaupt prüfbar.²

Wie ASVS tatsächlich verwendet wird

Der Standard zahlt sich in drei verschiedenen Rollen aus.

Für die Entwicklung ist er eine Entwurfs und Bau Checkliste. OWASP positioniert ASVS als Leitfaden für Sicherheitsarchitektur und als Grundlage für eine sichere Programmierreferenz: die Anforderungen sagen dir, welche Kontrollen eine sichere Anwendung braucht, und die begleitenden OWASP Projekte beantworten das "Wie" (die Cheat Sheet Series für das Bauen, der Web Security Testing Guide für das Prüfen).²⁷ Ich nutze die passenden Kapitel als Schwelle, bevor ein Feature ausgeliefert wird, nicht als einmal gelesenes Dokument.

Für die Prüfung ist er der Umfang der Verifizierung. Ein guter ASVS Bericht nennt das angestrebte Level, listet jede geprüfte Anforderung, markiert jede als bestanden oder nicht bestanden, hält die nicht anwendbaren fest (etwa Session Management in einer zustandslosen API) und gibt Hinweise, wie Lücken zu schließen sind.³ Das ist ein deutlich nützlicheres Ergebnis als ein klassischer Penetrationstest, der nur meldet, was ihm zufällig auffällt.

Für den Einkauf ist er eine Anforderung, die du schriftlich festhalten kannst. OWASP sagt das deutlich: ein Käufer kann schlicht verlangen, dass die Software nach ASVS Level X entwickelt wird, und den Verkäufer bitten, das nachzuweisen.² Genau diese Klausel landet immer öfter in Verträgen größerer Kunden, und deshalb muss sich plötzlich auch ein kleiner Zulieferer um ASVS kümmern: die Anforderung kommt vom größeren Kunden.

Durchgerechnetes Beispiel: ein Linzer SaaS für Hausverwaltung prüft auf Level 2

Ein Linzer Unternehmen betreibt eine SaaS Plattform, mit der unabhängige Hausverwaltungen Mietverhältnisse, Bonitätsauskünfte und Kautionszahlungen verwalten, auf einer Domain wie hausdesk.example. Sie hält Namen, Adressen und Bankdaten der Mieter und wickelt Kartenzahlungen über einen Zahlungsdienstleister ab, verarbeitet also sinnvolle personenbezogene Daten, ohne ein reguliertes Finanzinstitut zu sein. Level 2 ist das richtige Ziel.

Der Auslöser ist kommerziell. Eine österreichweite Hausverwaltungsgruppe bietet einen Vertrag an, der den Umsatz der Plattform verdoppeln würde, und das Sicherheitsblatt der Gruppe verlangt, dass die Software "nach OWASP ASVS Level 2 entwickelt und unabhängig verifiziert" ist. Niemand verlangt ein Abzeichen. Verlangt wird ein Nachweis.

Ich beginne mit einer Lückenanalyse gegen die siebzehn Kapitel auf Level 1 und Level 2. Die Plattform kodiert Ausgaben bereits und nutzt parametrisierte Datenbankabfragen (V1 und V4 sehen gesund aus) und läuft komplett über TLS (V12). Die Lücken sind die üblichen. Admins melden sich nur mit Passwort an, es fehlt also die Mehrfaktor Authentifizierung (V6). Ein Mieter kann das Dokument eines fremden Mietverhältnisses laden, indem er die Nummer in einer URL ändert, ein Fehler der gebrochenen Zugriffskontrolle (V8). Hochgeladene Mietverträge werden ohne Prüfung des Dateityps zurückgeliefert (V5). Sicherheitsereignisse werden kaum protokolliert, ein Vorfall wäre im Nachhinein unsichtbar (V16). Jede Lücke wird zu einem Fix mit einem Test, der beweist, dass sie geschlossen bleibt.

Erst wenn die Lücken geschlossen sind, hole ich einen unabhängigen Penetrationstester dazu, und ich gebe ihm die Dokumentation und den Quellcode, keine verriegelte Haustür. ASVS ist eindeutig, dass dokumentations oder quellcodegestütztes Testen, mit Zugang zu den Entwicklern, deutlich mehr des Standards verifiziert als ein Stochern von außen, besonders die Anforderungen auf Level 2 und Level 3, die automatische Werkzeuge allein nicht erreichen.³ Der Tester arbeitet die Anforderungen im Umfang durch, bestätigt die Fixes, findet zwei weitere Punkte und schreibt den Bericht, den die Gruppe verlangt hat. Ich behebe die zwei Findings, der Tester prüft nach. Der Vertrag kommt auf Basis eines Berichts zustande, nicht einer Behauptung.

Wer prüft, und was ein unabhängiger Pen Test kostet

Manche ASVS Anforderungen lassen sich mit automatischen Werkzeugen prüfen. Statische und dynamische Analysewerkzeuge in der Build Pipeline (SAST und DAST) fangen manche Probleme ab, die nie existieren sollten, etwa bestimmte Fehler beim Kodieren.³ Aber OWASP ist deutlich, dass "mit Automatisierung prüfbar" nicht dasselbe ist wie "ein Werkzeug von der Stange laufen lassen": die schwereren Anforderungen, allen voran Geschäftslogik und Zugriffskontrolle, brauchen Prüfungen, die speziell für deine Anwendung geschrieben sind, und für echte Sicherheit einen menschlichen Tester mit Zugang zu Dokumentation und Code.³ Ein großer Teil von ASVS muss von Hand verifiziert werden.

Den unabhängigen Teil beauftragt der Kunde. Ein Tester, der dieselbe Anwendung baut und abnimmt, ist nicht unabhängig, und genau deshalb ist die Verifizierung für einen Käufer überhaupt etwas wert. Die ehrliche Kostenrechnung hat also zwei Zeilen: mein Bau nach dem Standard, und ein getrenntes Honorar, das der Kunde dem Tester zahlt.

Für das Honorar des Testers sind die am besten belegten Zahlen die Tagessätze auf dem Beschaffungsmarktplatz der britischen Regierung. Im G Cloud Rahmen führt Pen Test Partners das Testen von Webanwendungen mit 1.200 £ pro Tag, Spezialrollen bis 1.500 £ pro Tag, und weist darauf hin, dass eine Berufshaftpflicht im Satz enthalten ist.⁸ Das ist eine britische Zahl, zur Orientierung rund 1.400 € pro Tag, und ein österreichischer Tester liegt in einer ähnlichen Größenordnung. Eine gezielte Verifizierung einer einzelnen Anwendung dauert meist mehrere Tage, eine realistische Spanne für ein kleines SaaS liegt also bei einigen Tausend Euro bis in den niedrigen fünfstelligen Bereich, je nach Umfang und danach, ob ein Nachtest enthalten ist. Lass dir den Preis in Testertage und einen Tagessatz aufschlüsseln, dann vergleichst du Gleiches mit Gleichem. Eine größere oder sensiblere Plattform mit Ziel Level 3 kostet mehr, weil es mehr Anforderungen zu verifizieren gibt und mehr davon Handarbeit brauchen.

ASVS neben SOC 2 und ISO 27001

Das ist der Vergleich, der Leser davon abhält, das Falsche zu kaufen. ASVS verifiziert die Sicherheit der Anwendung. SOC 2 und ISO 27001 bescheinigen die Kontrollen der Organisation.

Ein SOC 2 Bericht oder ein ISO 27001 Zertifikat sagt, dass das Unternehmen die richtigen Richtlinien, Zugriffsprüfungen, Änderungsverwaltung und Überwachung rund um seine Systeme hat. Es wird von einem unabhängigen Auditor oder einer Zertifizierungsstelle erstellt, die das Unternehmen beauftragt und bezahlt. Es sagt wenig darüber aus, ob eine bestimmte Maske in deinem Produkt für gebrochene Zugriffskontrolle anfällig ist. ASVS sagt sehr viel über diese Maske und nichts darüber, ob dein Offboarding Prozess im Personalbereich Zugänge rechtzeitig entzieht.

Sie beantworten also verschiedene Fragen, und ein Käufer will oft beides: die organisatorische Zertifizierung, um dem Unternehmen zu vertrauen, und eine ASVS Verifizierung, um der Software zu vertrauen. Ein spezialisierter Standard für Zahlungen, PCI DSS, kommt noch dazu, wenn du Kartendaten speicherst oder verarbeitest. Die kürzeste Art, die drei auseinanderzuhalten: ISO 27001 und SOC 2 betreffen die Organisation, PCI DSS betrifft die Umgebung der Karteninhaberdaten, und ASVS betrifft die Anwendung selbst.

Wo ASVS steht, und wer ihn nicht braucht

Ehrlichkeit geht in beide Richtungen, also hier, wer sich entspannen darf. Wenn du eine reine Visitenkartenseite mit Kontaktformular und ohne Login baust, ist das volle Gewicht von ASVS übertrieben, eine Handvoll Level 1 Punkte deckt dich ab. Ein sehr frühes Produkt, das noch herausfindet, ob es jemand will, setzt sich vernünftig Level 1 als erstes Ziel und steigt auf, sobald es echte Daten hält, genau wie OWASP es vorschlägt.² Der Standard ist eine Leiter, kein Alles oder Nichts Tor, und die unterste Sprosse soll leicht erreichbar sein.

Die Kehrseite sind die Kosten, klar gesagt. Nach Level 2 oder Level 3 zu bauen, bringt echte Arbeit in den Bau selbst: die Fixes, die Tests, die Dokumentationsanforderungen. Dazu zahlt der Kunde den unabhängigen Tester getrennt. Keine dieser beiden Zahlen verstecke ich. Das ist der Preis dafür, Sicherheit beweisen statt behaupten zu können, und für eine geschäftskritische Plattform ist dieser Beweis meist mehr wert, als er kostet.

Wie ich nach ASVS baue

In einem SaaS auf Ruby on Rails oder einem Shop auf Solidus ist das meiste an ASVS gewöhnliche, disziplinierte Entwicklungsarbeit, kein Produkt, das man kauft.

Authentifizierung und Autorisierung (V6 und V8) heißen Mehrfaktor Authentifizierung auf jedem Admin Pfad und Zugriffsprüfungen, die für jede Anfrage auf dem Server erzwungen werden, nie im Frontend versteckt. Kodierung und Validierung (V1 und V2) sind großteils das, was das Framework dir gibt, wenn du es richtig nutzt: parametrisierte Abfragen und kontextbezogene Ausgabekodierung. Für Kryptografie und Datenschutz (V11 und V14) bringt Rails Active Record Encryption mit, um sensible Attribute auf Anwendungsebene zu verschlüsseln, damit Bankdaten und Auskünfte nicht im Klartext liegen.⁹ Gegen die Rateangriffe, auf die die Level 1 Authentifizierung zielt, hat Rails eine eingebaute Ratenbegrenzung für Controller, die wiederholte Login und Passwort Zurücksetzungsversuche drosselt.¹⁰ Logging und Fehlerbehandlung (V16) heißt, Sicherheitsereignisse so zu protokollieren, dass sie jemand tatsächlich ansieht, und nie ein Geheimnis in ein Log zu schreiben.

Ich fahre vor jedem Internetzugang einen Penetrationstest Durchgang mit dem Kali Linux Werkzeugkasten, mit Werkzeugen wie Nmap, Burp Suite und OWASP ZAP, und jedes Finding wird mit Schweregrad und Fix dokumentiert. Dieser Durchgang ist meine eigene Qualitätsschwelle. Er ersetzt nicht die unabhängige Verifizierung des Kunden gegen ASVS, er sorgt dafür, dass der unabhängige Test deutlich weniger findet und das Gefundene kleiner ist.

Was jetzt zu tun ist

Arbeite das der Reihe nach durch.

Erstens, entscheide das Level nach deinem Risiko, nicht nach einem Prospekt: Level 1 für ein datenarmes Produkt, Level 2 für die meisten Plattformen mit sinnvollen Daten, Level 3 für die sensibelsten. Zweitens, mach eine Lückenanalyse gegen die Kapitel auf diesem Level, solange die Anwendung noch gebaut wird, denn einen Entwurfsfehler vor dem Start zu beheben, ist weit weniger teuer als danach. Drittens, halte die Entscheidungen fest, die die Dokumentationsanforderungen verlangen, damit ein Prüfer etwas zum Vergleichen hat. Viertens, beauftrage einen unabhängigen, quellcodegestützten Penetrationstest, der auf dein gewähltes Level abbildet, und plane ihn als getrennte Zeile ein, die der Kunde zahlt. Fünftens, behebe die Findings und lass nachtesten, dann bewahre den Bericht auf: dieser Bericht und die Fixes dahinter sind der Beweis, und sie sind mehr wert als jedes Abzeichen.

Wenn deine eigenen Kunden begonnen haben, einen Nachweis für die Sicherheit deiner Software zu verlangen, oder ein Vertrag jetzt ein ASVS Level nennt, dann ist das der Moment, ordentlich nach dem Standard zu bauen, statt nach einem Zertifikat zu suchen, das es nicht gibt.

Footnotes

1. OWASP, Application Security Verification Standard, Projektseite, Version 5.0.0 veröffentlicht am 30. Mai 2025, unter Creative Commons Attribution ShareAlike 4.0, https://asvs.owasp.org/ ↩ ↩² ↩³ ↩⁴

2. OWASP, Application Security Verification Standard 5.0.0, "What is the ASVS?" (Umfang, die drei Level, die siebzehn Kapitel, Dokumentationsanforderungen, Versionsstrategie, Forking, Referenzformat und Anwendungsfälle inklusive Beschaffung), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵

3. OWASP, Application Security Verification Standard 5.0.0, "Assessment and Certification" (OWASP zertifiziert weder Anbieter noch Prüfer noch Software, dazu Berichterstattung und Umfang der Verifizierung sowie die Rolle automatischer Werkzeuge und quellcodegestützter Penetrationstests), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x04-Assessment_and_Certification.md ↩ ↩² ↩³ ↩⁴ ↩⁵

4. OWASP, OWASP Top 10 Projekt, das verbreitete Bewusstseinsdokument für häufige Sicherheitsrisiken in Webanwendungen, https://owasp.org/www-project-top-ten/ ↩

5. Creative Commons, Attribution ShareAlike 4.0 International, Lizenztext, https://creativecommons.org/licenses/by-sa/4.0/ ↩

6. OWASP, Application Security Verification Standard 5.0.0, Kapitel V1 Encoding and Sanitization (Beispielanforderung v5.0.0 1.2.5 zum Schutz gegen Befehlsinjektion im Betriebssystem), https://github.com/OWASP/ASVS/blob/master/5.0/en/0x10-V1-Encoding-and-Sanitization.md ↩

7. OWASP, Web Security Testing Guide, das Begleitprojekt dazu, wie man Sicherheitskontrollen von Webanwendungen prüft, https://owasp.org/www-project-web-security-testing-guide/ ↩

8. UK Government Digital Marketplace, G Cloud, Preisdokument für Penetrationstests von Pen Test Partners (Testen von Webanwendungen 1.200 £ pro Tag, Spezialsätze bis 1.500 £ pro Tag, Berufshaftpflicht enthalten), veröffentlicht am 28. Jänner 2026, https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-15/documents/701263/429516649648249-pricing-document-2026-01-28-0919.pdf ↩

9. Ruby on Rails Guides, Active Record Encryption, guides.rubyonrails.org, https://guides.rubyonrails.org/active_record_encryption.html ↩

10. Ruby on Rails API, ActionController::RateLimiting::ClassMethods, rate_limit, api.rubyonrails.org, https://api.rubyonrails.org/classes/ActionController/RateLimiting/ClassMethods.html ↩