Ratgeber

Headless-Browser und Automatisierung auf der Anmeldeseite erkennen

Die Browsersignale, die Anmeldungen per Puppeteer, Playwright und Selenium verraten, warum jedes einzeln gefälscht werden kann und wie man sie kombiniert, ohne echte Menschen zu blockieren.

9 Min. Lesezeit · Aktualisiert am 2026-10-31 · Attrelix

Warum Bots heute echte Browser nutzen

Vor einigen Jahren waren die meisten Anmelde-Bots einfache HTTP-Skripte, die Ihr Formular direkt absendeten. Die sind leicht zu stoppen: Sie führen kein JavaScript aus, also kommt nichts an, was Ihre Seite im Browser berechnet. Heute steuern die meisten ernsthaften Bots einen echten Browser über Puppeteer, Playwright oder Selenium, oft headless, manchmal über einen Anti-Detect-Browser, der seinen Fingerabdruck tarnt. Sie führen Ihr JavaScript aus, rendern Ihre Seite und füllen das Formular aus wie ein Mensch.

Sie zu erkennen heißt, die Stellen zu finden, an denen sich ein automatisierter Browser von einem unterscheidet, den ein Mensch benutzt. Keines der folgenden Signale ist für sich ein Beweis — ein entschlossener Betreiber kann jedes kaschieren —, aber sie sind günstig zu erheben und summieren sich.

Signal 1: das WebDriver-Flag

Browser unter WebDriver-artiger Automatisierung setzen navigator.webdriver auf true. Das ist bewusst Teil des WebDriver-Standards, und die Standardkonfigurationen von Selenium, Puppeteer und Playwright legen es offen.

const automated = navigator.webdriver === true;

„Stealth“-Plugins löschen oder überschreiben es, sein Fehlen beweist also nichts. Sein Vorhandensein ist dagegen nahezu eindeutig: Echte Nutzer haben es praktisch nie.

Signal 2: der Headless-User-Agent

Headless Chrome gibt sich im User-Agent als HeadlessChrome zu erkennen, sofern der Betreiber das nicht überschreibt. Prüfen Sie es auch auf dem Server anhand des Request-Headers, denn der in JavaScript gemeldete User-Agent kann vom gesendeten abweichen.

Signal 3: ein angebundener DevTools-Protokoll-Client

Puppeteer und Playwright steuern Chrome über das DevTools-Protokoll. Hört ein Protokoll-Client auf Konsolen-Ereignisse, serialisiert der Browser geloggte Objekte — und liest dabei sogar Eigenschaften, die eine normale Seite nie anfassen würde. Ein Getter, der festhält, ob er gelesen wurde, ist ein bekannter Weg, das zu bemerken:

function devtoolsProtocolAttached() {
  let read = false;
  const e = new Error();
  Object.defineProperty(e, "stack", { get() { read = true; return ""; } });
  console.debug(e);
  return read;
}

Es schlägt auch an, wenn ein Entwickler die DevTools geöffnet hat; geben Sie ihm daher ein mittleres Gewicht statt es als Urteil zu behandeln.

Signal 4: Software-Rendering und seltsame Fenster

Headless-Browser auf Servern haben keine GPU, daher weicht WebGL auf einen Software-Renderer wie SwiftShader oder llvmpipe aus. Den Namen des Renderers können Sie über die Erweiterung WEBGL_debug_renderer_info auslesen, sofern der Browser sie anbietet. Manche Headless-Setups melden außerdem ein Fenster mit Breite oder Höhe null. Virtuelle Maschinen und Remote-Desktops teilen diese Merkmale, allein sind es also schwache Signale.

Signal 5: ein Fingerabdruck, der sich widerspricht

Anti-Detect-Browser sollen wie viele verschiedene echte Browser aussehen. Dazu überschreiben sie Eigenschaften, und solche Überschreibungen sind selten völlig konsistent. Vergleichen lohnt sich:

• Das Betriebssystem im User-Agent mit navigator.platform und den User-Agent Client Hints.
• Die Browserfamilie im User-Agent mit Funktionen, die nur diese Engine hat.
• Die installierten Schriftarten mit denen, die das Betriebssystem mitbringt.
• Ein zweimal hintereinander gezeichnetes Canvas, das zwei verschiedene Bilder ergibt — ein Zeichen für eingespeistes Rauschen.
• Notification.permission meldet „denied“, während die Permissions API „prompt“ meldet.

