VAPT-Kosten in den VAE für SaaS, APIs und mobile Apps: Preise und Käufer-Checkliste

Jeder SaaS-Gründer oder CTO in den VAE stellt irgendwann dieselbe Frage: Was kostet VAPT eigentlich, und lohnt es sich vor dem Launch? Die Antworten sind weniger eindeutig als eine Anbieterpreisliste vermuten lässt – und wichtiger, als die meisten Gründungsteams erkennen, bis ein Enterprise-Beschaffungsteam, ein Fintech-Regulierer oder ein Sicherheitsvorfall das Gespräch erzwingt.

Dieser Leitfaden richtet sich an technische Entscheidungsträger, die VAPT gezielt einkaufen möchten: um zu verstehen, wofür sie zahlen, was einen echten Penetrationstest von einem automatisierten Scan unterscheidet, und wie sie beurteilen können, ob der Scope eines Anbieters mit ihrer tatsächlichen Risikooberfläche übereinstimmt.

---

Was kostet VAPT in den VAE?

VAPT-Kosten VAE – Engagements bei Seven Labs werden pro Auftrag basierend auf Anzahl der Assets, Benutzerrollen, Authentifizierungskomplexität, API-Endpunktvolumen, Tiefe der Geschäftslogik und Retest-Bedingungen kalkuliert. Die Preise variieren von [Verifizierte Seven Labs AED-Preise nach Scope einfügen], abhängig davon, ob der Scope eine einzelne Webanwendung, eine REST- oder GraphQL-API, eine mobile Anwendung, Cloud-Infrastruktur oder eine kombinierte SaaS-Plattform abdeckt. Automatisiertes Scanning allein ist kein VAPT. Manuelle Exploitation, Tests der Geschäftslogik und authentifizierte Multi-Rollen-Tests treiben den Großteil sowohl der Kosten als auch des Nutzens.

---

Was ist der Unterschied zwischen Schwachstellenscan und Penetrationstest?

Vulnerability Assessment VAE – Käufer verwechseln häufig vier unterschiedliche Aktivitäten, die sich in Tiefe, Kosten und Ergebnis erheblich unterscheiden. Ein automatisierter Schwachstellenscan führt Tools gegen Ihre Angriffsfläche aus und meldet bekannte CVEs und Fehlkonfigurationen. Er kann nicht testen, ob Ihre Geschäftslogik ausnutzbar ist, ob Ihre Mandantentrennung einem authentifizierten Angriff standhält oder ob Ihre JWT-Implementierung eine Privilegienerweiterung ermöglicht. Ein Penetrationstest tut all das – manuell, aus Angreiferperspektive, durch einen menschlichen Ingenieur, der versteht, was ein echter Angreifer mit jedem Fund anfangen würde.

Die praktische Konsequenz: Ein Schwachstellenscan, der zu einem Bruchteil des Preises eines Penetrationstests angeboten wird, ist keine günstigere Version desselben Produkts. Es ist ein anderes Produkt mit einem anderen Risikoabdeckungsprofil. Für SaaS-Anwendungen, die Benutzerdaten, Zahlungsabläufe oder sensible Geschäftsvorgänge verarbeiten, stellt ein Scan allein keine aussagekräftige Sicherheitsgarantie dar.

---

Was bestimmt die Kosten eines SaaS-Penetrationstests?

SaaS-Penetrationstests sind komplexer als eine einzelne Webanwendung, da die Angriffsfläche über mehrere Dimensionen hinweg zunimmt. Das Verständnis der Kostentreiber hilft Ihnen, den Scope präzise zu definieren und zu vermeiden, dass Sie für nicht benötigte Abdeckung zahlen – oder wichtige Abdeckung auslassen.

Anzahl der Anwendungen und Schnittstellen. Eine SaaS-Plattform umfasst typischerweise eine kundenorientierte Webanwendung, ein Admin-Panel, eine API-Schicht und manchmal eine mobile Anwendung. Jede ist eine eigenständige Testoberfläche. Die Bündelung in einem Engagement reduziert den Aufwand; separate Tests erhöhen die Klarheit.

