Weniger gefälschte Anfragen. Mehr Zeit für Kunden.
Formular-Spam und verdächtige Anmeldeversuche belasten das Team und den täglichen Betrieb. Corpilus hilft Ihnen, riskante Anfragen zu bewerten und je nach Anbindung festzulegen, wie Ihre Anwendung reagiert.
Drei Stellen, an denen es Unternehmen am meisten spüren
Modellsituationen aus dem Betrieb von Websites und Shops. Es sind keine Kundenreferenzen, und wir nennen dazu keine gemessenen Ergebnisse.
Wiederholte gefälschte Anfragen
Über das Kontaktformular kommen laufend Anfragen, die sich wie höflich geschriebener Text lesen. Ein echter Kunde kann darunter sein, also muss jemand sie einzeln durchgehen.
Eine Vertriebskraft sortiert Anfragen ohne Wert.
Warum eine Anfrage markiert wurde und was ein geschütztes Formular damit macht.
Das Skript auf der Seite meldet, wie das Formular ausgefüllt wurde und ob derselbe Text schon viele Male eingegangen ist — nicht, welche Wörter darin stehen. Die verbindliche Entscheidung fällt erst, wenn das Ergebnis serverseitig verifiziert wird, über das SDK oder den Endpunkt zur Token-Prüfung.
Verdächtige Anmeldungen
Auf der Anmeldeseite gehen Versuche mit fremden Passwörtern ein, Anmeldungen von unbekannten Geräten und von Orten, zwischen denen niemand in der Zwischenzeit hätte reisen können.
Risiko des Kontomissbrauchs und Belastung des Supports.
Der Unterschied zwischen der Risikobewertung und der eigenen Entscheidung der Anmelde-Anwendung.
Wenn der Anmeldeprozess eine Anmeldung samt Historie an Corpilus sendet, erhält er eine Risikostufe mit den konkreten Signalen: unmögliche Reise, wiederholte Versuche mit fremden Passwörtern, eine erste Anmeldung zugleich von einem unbekannten Gerät und aus einem unbekannten Land. Die Historie liefert der Aufrufer, und über die Anmeldung entscheidet Ihre Anwendung.
Automatisiertes Durchsuchen von Inhalten
Ein automatisierter Client geht den Katalog durch und gibt sich dabei als gewöhnlicher Besucher aus. In der Statistik sieht es wie Produktinteresse aus, obwohl nie ein Kunde da war.
Unklare Herkunft des Traffics.
Was sich erkennen ließ und wo die Integration einen Eingriff erlaubt.
Der Schutz arbeitet mit dem, was er auf seiner Seite sehen kann: ob die Adresse auf öffentlichen IP-Reputationslisten steht, ob der User-Agent zu einem bekannten KI-Crawler passt und ob die von Ihnen konfigurierten Regeln greifen. Ein Treffer erhöht das Risiko und wird als Ereignis festgehalten; die Anfrage stoppen kann nur ein Weg, der das Ergebnis der Prüfung verifiziert.
Sie sehen den Grund für den Fund und die Reaktion des Schutzes.
Eine einzelne Anfrage aus einem geschützten Formular, so wie sie die Ereignisübersicht zeigt.
- Zeit
- 08:07
- Ort
- Das Formular „Kontakt“ auf beispiel-shop.example
- Grund
- Derselbe Text kam wiederholt vom selben Gerät; die Felder wurden auf einmal ausgefüllt, ohne Tippen.
- Risiko
- Hoch
Die Anfrage wurde bewertet und das Ereignis festgehalten. Das Formular hat sie wie jede andere verarbeitet — in diesem Modus greift der Schutz nicht in die Verarbeitung ein.
Beobachten ist ein Fund. Es zeigt, was auf der Website ankommt, hält aber für sich genommen nichts auf.
Der Schalter ist hier, um den Unterschied zu zeigen. Er verändert nur, was Sie in diesem Beispiel sehen, und hat keine Auswirkung auf die Einstellungen irgendeines Systems.
Zuerst finden wir heraus, was Ihre Website braucht.
Kein zugesagtes Audit und kein automatischer Scan, sobald Sie eine Adresse senden.
- 01Wir wählen aus, was geschützt wirdWir gehen die Formulare, die Anmeldung oder die Schnittstellen durch, die Sie schützen wollen — beginnend dort, wo es Sie heute belastet.
Für ITDer Umfang wird Weg für Weg festgelegt: welches Formular, welcher Anmeldeablauf, welche Schnittstelle.
- 02Wir vereinbaren die Anbindung und was beobachtet wirdWir legen fest, wie der Schutz angebunden wird und was er beobachtet, damit Sie sehen, was wirklich auf der Website ankommt.
Für ITAuf einer Website heißt das: das Skript auf der Seite für die Signale und das SDK oder die Middleware in Ihrem serverseitigen Ablauf für die verbindliche Entscheidung.
- 03Wir stellen die Reaktionen auf das Gefundene einSobald es eine Grundlage gibt, stellen wir die Reaktionen Stelle für Stelle ein — zuerst dort, wo die Auswirkung am größten ist.
Für ITFür jede Oberfläche vereinbaren wir, ab welchem Schweregrad eine Anfrage blockiert wird und was passiert, wenn die Prüfung nicht verfügbar ist.
Das Skript auf der Seite allein erzwingt keinen Schutz auf dem Server. Soll die Anwendung eine Anfrage stoppen, muss sie das Ergebnis der Prüfung im zuständigen serverseitigen Ablauf verifizieren.
Ein geschütztes Formular bedeutet keinen geschützten Katalog — das öffentliche Durchsehen von Inhalten ist eine eigene Frage. Einen bekannten Robot zu erkennen ist ebenfalls nicht dasselbe, wie das Kopieren von Inhalten zu unterbinden.
Die Website-Prüfungen im Detail
Nur die Prüfungen, die eine Website betreffen. Token-Prüfung, der Ort der Middleware, Umgehung auf der Client-Seite, Ausfälle und Kapazität gehören auf die Seiten zu Integration und Bereitstellung.
Formularsignale
Das Skript meldet, wie die Seite und das Formular genutzt wurden: ob die Felder auf einmal befüllt wurden, ob sich dieselbe Übermittlung wiederholt und ob ein verstecktes Feld ausgefüllt wurde, das ein Besucher nicht sehen kann.
Formulare auf Seiten, auf denen das Skript eingebunden ist.
Anfragerate
Aktionsereignisse werden nach der auf dem Server ermittelten Adresse bewertet, nicht nach einem Wert aus dem Anfragekörper. Telemetrie aus dem Skript bleibt bei den Ratenprüfungen außen vor und führt nie zu einer Blockierung.
Formularübermittlungen, Anmeldungen und andere Aktionsereignisse.
Anmeldebewertung
Der Endpunkt zur Anmeldebewertung bewertet unmögliche Reisen, wiederholte Versuche mit fremden Passwörtern, eine erste Anmeldung zugleich von einem unbekannten Gerät und aus einem unbekannten Land sowie Versuche gegen mehrere Konten von derselben Adresse oder demselben Gerät. Er gibt Risiko und Signale zurück, kein Urteil.
Wird aus dem Anmeldeprozess über die Integration oder die REST-API aufgerufen.
Regeln und die verfügbaren Reaktionen
Für jede Oberfläche — Formular, Anmeldung, API — legt die Richtlinie fest, ab welchem Schweregrad eine Anfrage blockiert wird. Sie verschärft die Entscheidung der anderen Schichten immer nur, lockert sie nie, und ohne Konfiguration erzwingt sie nichts zusätzlich.
Auswertung der Ereignisse aus dem Skript und dem SDK.
Website-Scan von außen
Auf Anfrage geht er die Website wie ein Besucher durch, nur mit HEAD- und GET-Anfragen, ohne Angriffe und ohne Formularübermittlungen: die Einrichtung von Verschlüsselung und Sicherheits-Headern, Cookies, öffentlich erreichbare Dateien, domainübergreifende Freigaben und die Regeln für KI-Crawler.
Eine eigene Prüfung, kein automatischer Scan, der durch eine Adresse ausgelöst wird.
Wenn Sie eine WAF haben, ersetzt Corpilus sie weder noch schaltet es sie ab. Welche Stellen es noch um eine Prüfung ergänzt, geht man Schicht für Schicht durch. WAF und weitere Schichten
Sehen wir uns die konkrete Stelle an, die Ihnen Probleme macht.
Senden Sie uns die Adresse der Website und beschreiben Sie kurz, ob es um die Formulare, die Anmeldung oder einen anderen Teil der Anwendung geht. Wir schlagen einen passenden Weg zur Bewertung vor.
Das Senden einer Adresse ist keine Zustimmung zu aktiven Sicherheitstests. Wir starten keinen automatischen Scan, sobald eine Adresse eingeht.
Der Preis ist individuell, nach Umfang. Wie der Umfang bestimmt wird