Zum Inhalt springen
Browserberg Browserberg
Tool

Wohin schickt diese Seite, was du eintippst?

Ein echter Browser lädt die URL und löst jedes Formular, jeden Button und jeden Link auf das Ziel auf, zu dem er wirklich führt, so wie der Destination Guard von Browserberg es tut, bevor ein Agent ein Element benutzen darf. Nichts wird abgeschickt; der Bericht zeigt Ziele, Domains und Risiken.

Kostenlos starten Gespräch buchen

Eine öffentliche Seite mit Formular eingeben: Kontaktseite, Newsletter-Box, Login. Der Scan dauert etwa fünfzehn Sekunden.

Diese Prüfung öffnet einen echten Browser auf unseren Servern und braucht JavaScript in deinem.

Beobachtungen, keine Urteile. Deine Eingabe wird für dieses Ergebnis verarbeitet und in ein Nutzungsjournal geschrieben, das die Datenschutzerklärung beschreibt; sonst wird nichts gespeichert.

Den Bericht lesen

  1. Mit der Zusammenfassung anfangen

    Wie viele Elemente, wie viele Domains, wie viele mit Risiko. Eine Kontaktseite mit vierzig fremden Navigationszielen ist meist ein Footer voller Social-Links, und die Domain-Spalte bestätigt das auf einen Blick.

  2. Auf Absendungen filtern

    Formulare tragen die eingetippten Daten. Ein off_site_submit auf einem Login oder Kontaktformular verdient einen Blick in die Zielspalte; ein Zahlungsdienstleister ist erwartbar, ein unbekannter Host nicht.

  3. Unsichere Übertragung prüfen

    insecure_submit heißt: Eine https-Seite sendet an http. Dafür gibt es selten einen Grund; meist ist es eine fest verdrahtete action, die älter ist als das Zertifikat.

  4. Mit dem Agenten vergleichen

    Jede Zeile mit Risiko ist ein Element, dessen Absendung der Destination Guard unbeaufsichtigt verweigern würde. Braucht dein Workflow eins davon, braucht er eine Person oder eine ausdrückliche Freigabe für dieses Ziel.

Wie Ziele aufgelöst werden

Der Check führt den Destination-Bericht in einer normalen Browserberg-Session aus. Chromium lädt die Seite, und für jedes Formular, jeden Absende-Button und jeden Link fragt der Bericht die Seite, wohin das Element führt. Das Fragen ist der entscheidende Teil. Die action eines Formulars kann relativ sein, von einem base-Element umgeschrieben, von einem formaction am Button überstimmt oder leer, dann sendet der Browser an die aktuelle URL. Wer das Attribut aus dem HTML liest, macht jeden dieser Fälle zumindest manchmal falsch. Der Bericht löst die URL durch den DOM auf, so wie der Browser selbst, und genau so arbeitet der Destination Guard, bevor ein Agent etwas drückt.

Was in einer Zeile steht

Je Element: die Ziel-URL, die registrierbare Domain, ob sie mit der der Seite übereinstimmt, und ein Risiko, wenn eins zutrifft. Es gibt vier, und jedes ist eine Beobachtung, kein Urteil. off_site_submit: Ein Formular sendet an eine andere Domain. off_site_navigation: Ein Link oder Button führt auf eine andere Domain. unsafe_scheme: Das Ziel ist eine javascript:- oder data:-URL und keine Seite. insecure_submit: Die Seite ist https, das Formular sendet an http, und was du tippst, ginge im Klartext über die Leitung. Die Zusammenfassung zählt Elemente je Risiko und je Domain.

Warum eine Agentenplattform so etwas hat

Den Destination Guard gibt es wegen Prompt Injection. Eine Seite kann ein Login-Formular enthalten, dessen action ganz woanders hinzeigt, und ein Agent mit dem Auftrag, sich anzumelden, würde die Zugangsdaten des Kunden hineintippen. Einzustufen, was ein Button sagt, reicht nicht. Deshalb löst der Guard vor der Benutzung auf, wohin ein Element führt, und verweigert eine Absendung, die Daten von der Seite wegtragen würde. Der Bericht ist diese Auflösung, ausgedruckt.

Was der Check nicht beurteilt