Benutzerrollen. Eine SaaS-Anwendung mit einem kostenlosen Tarif, einem zahlenden Nutzer, einem Organisations-Admin, einem Super-Admin und einem Support-Mitarbeiter hat fünf Rollenoberflächen. Tests erfordern authentifizierte Sitzungen über alle Rollen hinweg, um Schwachstellen bei der Zugriffskontrolle und Privilegienerweiterung aufzudecken. Jede zusätzliche Rolle erhöht den Testaufwand.

API-Endpunkte. REST- und GraphQL-APIs werden Endpunkt für Endpunkt getestet, einschließlich Authentifizierung, Autorisierung pro Endpunkt, Eingabevalidierung, Rate-Limiting und Datenexposition in Antworten. Eine SaaS-Anwendung mit 200+ API-Endpunkten erfordert deutlich mehr Zeit als eine mit 40.

Mandantenarchitektur. Multi-Mandanten-SaaS-Anwendungen erfordern Tests zur Mandantenisolierung. Kann Mandant A auf die Daten von Mandant B zugreifen? Kann ein Admin auf Mandantenebene auf eine Admin-Rolle auf Plattformebene eskalieren? Diese Tests erfordern ein spezifisches Setup und sind von Natur aus manuell.

Zahlungsabläufe. Jede Zahlungsintegration – Stripe, Checkout.com, Telr oder direktes Payment-Gateway – erfordert spezifische Tests auf Bestellmanipulation, Preisfälschung, Coupon-Bypass und Rückerstattungsmissbrauch. Dies ist Geschäftslogiktesting und kann nicht automatisiert werden.

Datei-Upload-Handling. Upload-Endpunkte sind durchgehend hochriskant. Tests umfassen Dateitype-Bypass, Ausführung schädlicher Dateien, Path-Traversal und Speicher-Fehlkonfiguration. Jede Upload-Oberfläche erweitert den Scope.

Admin-Panels. Admin-Oberflächen erfordern separate authentifizierte Sitzungen und spezifische Tests auf horizontale und vertikale Privilegienerweiterung, Massendatenexport und Imitationsfunktionalität.

Cloud-Infrastruktur. Wenn der Scope AWS, Azure oder GCP-Infrastruktur umfasst – IAM-Fehlkonfiguration, freigegebene Speicher-Buckets, übermäßig berechtigte Service-Accounts, Netzwerksegmentierung – erfordert das Engagement cloud-spezifische Tools und Expertise über das Web-Application-Testing hinaus.

Mobile Plattformen. Android- und iOS-Anwendungen sind separate Engagements für Binäranalyse und dynamisches Testing. Jede Plattform hat ihre eigene Testmethodik: statische Analyse, Runtime-Hooking, Certificate-Pinning-Bypass, unsicherer Speicher und API-Interaktionstests.

Quellcode-Zugang. White-Box-Testing mit Quellcode-Zugang ist schneller und deckt mehr der Codebasis ab. Grey-Box- und Black-Box-Testing ohne Quellcode benötigt länger, um vergleichbare Abdeckung zu erreichen. Quellcode-Zugang reduziert die Kosten für gleichwertige Abdeckungstiefe.

Testumgebung. Produktionstests bergen Risiken. Eine dedizierte Staging-Umgebung, die die Produktion genau spiegelt, ist der professionelle Standard. Wenn die Staging-Umgebung des Kunden beeinträchtigt ist, liegt die Verantwortung für Testabdeckungslücken beim Kunden.

Regulatorisches Mapping. Engagements, die die Zuordnung von Befunden zu UAE CBUAE-Sicherheitskontrollen, SAMA CSF, DIFC-Datenschutzanforderungen, PCI DSS, ISO 27001 oder SOC 2-Kriterien erfordern, erweitern den Berichtsumfang.

