Die Situation ist jedem bekannt, der schon einmal eine Website mit Formularen, Warenkörben oder Benutzerkonten gestartet hat. Der Entwickler macht alles nach Anleitung: Captcha im Formular, Ratenbegrenzungsfilter, Sperrung verdächtiger Länder. Die Website ist geschützt, Bots kommen nicht durch. Doch eine Woche später öffnet der Inhaber das Feedback und sieht: „Kann keine Bestellung aufgeben“, „Captcha lädt nicht“, „Die Website funktioniert nicht, obwohl ich Internet habe“.
Das Problem ist, dass die Sicherheit meist von einer einzigen Person getestet wird, in einem Browser, aus einer Stadt, auf einem Gerät. Für sie funktioniert alles. Aber ein Kunde aus einer anderen Region, auf einem anderen Smartphone, mit einem anderen Browser kommt nicht durch. Und das nicht, weil er ein Bot ist. Sondern weil der auf Härte getrimmte Schutz nicht zwischen einer „seltsamen, aber echten“ Anfrage und einer „seltsamen, weil automatisierten“ Anfrage unterscheidet. Er blockiert einfach. Und er blockiert diejenigen, die gekommen sind, um zu kaufen.
Wie ein Schutz aussieht, der echte Nutzer aussperrt
Das häufigste Szenario ist ein unlösbares Captcha. Nicht, weil es generell defekt ist, sondern weil es für einen bestimmten Nutzer nicht lädt, fehlerhaft geladen wird oder schlicht nicht erkannt wird. Die Person gibt dreimal Zeichen ein, erhält dreimal „falsch“ und geht. Für den Website-Inhaber sieht das aus wie ein einzelner Abbruch. Für den Markt wie ein verlorener Auftrag. Und wenn das zehn Leuten am Tag passiert, reißt das über einen Monat hinweg ein spürbares Loch in den Umsatz, das niemand bemerkt, weil die Statistik einfach „niedrige Conversion“ anzeigt.
Das zweite Szenario ist ein strenger Frequenzfilter für Anfragen. Die Website geht davon aus, dass es sich um einen Bot handelt, wenn innerhalb einer Minute mehr als fünf Anfragen von derselben Adresse eingehen. Aber ein echter Mensch öffnet auf langsamem Mobilfunkinternet eine Seite, sie lädt nicht, also aktualisiert er. Noch einmal. Noch einmal. Nach einer Minute hat er bereits sieben Anfragen, und die Website sperrt ihn. Die Person sieht eine leere Seite oder die Meldung „zu viele Versuche“. Sie ist kein Bot. Sie hat einfach schlechten Empfang. Aber der Schutz weiß das nicht.
Das dritte ist die Ländersperre. Der Entwickler betrachtet die Angriffsstatistik, sieht, dass die Hälfte der Anfragen aus bestimmten Regionen stammt, und verhängt ein Verbot. Später stellt sich heraus, dass in diesen Ländern echte Kunden leben, die früher bestellt haben. Oder dass sich jemand im Roaming befindet und sich physisch in einem Land aufhält, während seine Anfrage über ein anderes läuft. Der Schutz analysiert keinen Kontext. Er sieht das Land und entscheidet.
Das vierte, weniger offensichtliche Problem: ein Skript, das die „Lebendigkeit“ des Browsers überprüft. Es prüft das Vorhandensein bestimmter Parameter, die Engine-Version und einen Satz von Funktionen. Wenn der Browser nicht übereinstimmt, wird die Seite nicht gerendert. Der Mensch sieht einen leeren Bildschirm oder ein halbfertiges Layout. Für ihn ist die Website „kaputt“. Für den Entwickler „wird der Browser nicht unterstützt“. Aber hier geht es nicht um Unterstützung. Es geht darum, dass Lebendigkeitsprüfungen so geschrieben sind, dass sie bei normalen, aber nicht standardmäßigen Konfigurationen fehlschlagen.
Warum man das Problem nicht „nach Auge“ prüfen kann
Die Hauptfalle: Entwickler und Website-Inhaber sehen alles problemlos laufen. Sie öffnen die Website in Chrome auf dem Desktop, in ihrem eigenen Land, über eine gute Internetverbindung. Alles lädt, das Captcha wird gelöst, das Formular wird abgeschickt. Test bestanden. Website gestartet. Und dann kommen Kunden — mit Android auf schwachem Empfang, mit Safari auf dem iPhone, mit Firefox auf dem Laptop, aus einem anderen Land, mit einer Browser-Erweiterung, die den Header ändert. Und für sie ist die Website anders. Nicht, weil sie kaputt ist. Sondern weil sie nicht diejenigen sind, die sie getestet haben.
Synthetische Lasttests, die oft zur Überprüfung des Servers eingesetzt werden, helfen hier nicht weiter. Sie senden Anfragen an den Server und schauen, wie dieser antwortet. Aber sie führen kein JavaScript aus, laden die Seite nicht vollständig, rendern kein Layout und lösen keine Captchas. Für sie ist eine Seite nur eine Ansammlung von Bytes. Für einen echten Menschen ist es das, was er auf dem Bildschirm sieht. Und wenn JavaScript nicht funktioniert hat, wenn die Schriftart nicht geladen wurde, wenn das Formular nicht initialisiert wurde — kann der Server trotzdem „200 OK“ antworten und glauben, alles sei in Ordnung. Der Mensch sieht jedoch eine fehlerhafte Seite und geht.
Ein weiterer Punkt: Der Schutz schaltet sich oft nicht sofort ein. Die ersten Anfragen gehen normal durch, aber sobald der Anfragenzähler einer Adresse den Schwellenwert überschreitet, greift die Sperre. Der Tester macht fünf Anfragen, alles funktioniert, er schließt den Browser. Ein Kunde macht jedoch fünfzehn — und stößt gegen eine Wand. Der Test bildet das echte Nutzerverhalten nicht ab, da der Tester kein Nutzer ist. Er testet eine Funktion, kein Szenario.
Was genau kaputt geht und wie man es bemerkt
Die Liste der Dinge, die durch zu harten Schutz kaputtgehen können, ist kurz, aber jeder Punkt schlägt sich im Geldbeutel nieder. Layout: Die Seite wird nicht vollständig gerendert, Blöcke verrutschen, Buttons sind nicht anklickbar. Zähler: Das Analyseskript kann keine Daten senden, da die Anfrage vom Filter blockiert wird, wodurch Löcher in der Statistik des Inhabers entstehen — nicht weil es keine Besucher gibt, sondern weil ihre Besuche nicht aufgezeichnet wurden. Formulare: Das Absenden schlägt fehl, weil die Formularanfrage für den Filter „verdächtig“ wirkt. Warenkörbe: Sitzungen brechen ab, da die Lebendigkeitsprüfung im zweiten Schritt fehlschlägt. Benutzerkonten: Der Login funktioniert nicht, weil die Autorisierung bestimmte Parameter erfordert, die der Schutz nicht durchlässt.
Wie erkennt man, dass das Problem am Schutz liegt und nicht an der Website? Ein einfacher Test: Den Schutz für zehn Minuten abschalten und schauen, was passiert. Wenn Formulare wieder funktionieren, das Layout stimmt und Zähler Daten erfassen, lag es am Filter. Aber das ist ein Test im Nachhinein, wenn bereits etwas kaputt ist. Man muss es jedoch vorher wissen, vor dem Start oder vor Änderungen der Sicherheitseinstellungen. Und dafür braucht man nicht nur einen Browser in einer Stadt, sondern viele Browser an verschiedenen Orten.
Die Website mit realen Browsern testen: Die Idee
Die Idee ist einfach und, ehrlich gesagt, etwas ironisch: Genau das Tool, mit dem Traffic künstlich erzeugt wird, arbeitet hier zum Wohle der Website. Zur Erinnerung: Künstlicher Traffic bedeutet, dass automatisierte Programme eine Website öffnen, damit die Statistik besser aussieht. Hier ist es genau umgekehrt: Automatisierte Programme öffnen die Website, um zu prüfen, ob der Schutz normale Besucher erstickt. Der Unterschied liegt im Ziel. Der Mechanismus ist derselbe: Eine echte Browser-Engine öffnet die Seite, wartet die vorgegebene Zeit, scrollt, klickt und füllt Felder aus. Und wenn die Seite in einem Schritt nicht lädt, das Formular nicht funktioniert oder kein Captcha erscheint, ist das sichtbar. Nicht in Server-Logs, sondern auf dem Bildschirm. So wie ein Mensch es sieht.
Warum ist das besser als ein synthetischer Lasttest? Weil der Viewer die Seite vollständig lädt. Er führt JavaScript aus, rendert das Layout, lädt Schriftarten, Bilder und Skripte. Er verhält sich wie ein normaler Besucher, nur eben ohne Bewusstsein. Und wenn der Schutz ihn erstickt, erstickt er auch echte Menschen. Wenn nicht, kommen echte Menschen durch. Das ist keine Garantie, dass jeder einzelne Nutzer durchkommt, aber es ist der Realität viel näher als „Server hat 200 geantwortet“.
Woher bekommt man solchen Traffic für den Test? Eine geeignete Quelle ist 9Hits. Dies ist eine Traffic-Börse, die seit den 2010er Jahren betrieben wird. Ein Teilnehmer installiert eine Viewer-Anwendung, die vollautomatisch Websites in einer echten Browser-Engine öffnet, eine bestimmte Zeit verweilt und weitergeht. Dafür werden Punkte gutgeschrieben. Diese Punkte werden für eigene Kampagnen ausgegeben: Website-Adresse, Verweildauer, Frequenz, Länder. Die Website öffnet sich in den Viewern anderer Teilnehmer weltweit. Es gibt Makros — Aktionsszenarien auf der Seite: Scrollen, Klicks, Ausfüllen von Feldern. Für den Sicherheitstest ist das genau das Richtige: Man kann einstellen, dass auf der Seite gescrollt, auf einen Formularbutton geklickt und etwas in ein Feld eingegeben wird. Und dann beobachten, was passiert.
Punkte für einen einmaligen Test: Man muss nicht sammeln
Das Einzige, was abschrecken könnte: „Ich muss erst Punkte sammeln, bevor ich sie ausgeben kann.“ Für den regelmäßigen Betrieb — ja, da sammelt der Teilnehmer Punkte, während sein Viewer fremde Seiten öffnet. Aber für einen einmaligen Test vor dem Start oder vor einer Änderung der Schutzeinstellungen ist das Sammeln nicht erforderlich. Es gibt die Möglichkeit, fertige Punkte zu erwerben. Das ist kein Abonnement, kein Vertrag und kein „Paketkauf“. Es ist einfach eine Menge, die man für einen einzigen Durchlauf nehmen kann. Kampagne für die eigene Website starten, in verschiedenen Ländern und Szenarien beobachten, schließen. Punkte ausgegeben, Test erledigt.
Es ist wichtig zu verstehen, dass es sich hierbei um automatisierten Programm-Traffic handelt, nicht um echte Menschen. Niemand sitzt da und klickt. Es ist eine Browser-Engine, die eine Seite öffnet und vorgegebene Aktionen ausführt. Für einen Sicherheitstest ist das kein Nachteil, sondern ein Vorteil: Sie wird nicht müde, vergisst nicht, einen Button zu klicken, und schließt den Tab nicht nach drei Sekunden. Sie tut exakt das, was im Makro definiert ist. Und wenn die Seite im dritten Schritt nicht lädt, wird das im Bericht angezeigt. Nicht nach „Gefühl“, sondern konkret: Seite X, Zeit Y, Status Z.
Was nach dem Durchlauf genau zu prüfen ist
Die Checkliste ist überschaubar, aber jeder Punkt sollte durchgegangen werden. Erstens: Layout. Öffnet sich die Seite vollständig? Bricht sie auf halbem Weg ab? „Springt“ der Inhalt? Wenn die Seite in einem Szenario nur zur Hälfte lädt, ist das ein Problem. Nicht zwangsläufig im Schutz, aber es muss geprüft werden.
Zweitens: Formulare. Werden Felder ausgefüllt? Wird das Formular abgeschickt? Erscheint eine Erfolgs- oder Fehlermeldung? Wenn das Formular nicht abgesendet wird, liegt das entweder am Schutz oder an einem Bug. Wenn es jedoch nur in bestimmten Ländern oder bei bestimmten Szenarien fehlschlägt, ist es fast sicher der Schutz.
Drittens: Captcha. Erscheint es? Lässt es sich lösen? Wenn ein Captcha in einem Szenario vorhanden ist, im anderen aber nicht, oder wenn es lädt, aber nicht angezeigt wird, ist das ein Problem. Ein echter Mensch wird in einer solchen Situation die Seite verlassen.
Viertens: Zähler. Wenn nach dem Durchlauf keine Daten in der Analyse auftauchen, konnte das Analyseskript keine Anfrage senden. Echte Besucher werden dann ebenfalls nicht erfasst. Die Statistik lügt: Es gibt angeblich keine Menschen, obwohl welche da waren.
Fünftens: Geschwindigkeit. Es ist nicht zwingend erforderlich, dass die Seite in 0,3 Sekunden lädt. Aber wenn sie in einem Szenario zwei Sekunden und im anderen acht Sekunden benötigt — und nach acht Sekunden nicht vollständig geladen ist —, ist das ein Problem. Ein echter Mensch mit langsamem Internet wartet keine acht Sekunden. Er aktualisiert die Seite. Und eine Aktualisierung bedeutet eine weitere Anfrage. Und eine weitere Anfrage bringt ihn der Sperre näher.
Sechstens: Sitzungen. Wenn ein Nutzer das Formular im ersten Schritt passiert, aber die Sitzung im zweiten Schritt abbricht, ist das ein Problem. Ein echter Mensch gibt seinen Namen ein, geht zum nächsten Feld, und seine Sitzung ist abgelaufen. Er sieht eine leere Seite oder die Meldung „Sitzung abgelaufen“. Und er geht.
Wie man es mit dem Schutz nicht übertreibt
Schutz ist notwendig. Bots existieren, sie ruinieren den Ruf, spammen Formulare und belasten den Server. Aber ein Schutz, der einen Bot nicht von einem echten Menschen mit schlechtem Internet unterscheiden kann, ist kein Schutz. Es ist ein Filter, der alles niedermäht. Und das Hauptprinzip lautet: Der Schutz muss echte Menschen durchlassen. Nicht „hauptsächlich durchlassen“, nicht „die Mehrheit kommt durch“, sondern durchlassen. Wenn ein echter Mensch nicht durchkommt, ist das nicht sein Problem. Es ist ein Konfigurationsproblem.
Das praktische Fazit aus dem Vorherigen: Vor dem Website-Start oder vor Änderungen der Schutzeinstellungen sollte die Seite mit realen Browsern aus verschiedenen Ländern getestet werden. Nicht mit einem einzigen Browser in einer Stadt. Kein synthetischer Test, der nur den Server betrachtet. Sondern ein vollständiger Durchlauf, bei dem die Seite komplett lädt, JavaScript ausgeführt wird, Formulare ausgefüllt werden und das Scrollen funktioniert. Und man schaut, was passiert. Wenn echte Nutzer in einem Szenario scheitern, sieht man das. Nicht erst nach einer Woche, wenn Kunden bereits abgewandert sind, sondern vorher. Solange man es noch korrigieren kann.
Und das Letzte: Sicherheit ist kein „Einrichten und Vergessen“-Vorgang. Browser aktualisieren sich, Engines verändern sich, neue Erweiterungen tauchen auf, neue Länder kommen hinzu. Was vor drei Monaten funktioniert hat, funktioniert heute vielleicht nicht mehr. Nicht, weil die Website kaputt ist. Sondern weil sich die Welt verändert hat. Eine einmalige Prüfung vor dem Start ist nach einem halben Jahr nicht mehr aktuell. Das ist kein Urteil. Es bedeutet lediglich, dass Schutz keine einmalige Einstellung ist, sondern ein Prozess. Und je früher man sieht, dass er echte Menschen aussperrt, desto weniger verliert man. Nicht in der Statistik. Sondern an Geld.
