
Wir finden, was Scanner übersehen.
Ein automatischer Scanner erkennt bekannte Muster. Er versteht aber nicht, was Ihre Anwendung eigentlich tun soll – und genau dort liegen die teuren Lücken: im Bestellprozess, der sich manipulieren lässt, in der API, die dem Frontend vertraut, in der Rollenprüfung, die eine Ebene zu früh aufhört.
Wir testen Ihre Anwendung so, wie ein Angreifer sie benutzen würde: mit Verständnis für die Geschäftslogik dahinter. Das gilt besonders für Code, der mit KI-Assistenten entstanden ist – lauffähig heißt dort nicht abgesichert. Was wir melden, ist nachweislich ausnutzbar – kein Scanner-Rauschen, das Ihr Entwicklungsteam Wochen kostet.
Vereinbaren Sie ein unverbindliches Erstgespräch. Wir analysieren Ihre Situation und empfehlen den passenden Ansatz.
Anfragen0800 20 60 900Wir analysieren Abläufe, die kein Tool versteht – etwa die Frage, was passiert, wenn der Preis im Bezahlprozess nach der Validierung geändert wird.
Wir testen die „Sprache" zwischen Ihren Systemen. Sind Authentifizierung und Autorisierung lückenlos, selbst wenn der Aufruf nicht vom offiziellen Frontend kommt?
Von Cloud-nativen Apps (AWS, Azure) bis zu klassischen Content-Management-Systemen – wir kennen die spezifischen Angriffsvektoren.
Wir prüfen die App im Betrieb und dekompilieren sie (.apk / .ipa). Wir suchen nach hartkodierten API-Schlüsseln, versteckten Admin-Passwörtern und unsicheren Krypto-Implementierungen.
Coding-Assistenten schreiben heute ganze Features – schnell, lauffähig und ohne Blick dafür, wer den Aufruf eigentlich machen darf. Die Fehlerbilder wiederholen sich: Berechtigungsprüfungen, die nur im Frontend stattfinden, Zugangsdaten direkt im Quelltext, ungeprüfte Eingaben und Abhängigkeiten mit erfundenen Paketnamen, die Angreifer im Paket-Repository dann bereitwillig anlegen. Wir prüfen KI-generierten Code gezielt auf diese Muster – bevor er produktiv geht.
Wir analysieren die komplette Angriffsfläche: Endpunkte, APIs, Authentifizierungsmechanismen, Datenflüsse und verwendete Technologien.
Bekannte Schwachstellen und die OWASP Top 10 werkzeuggestützt abklopfen. Das ist die Grundlage für die manuelle Analyse, nicht das Ergebnis – ausgewertet wird jeder Treffer von Hand.
Der Kern: Wir testen auf Logikfehler, IDOR, Preismanipulation, unsichere API-Endpunkte und fehlende Autorisierungsprüfungen.
Dynamische und statische Analyse der Mobile App. Prüfung von Certificate Pinning, Datenspeicherung und Reverse Engineering des Codes.
Klares Executive Summary für das Management, dazu priorisierte technische Anleitungen für Ihr Entwicklerteam. Kein Rauschen, nur echte Befunde.
Für bekannte Schwachstellen in Bibliotheken: ja, den sollten Sie behalten. Ein Scanner prüft aber Muster, keine Absichten. Er meldet Ihnen keine Bestellung, bei der sich der Preis nach der Prüfung noch ändern lässt, und keinen API-Endpunkt, der die Rolle des Aufrufers nicht kontrolliert. Genau diese Fehler kosten im Schadensfall am meisten – und genau die finden wir manuell.
Am liebsten auf einer Staging-Umgebung, die der Produktion entspricht. Dort können wir ohne Rücksicht auf echte Kundendaten und Bestellungen arbeiten. Wenn es kein Staging gibt, testen wir auch produktiv – dann mit klar abgestimmten Grenzen und außerhalb Ihrer Hauptgeschäftszeiten.
Zugangsdaten ja, in der Regel je einen Account pro Rolle. Erst damit lässt sich prüfen, ob ein normaler Nutzer an Daten kommt, die ihm nicht gehören – die häufigste und teuerste Klasse von Webfehlern. Quellcode ist optional: Mit Code finden wir mehr in derselben Zeit, ohne Code entspricht der Test eher der Sicht eines echten Angreifers. Wir beraten Sie, was in Ihrem Fall sinnvoller ist.
Ein fokussierter Web-Application-Test liegt typischerweise bei drei bis fünf Tagen, ein größerer Test mit mehreren Rollen, APIs und Mobile-App entsprechend darüber. Der wichtigste Faktor ist nicht die Anzahl der Seiten, sondern die Anzahl der Rollen und der fachlichen Abläufe – ein Shop mit Rabattlogik und Teilzahlung ist aufwendiger als eine große Informationsseite.
Den Schwerpunkt, ja. KI-generierter Code ist selten schlampig – er ist plausibel und an denselben Stellen lückenhaft: Rollenprüfungen, die nur im Frontend stattfinden, Zugangsdaten im Quelltext, Abhängigkeiten, deren Paketnamen aus einer Halluzination stammen. Wir sehen uns deshalb zuerst die Autorisierung über alle Rollen hinweg an und gleichen die verwendeten Pakete ab. Wer die Zeile geschrieben hat, Mensch oder Assistent, ändert an Ihrer Verantwortung nichts.
Teilweise – deshalb ist der Zeitpunkt entscheidend. Sinnvoll ist ein gründlicher Test vor großen Releases oder nach Umbauten an Authentifizierung, Bezahlung oder Rollenmodell. Für die Zeit dazwischen ist die kontinuierliche Überwachung mit myAUDIT360 der passendere Baustein. Was ein Test dauerhaft bringt, sind die Muster: Ihr Team erkennt die gefundenen Fehlerklassen danach selbst.
Vereinbaren Sie ein unverbindliches Erstgespräch. Wir analysieren Ihre Situation und empfehlen den passenden Ansatz.
Jetzt anfragen