Retest-Bedingungen. Ein professionelles VAPT-Engagement beinhaltet mindestens einen Retest-Zyklus, um zu verifizieren, dass kritische und hochschwere Befunde behoben wurden. Retest-Scope, Zeitplan und ob er eingeschlossen oder separat abgerechnet wird, beeinflussen die Gesamtkosten des Engagements.

---

VAPT-Kosten nach Asset-Typ

Webanwendungs-Sicherheitstests, API-Sicherheitstests und Mobile-App-Penetrationstests werden nach Scope, Testtiefe und Retest-Bedingungen bepreist. Die nachstehende Tabelle zeigt den allgemeinen Abdeckungsrahmen für jede Asset-Kategorie zusammen mit den Engagement-Bereichen von Seven Labs.

Preise in AED. Engagements werden individuell geplant – die oben genannten Bereiche dienen der Planung. Fordern Sie ein scopebasiertes Angebot an unter /contact.

---

Was sollte ein professioneller VAPT-Bericht enthalten?

Ein Sicherheitsauditbericht aus einem professionellen Penetrationstest ist das primäre Lieferobjekt und das Dokument, das von Enterprise-Beschaffungsteams, Compliance-Beauftragten und Versicherungszeichnern geprüft wird. Ein vollständig von einem automatisierten Scanner generierter Bericht – selbst ein ausgefeilter – ist kein Penetrationstest-Bericht und entspricht nicht dem Standard, den informierte Käufer akzeptieren sollten.

Ein professioneller VAPT-Bericht enthält:

Management-Zusammenfassung. Ein nicht-technischer Überblick darüber, was getestet wurde, was gefunden wurde und die allgemeine Risikolage. Geschrieben für ein Vorstands- oder Führungspublikum.

Scope und Methodik. Genaue Definition dessen, was getestet wurde – URLs, API-Basispfade, Anwendungsversionen, mobile Paket-Identifier, Cloud-Regionen, IP-Bereiche – und die angewendete Testmethodik (Grey-Box, authentifiziert, manuelle Exploitation).

Asset-Inventar. Eine Aufzeichnung aller Assets im Scope, einschließlich solcher, die sich als außerhalb des Scopes oder unzugänglich erwiesen haben, um die Abdeckungsgrenze zu definieren.

Schwachstellenbefunde. Jeder Befund dokumentiert mit:

• CVSS-Bewertung (v3.1 Basis-, Temporal- und Umgebungswerte, soweit zutreffend)
• Beschreibung der Schwachstelle und Grundursache
• Geschäftliche Auswirkung – was ein Angreifer mit dieser Schwachstelle im Kontext dieser Anwendung tun kann
• Nachweise – Screenshots, Request/Response-Paare, Payload-Beispiele oder Videos, soweit relevant
• Reproduktionsschritte – ausreichend, damit das Entwicklungsteam den Befund replizieren kann
• Behebungsempfehlungen – spezifisch, umsetzbar und auf den Technologie-Stack abgestimmt
• Betroffene Endpunkte, Parameter oder Komponenten

Retest-Status. Nach der Behebung dokumentiert ein Retest-Abschnitt, welche Befunde als geschlossen verifiziert wurden, welche offen bleiben und welche teilweise adressiert wurden.

Einschränkungen. Alle Testbeschränkungen – ausgeschlossene Endpunkte, nicht bereitgestellte Authentifizierung, aufgetretene Rate-Limits, während des Engagements vorgenommene Scope-Reduzierungen.

Risikozusammenfassung. Eine aggregierte Übersicht der Befunde nach Schweregrad und Kategorie mit einer Priorisierungs-Roadmap für die Behebung.

Wenn ein Anbieter Ihnen vor Vertragsunterzeichnung keinen Musterbericht mit dieser Struktur zeigen kann, sollten Sie das als Warnsignal betrachten.

---

Welche Schwachstellen werden vor dem SaaS-Launch häufig übersehen?