Fremd ist nicht falsch. Ein Zahlungsformular, das an einen Dienstleister sendet, ein Login, der zu einem Identitätsanbieter weiterleitet, eine Newsletter-Box, die an einen Versanddienst geht: alles fremde Absendungen, alles gewöhnlich. Der Bericht zeigt sie, damit du sie erkennst; er benotet die Seite nicht.

Er sieht außerdem nur, was der DOM deklariert. Ein Formular, dessen Submit-Handler per fetch eine API ruft, löst auf seine deklarierte action auf, meist die Seite selbst, und das echte Ziel ist ohne Absenden unsichtbar, was der Bericht nie tut. Single-Page-Anwendungen zeigen deshalb weniger Ziele, als sie nutzen. Elemente jenseits des Limits, in der API standardmäßig zweihundert, werden gezählt, aber nicht gelistet. Und der Scan ist ein frischer Browser in der EU beim Laden der Seite: Ziele, die erst nach Login, Reiterwechsel oder Scrollen erscheinen, fehlen, und ein Cookie-Banner ist ein Formular wie jedes andere.

Die eingegebene URL landet nur im Nutzungsjournal, das die Tagesgrenze ehrlich hält.

Fragen zu Formular-Zielen

Wie finde ich heraus, wohin ein Formular seine Daten sendet?

Lies die aufgelöste action im Browser, nicht im HTML: Entwicklerwerkzeuge öffnen, das form-Element auswählen und seine action-Eigenschaft ansehen, die base-URLs und formaction-Überschreibungen berücksichtigt. Dieser Check macht das für alle Elemente der Seite auf einmal.

Ist eine Absendung an eine fremde Domain ein Problem?

Nicht an sich. Zahlungsdienstleister, Identitätsanbieter und Versanddienste empfangen legitim Formulardaten. Der Bericht markiert die Tatsache; ob der Empfänger erwartet ist, entscheidest du.

Sendet der Scan irgendetwas ab?

Nein. Es wird nichts getippt, geklickt oder gesendet. Ziele werden aus dem DOM der Seite und der URL-Auflösung des Browsers bestimmt.

Warum zeigt ein JavaScript-Formular die Seite selbst als Ziel?

Weil das seine deklarierte action ist. Die Anfrage, die ein Skript beim Absenden schickt, ist ohne Absenden nicht sichtbar, und das verweigert der Bericht. Single-Page-Anwendungen zeigen weniger Ziele, als sie nutzen.

Was macht der Destination Guard mit einem markierten Element?

In einem Agentenlauf verweigert er die Absendung eines Elements, dessen aufgelöstes Ziel die Seite verlässt, und meldet die Verweigerung als Inhalt, nicht als Fehler. Der Bericht hier ist dieselbe Auflösung ohne die Verweigerung.

Derselbe Bericht aus der eigenen Session

import { Browserberg } from '@browserberg/sdk';

const bb = new Browserberg({ apiKey: process.env.BROWSERBERG_API_KEY });

await using session = await bb.sessions.create();
const report = await session.destinationReport({ url: 'https://www.beispiel.de/kontakt', limit: 200 });

for (const c of report.controls) {
  if (c.risk) console.log(c.risk, c.destination, c.site);
}
console.log(report.summary);

Wer das nutzt

Sicherheitsprüfung vor dem Agenten

Bevor ein Agent auf ein Partnerportal losgelassen wird: auflisten, wohin dessen Formulare wirklich senden. Ein Ziel, das niemand kennt, ist eine Frage an den Partner, gestellt bevor Zugangsdaten getippt werden.

Datenschutz

Welche Dritten von dieser Seite Formulardaten bekommen, ist ein Inventar, das der Bericht liefert. Was das für das Verarbeitungsverzeichnis heißt, ist eine Bewertung, die das Team trifft.

Nach einer Migration

Alte absolute actions, http-Endpunkte und Staging-Hosts überleben Relaunches. Der Bericht findet sie schneller als ein grep durch Templates, weil er auflöst, was der Browser auflöst.

Vor einem Workflow

Jedes Formular, das der Workflow ausfüllen soll, einmal hier prüfen. Dann ist klar, welche Absendung der Guard verweigern wird und wo eine Person freigeben muss.

Weiterlesen

Den Guard prüfen lassen, bevor der Agent tippt

Fünf Browserstunden, keine Karte. destination_report auf jeder Seite, die dein Workflow berührt.

Kostenlos starten Gespräch buchen