Jeder Widerspruch ist allein schwach, denn Datenschutz-Erweiterungen und ungewöhnliche Setups erzeugen manche davon. Zwei oder drei zusammen sind ein starkes Muster.

Signal 6: das Token, das nie zurückkam

Eine einfache und robuste Technik: Lassen Sie das Skript der Anmeldeseite ein kurzlebiges Einmal-Token anfordern, legen Sie es in ein verstecktes Formularfeld und prüfen Sie es auf dem Server. Ein Bot, der Ihr JavaScript überspringt, kommt ohne gültiges Token an; einer, der ein altes Token wiederverwendet, mit einem bereits benutzten. Sie müssen nicht wissen, wie der Bot funktioniert, um zu merken, dass er Ihre Seite nie richtig ausgeführt hat. Halten Sie das Token einmalig, an Ihre Website gebunden, und lassen Sie es nach Minuten ablaufen.

Signal 7: Verhalten statt Fingerabdruck

Fingerabdrücke lassen sich fälschen, Verhalten deutlich schwerer. Ein Mensch liest das Formular, bewegt den Zeiger und tippt. Ein Skript füllt die Felder und schickt sie wenige hundert Millisekunden nach dem Laden ab, ohne ein einziges vertrauenswürdiges Eingabeereignis.

Die verlässliche Messung braucht keine zusätzliche Software: Ihr Agent gibt beim Laden der Seite das Besuchertoken aus, und Ihr Server vergleicht diesen Zeitstempel mit dem Moment der Prüfung. Unter etwa einer Sekunde vom Laden bis zur Anmeldung ist ein Skript. Kann der Agent zusätzlich vertrauenswürdige Eingabeereignisse melden, ist ein sofortiges Absenden ohne Zeiger-, Tasten- oder Touch-Ereignis eine zweite, unabhängige Bestätigung.

Eine Einschränkung zu Signal 3: In aktuellem Chrome greift der DevTools-Trick nur, wenn der Automatisierungsclient Konsolen-Ereignisse abonniert. Behandeln Sie ihn als Bonus, nicht als Hauptdetektor.

Kombinieren statt an einem Signal sperren

Behandeln Sie jedes Signal als Punkte in einem Score und entscheiden Sie über die Summe. Eine sinnvolle Startgewichtung, vom stärksten zum schwächsten:

Kombinieren Sie die Browsersignale mit serverseitigen — Anmeldungen aus Cloud-IP-Bereichen, Schübe aus einem Subnetz, Konten am selben Gerät —, und nur sehr wenige Bots wirken in allen gleichzeitig sauber.

Was Sie lassen sollten

• Nicht allein wegen fehlender Plugins oder Sprachen sperren. Auf Datenschutz gehärtete Browser entfernen sie.
• Ihre Erkennungslogik nicht als offensichtlich benannte Prüfungen ausliefern, die ein Betreiber suchen und auf einen Schlag aushebeln kann; erheben Sie Rohdaten im Browser und entscheiden Sie auf dem Server.
• Nichts blind glauben, was der Browser meldet. Der Client steht unter Kontrolle des Bots. Geprüft wird auf Ihrem Server, mit Ihrem Geheimnis.

So macht es Attrelix

Der Attrelix-Agent erhebt diese Browserdaten und ein Einmal-Besuchertoken auf Ihrer Anmeldeseite; der Server kombiniert sie mit Netzwerk-, Postfach- und Verknüpfungssignalen zu einem Score. Alle Gewichte sind öffentlich in der Dokumentation, und kein einzelnes schwaches Signal kann eine Anmeldung allein in die Prüfung schicken.

Zusammenfassung

• Moderne Bots nutzen echte Browser; suchen Sie, wo sich Automatisierung vom Menschen unterscheidet.
• WebDriver, Headless-User-Agent und fehlende Tokens sind stark; der Rest ist schwach, summiert sich aber.
• Entscheiden Sie auf dem Server per Score, nie anhand eines einzelnen Browser-Flags.