In Seven Labs VAPT-Engagements über mehr als 50 produktive KI- und Sicherheitssysteme hinweg erscheinen mindestens 8 der folgenden 11 Schwachstellenkategorien mit hoher Häufigkeit in Pre-Launch-SaaS-Anwendungen. Die vollständige Aufschlüsselung einschließlich CVSS-Bewertung, Exploitation-Szenarien und Behebungsschritten wird im Begleitartikel behandelt: 11 kritische Schwachstellen, die die meisten SaaS-Startups vor dem Launch übersehen.

Die Kategorien selbst, mit ihrer OWASP Top 10 und OWASP API Security Top 10-Zuordnung:

BOLA/IDOR (Broken Object Level Authorization). Die am häufigsten gefundene Schwachstelle in SaaS-VAPT-Engagements. Ein Benutzer ändert eine numerische ID oder UUID in einer Anfrage und greift auf die Daten eines anderen Mandanten zu. OWASP API1:2023. CVSS 8,1–9,8.

Fehlerhafte Zugriffskontrolle. Authentifizierungsschutzmaßnahmen auf Routenebene, die Autorisierungsprüfungen auf Objektebene auslassen. Tritt in administrativen Endpunkten, Massenoperationen und Exportfunktionen auf.

Unsicheres JWT-Handling. Algorithmus-Verwechslungsangriffe, schwache Signing-Keys, fehlende Ablaufvalidierung und JWT-Payload-Manipulation. OWASP A02:2021.

Injection. SQL, NoSQL, Command und LDAP-Injection in Suchfeldern, Filterparametern und Massenoperations-Endpunkten. OWASP A03:2021.

Offengelegte Geheimnisse. API-Schlüssel, Datenbankanmeldedaten und private Schlüssel, die in die Versionskontrolle eingecheckt oder in Build-Artefakten, Umgebungsvariablen oder API-Antworten offengelegt wurden.

Fehlende Rate-Limits. Login-Endpunkte, OTP-Verifizierung, Passwort-Reset und API-Endpunkte ohne Rate-Limiting sind anfällig für Brute-Force- und Enumerationsangriffe. OWASP API4:2023.

Fehler bei der Mandantenisolierung. Multi-Mandanten-SaaS-Anwendungen, bei denen ein Mandant die Daten eines anderen Mandanten durch direkte Objektreferenzen, gemeinsame Caches oder falsch konfigurierte Datenfilter lesen, ändern oder löschen kann.

Unsicherer Datei-Upload. Upload-Endpunkte, die beliebige Dateitypen akzeptieren, Inhalte nicht validieren oder Dateien in ausführbaren Pfaden speichern. Kann zu Remote Code Execution führen.

Übermäßige API-Datenexposition. API-Antworten, die vollständige Objektdarstellungen einschließlich Felder zurückgeben, die der Client nicht verwendet – und auf die er keinen Zugriff haben sollte. OWASP API3:2023.

Cloud-Fehlkonfiguration. Öffentlich zugängliche Speicher-Buckets, übermäßig berechtigte IAM-Rollen, uneingeschränkte Sicherheitsgruppen und fehlende Verschlüsselung im Ruhezustand oder bei der Übertragung.

Unzureichende Protokollierung. Kein Audit-Trail für Authentifizierungsereignisse, Berechtigungsfehler oder sensible Datenzugriffe. Bedeutet, dass ein Sicherheitsverstoß unentdeckt bleiben kann und forensische Untersuchungen unmöglich sind. OWASP A09:2021.

---

Black-Box, Grey-Box oder White-Box-Testing: Was sollten Sie kaufen?

Die Testmethodik bestimmt, wie viel Zugang der Tester hat und wie tiefgehend er die Anwendung abdecken kann. Jeder Ansatz hat legitime Anwendungsfälle.

Black-Box-Testing. Der Tester hat kein Vorwissen über die Anwendung, keine Anmeldedaten und keine Dokumentation. Simuliert einen externen nicht authentifizierten Angreifer. Realistisch für Tests der externen Angriffsfläche, übersieht jedoch den Großteil der authentifizierten Schwachstellen in der Geschäftslogik. Dauert deutlich länger, um gleichwertige Abdeckung zu erreichen, und kostet mehr pro gefundener Schwachstelle.

Grey-Box-Testing (authentifizierter Penetrationstest). Der Tester hat Anmeldedaten für jede Benutzerrolle und möglicherweise teilweise Dokumentation. Dies ist die empfohlene Methodik für die meisten SaaS-Anwendungen, da sie authentifizierte Multi-Rollen-Tests, Tests der Geschäftslogik und Tests zur Mandantenisolierung unterstützt und gleichzeitig die Angreiferperspektive bewahrt. Der Tester weiß, was die Anwendung tun soll – was Abweichungen vom erwarteten Verhalten umsetzbar macht. Die meisten Anwendungssicherheitsbewertungs-Engagements bei Seven Labs verwenden standardmäßig Grey-Box, da es die höchste Abdeckung für das Budget liefert.

White-Box-Testing. Der Tester hat vollen Zugang – Quellcode, Architekturdokumentation, Anmeldedaten, API-Spezifikationen und Infrastrukturdiagramme. Maximale Abdeckung. Geeignet für Anwendungen, die Finanztransaktionen, Gesundheitsdaten oder regulierte persönliche Daten verarbeiten, wo erschöpfende Sicherheitszusicherungen erforderlich sind. Schneller als Grey-Box für gleichwertige Abdeckung, da der Tester das Anwendungsverhalten nicht von Grund auf enumerieren muss.

Für die meisten SaaS-Unternehmen ist Grey-Box die richtige Wahl. Es deckt die Schwachstellenkategorien ab, die tatsächlich in Pre-Launch-SaaS-Anwendungen auftreten, unterstützt Tests der Geschäftslogik und Mandantenisolierung und liefert eine Abdeckung, die Black-Box ohne Vervierfachung des Zeitplans nicht erreichen kann.

---

Wann sollte ein SaaS-Unternehmen VAPT durchführen?

Pre-Launch-Sicherheitsaudit. Der kosteneffektivste Zeitpunkt, Schwachstellen zu finden und zu beheben, ist vor dem Live-Gang von Nutzern, Daten und Integrationen. Ein Pre-Launch-VAPT identifiziert Schwachstellen, wenn die Behebung nur Entwicklerzeit erfordert – bevor ein Sicherheitsverstoß regulatorische, Reputations- und vertragliche Konsequenzen hat.

Vor Enterprise-Beschaffung. Enterprise-Kunden in den VAE, Saudi-Arabien und dem GCC verlangen routinemäßig einen aktuellen Penetrationstest-Bericht als Teil der Vendor Due Diligence. Ohne einen solchen Bericht stocken oder scheitern Deals. Dies ist der häufigste unmittelbare Geschäftstreiber für VAPT in der Region.

Nach wesentlichen Authentifizierungsänderungen. Eine neue SSO-Integration, eine Änderung Ihrer JWT-Bibliothek, ein neuer OAuth-Flow oder eine wesentliche Rollenmodell-Umstrukturierung führt neue Angriffsflächen ein. Behandeln Sie diese als Auslöser für einen gezielten Re-Test der Authentifizierungs- und Autorisierungsschicht.

Nach Zahlungsintegration. Zahlungsabläufe – insbesondere solche mit Promo-Codes, Rabatten, Abonnement-Upgrades und Rückerstattungsverarbeitung – sind hochwertige Ziele für Geschäftslogik. Testen Sie nach der Integration, nicht nach einem Vorfall.

Nach Infrastrukturmigration. Ein Wechsel des Cloud-Anbieters, die Einführung eines neuen Container-Orchestrierungs-Setups oder die Umstrukturierung Ihrer VPC-Architektur verändert Ihre Cloud-Angriffsfläche. Eine Cloud-Sicherheitsbewertung sollte wesentlichen Infrastrukturänderungen folgen.

Vor Compliance-Überprüfung. Wenn Ihre Roadmap PCI DSS, ISO 27001, SOC 2 oder eine DIFC-Regulierungsprüfung umfasst, ist ein Penetrationstest ein erforderliches oder erwartetes Kontrollinstrument. Mit VAPT kurz vor der Compliance-Frist zu beginnen, lässt unzureichend Zeit für die Behebung.

Nach einem Sicherheitsvorfall. Ein Verstoß, ein anomales Zugriffsereignis oder eine Schwachstellenmeldung sollte ein umfassendes VAPT auslösen, um das volle Ausmaß der Exposition zu verstehen – nicht nur den spezifischen Angriffsweg, der ausgenutzt wurde.

In regelmäßigen Abständen. Anwendungen entwickeln sich weiter. Neue Funktionen führen neue Endpunkte ein, neue Abhängigkeiten führen neue Schwachstellen ein und Angreifer-Tools werden weiterentwickelt. Jährliches VAPT ist eine Basisanforderung für Anwendungen, die sensible Daten verarbeiten. Höheres Risiko-Anwendungen profitieren von einer häufigeren Kadenz.

---

Wie bewertet man einen VAPT-Anbieter?

Nicht alle VAPT-Anbieter in den VAE liefern dasselbe Produkt. Die folgenden Warnsignale deuten auf einen Anbieter hin, der automatisiertes Scanning zum Preis eines Penetrationstests verkauft.

Keine Erklärung manueller Tests. Ein professioneller Anbieter kann genau erklären, was seine Ingenieure manuell tun – welche Tools sie verwenden, was sie von Hand testen und warum. Wenn die Antwort vage ist, ist das Engagement wahrscheinlich scanner-geführt.

Keine benannte Methodik. OWASP Testing Guide, PTES, OWASP API Security Top 10 – ein professioneller Anbieter wendet eine dokumentierte Methodik an und kann sie benennen. „Wir folgen Best Practices der Branche" ist keine Methodik.

Keine Retest-Bedingungen. Ein Penetrationstest ohne Retest ist ein Audit, kein behebungsintegrierter Service. Wenn Retest-Bedingungen nicht im Vertrag stehen, fragen Sie nach dem Grund.

Kein Musterbericht. Jeder professionelle Anbieter hat einen anonymisierten Musterbericht, den er auf Anfrage teilen kann. Wenn er das nicht kann oder will, können Sie nicht bewerten, was Sie kaufen.

Keine Nachweise in Befunden. Echte Penetrationstest-Befunde enthalten Screenshots, Request/Response-Paare, Payload-Beispiele oder Exploitation-Videos. Scanner-Ausgabe ohne Nachweise ist kein Befund.

Kein Test der Geschäftslogik. Fragen Sie explizit: „Testen Ihre Ingenieure auf BOLA, Fehler bei der Mandantenisolierung und Payment-Logic-Bypass?" Wenn die Antwort unklar ist, deckt das Engagement die Schwachstellen nicht ab, die in Ihrer SaaS-Anwendung am wahrscheinlichsten vorhanden sind.

Unklarer Umgang mit Daten. Ein Penetrationstest berührt Ihre Produktions- oder Staging-Daten. Fragen Sie, wie Anmeldedaten, Testdaten und extrahierte Nachweise nach dem Engagement gespeichert, übertragen und gelöscht werden.

Bericht vollständig vom Scanner generiert. Schauen Sie sich die Beschreibungen der Befunde im Musterbericht an. Wenn sie wie automatisierte Tool-Ausgaben mit minimaler kontextueller Erklärung der geschäftlichen Auswirkungen klingen, ist das, was Sie kaufen.

Keine Schweregrad-Begründung. CVSS-Werte sollten von einer Erklärung begleitet sein, warum dieser Wert auf diesen Befund in dieser Anwendung zutrifft. Das Kopieren eines Basiswerts aus einer CVE-Datenbank ohne Umgebungskontext ist keine Schweregradbeurteilung.

Keine Behebungsüberprüfung. Die besten Anbieter überprüfen die Umsetzung der Behebung, nicht nur, ob ein Kontrollkästchen angekreuzt wurde. Fragen Sie, ob Ingenieure die Behebungsqualität überprüfen oder lediglich den ursprünglichen Testfall erneut ausführen.

---

Pre-Launch SaaS-Sicherheitscheckliste

Diese SaaS-Sicherheitscheckliste deckt die Kontrollkategorien ab, die am häufigsten als Lücken in Pre-Launch-VAPT-Engagements auftreten. Sie ist kein Ersatz für einen Penetrationstest – sie ist eine Mindestanforderung, die vor einem solchen erfüllt werden sollte.

Authentifizierung

• Passwörter mit bcrypt, Argon2 oder scrypt gehasht (nicht MD5, SHA-1 oder SHA-256 ohne Salt)
• MFA verfügbar und für Admin-Rollen erzwungen
• Passwort-Reset-Flow erlaubt keine Token-Wiederverwendung oder fehlende Ablaufzeit
• OAuth- und SSO-Integrationen auf Redirect-URI-Fixierung und State-Parameter-Handling validiert

Autorisierung

• Eigentumsüberprüfungen auf Objektebene bei jedem Datenabruf- und Mutations-Endpunkt
• Rollenbasierte Zugriffskontrolle serverseitig erzwungen, nicht clientseitig
• Admin-Endpunkte erfordern explizite Admin-Rollen-Verifizierung – nicht nur Authentifizierung
• Massenoperationen (Export, Löschen, Aktualisieren) erzwingen Eigentümerschaft über alle Datensätze im Batch

Mandantenisolierung

• Row-Level-Security oder Äquivalent auf Datenbankebene erzwungen
• Keine gemeinsamen Caches ohne mandantenspezifische Schlüssel
• Mandantenübergreifender Zugriff mit zwei separaten Konten vor dem Launch getestet
• Mandanten-Identifikatoren sind nicht vorhersehbar oder sequenziell aufzählbar

Rate-Limiting

• Login-Endpunkt rate-limitiert und nach wiederholten Fehlern gesperrt
• OTP- und Passwort-Reset-Endpunkte rate-limitiert pro IP und pro Konto
• API-Endpunkte rate-limitiert pro Benutzer/Token, nicht nur pro IP
• Aufwändige Operationen (Suche, Export, Batch-Verarbeitung) gegen Missbrauch geschützt

Eingabevalidierung

• Alle benutzerkontrollierten Eingaben serverseitig validiert, bevor sie in Abfragen oder Befehlen verwendet werden
• SQL-Abfragen verwenden parametrisierte Anweisungen oder ORM mit sicheren Standardwerten
• Datei-Uploads nach Inhaltstyp validiert (nicht nur Erweiterung), größenbegrenzt und außerhalb des Webroot gespeichert

Secrets-Management

• Keine Anmeldedaten, API-Schlüssel oder Tokens in der Versionskontrolle (vollständige Commit-Historie prüfen)
• Umgebungsvariablen für alle Secrets in der Produktion verwendet
• Secrets-Rotationsprozess dokumentiert und getestet

Passwort- und Sitzungssicherheit

• Sitzungstoken sind kryptografisch zufällig und ausreichend lang
• Sitzungen werden beim Abmelden ungültig gemacht (serverseitige Ungültigmachung, nicht nur Client-Cookie-Löschung)
• JWTs werden bei jeder Anfrage auf Algorithmus, Ablauf, Aussteller und Zielgruppe validiert
• Refresh-Token-Rotation implementiert, wenn langlebige Refresh-Tokens verwendet werden

API-Exposition

• API-Antworten geben nur die Felder zurück, die die anfragende Rolle benötigt (standardmäßig kein Over-Fetching)
• Nur intern zugängliche Endpunkte nicht über das öffentliche Internet zugänglich
• GraphQL-Introspection in der Produktion deaktiviert, wenn nicht erforderlich
• API-Versionierung lässt veraltete Endpunkte nicht mit gelockerten Sicherheitskontrollen aktiv

Datei-Handling

• Hochgeladene Dateien werden von einer separaten Domain oder CDN ohne Skriptausführung bereitgestellt
• Datei-Metadaten (EXIF, Dokumenteigenschaften) werden entfernt, wenn Dateien an andere Benutzer weitergegeben werden
• Speicherberechtigungen überprüft – kein öffentlicher Lesezugriff auf Buckets, die privat sein sollten

Protokollierung und Überwachung

• Authentifizierungsereignisse (Login, Logout, fehlgeschlagener Login, MFA-Ereignisse) mit IP und Zeitstempel protokolliert
• Autorisierungsfehler protokolliert
• Sensible Datenzugriffe (Massenexport, Admin-Operationen) protokolliert
• Log-Integrität – Logs sind schreibgeschützt und für den Anwendungsbenutzer nicht zugänglich

Backups und Wiederherstellung

• Backup-Verschlüsselung im Ruhezustand verifiziert
• Wiederherstellungsverfahren gegen eine Nicht-Produktionsumgebung getestet
• Backup-Zugriff auf eine separate IAM-Rolle beschränkt, die nicht von Anwendungsdiensten verwendet wird

Cloud-Berechtigungen

• Prinzip der geringsten Privilegien auf alle Service-Accounts und IAM-Rollen angewendet
• Keine Wildcard-IAM-Richtlinien in der Produktion
• Public-Access-Block auf Speicherkonten aktiviert
• Netzwerk-ACLs und Sicherheitsgruppen überprüft – kein 0.0.0.0/0-Eingang auf Management-Ports

Drittanbieter-Abhängigkeiten

• Abhängigkeits-Audit durchgeführt (npm audit, pip-audit, bundler-audit oder Äquivalent)
• Bekannte kritische CVEs in Abhängigkeiten vor dem Launch behoben
• Software Bill of Materials (SBOM) für Enterprise-Client-Anfragen verfügbar

Incident Response

• Definierter Prozess für die Reaktion auf eine gemeldete Schwachstelle oder einen Sicherheitsverstoß
• Sicherheitskontakt (security@yourdomain.com oder Äquivalent) veröffentlicht und überwacht
• Kommunikationsvorlagen für Verstoßbenachrichtigungen vorbereitet (auch wenn nie verwendet)

---

Scopebasiertes VAPT-Angebot anfordern

Die Lücke zwischen einem automatisierten Scan und einem professionellen Penetrationstest ist die Lücke zwischen dem Finden bekannter CVEs in Ihren Abhängigkeiten und dem Erkennen, dass Ihre Multi-Mandanten-Autorisierung umgehbar ist, Ihre JWT-Implementierung Privilegienerweiterung ermöglicht und Ihr Zahlungsflow anfällig für Bestellmanipulation ist. Seven Labs hat 11 kritische Schwachstellen in einem einzigen SaaS-Startup-VAPT-Engagement aufgedeckt – Schwachstellen, die Scanner nicht markiert haben, aber ein authentifizierter manueller Tester innerhalb des ersten Testtages fand.

Wenn Sie sich auf den Launch vorbereiten, auf einen Fragebogen zur Enterprise-Beschaffungssicherheit antworten oder eine Compliance-Überprüfung abschließen, ist der Ausgangspunkt ein scopebasiertes Angebot, das automatisiertes Scanning von manueller Exploitation und Tests der Geschäftslogik trennt.

Scopebasiertes VAPT-Angebot anfordern – oder lesen Sie unsere VAPT- und Penetrationstest-Services, um zu verstehen, was ein Seven Labs-Engagement abdeckt, bevor Sie sich melden.