Where does this page send what you type?
A real browser loads the URL and resolves every form, button and link to the place it would actually go, the way Browserberg's destination guard does before an agent is allowed to use a control. Nothing is submitted; the report lists destinations, sites and risks.
Enter a public page with a form on it: a contact page, a newsletter box, a login. The scan takes about fifteen seconds.
This check opens a real browser on our servers and needs JavaScript in yours.
Observations, not verdicts. What you enter is processed for this result and written to a usage journal described in the privacy policy; nothing else is stored.
How destinations are resolved
The checker runs the destination report in an ordinary Browserberg session. Chromium loads the page, and for every form, submit button and link the report asks the page where the control leads. Asking the page is the important part. A form's action may be relative, may be rewritten by a base element, may be overridden by a formaction on the button, or may be empty, in which case the browser posts to the current URL. Reading the attribute from the HTML gets every one of those wrong at least sometimes; the report resolves the URL through the DOM the way the browser itself would, which is how Browserberg's destination guard works before an agent presses anything.
What each row contains
For each control: the destination URL, the registrable site it belongs to, whether that site is the same as the page's, and a risk when one applies. Four risks exist and each is a fact rather than a judgement. off_site_submit: a form posts to a different registrable site. off_site_navigation: a link or button leads to a different site. unsafe_scheme: the destination is a javascript: or data: URL rather than a page. insecure_submit: the page is https and the form posts to http, so what you type would travel in the clear. The summary counts controls per risk and per site.
Why an agent platform has this
The destination guard exists because of prompt injection. A page can contain a login form whose action points somewhere else entirely, and an agent asked to sign in would type the customer's credentials into it. Classifying what a button says is not enough, so before a control is used the guard resolves where it leads and refuses a submit that would carry data off-site. The report is that resolution, printed.
What the checker does not judge
Off-site is not wrong. A payment form posting to a provider, a login redirecting to an identity provider and a newsletter box posting to a mailing service are all off-site submits and all ordinary. The report shows them so that you can recognise them; it does not score the page.
It also sees only what the DOM declares. A form whose submit handler calls fetch to an API resolves to its declared action, which is usually the page itself, and the actual request target is invisible without executing the submit, which the report never does. Single-page applications therefore show fewer destinations than they use. Controls beyond the limit, two hundred by default in the API, are counted but not listed. And the scan is a fresh EU-hosted browser at page load: destinations that appear after a login, a tab switch or a scroll are not in it, and cookie banners are part of the page like any other form.
The URL you enter is not stored beyond the usage journal that keeps the daily cap honest.
Reading the report
-
Start with the summary
How many controls, how many sites, how many carry a risk. A contact page with forty off-site navigations is usually a footer full of social links, and the site column confirms it in a glance.
-
Filter to submits
Forms are what carry typed data. An off_site_submit on a login or a contact form deserves a look at the destination column; a payment provider is expected, an unknown host is not.
-
Check the insecure ones
insecure_submit means an https page posting to http. There is rarely a good reason; it is usually a hard-coded action that predates the certificate.
-
Compare with what the agent would do
Every row with a risk is a control the destination guard would refuse to submit unattended. If your workflow needs one, it needs a person or an explicit allowance for that destination.
Who runs this and why
Security reviews
Before an agent is pointed at a partner portal, list where its forms actually post. A destination nobody recognised is a question for the partner, asked before any credential is typed.
Privacy and compliance teams
Which third parties receive form data from this page is a factual inventory the report provides. What that means for a records-of-processing entry is a judgement the team makes.
Developers after a migration
Old absolute actions, http endpoints and staging hosts survive redesigns. The report finds them faster than a grep through templates, because it resolves what the browser resolves.
The same report from your own 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.example.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);
from browserberg import Browserberg
bb = Browserberg(api_key=API_KEY)
with bb.sessions.create() as s:
report = s.destination_report("https://www.example.de/kontakt")
for c in report["controls"]:
if c.get("risk"):
print(c["risk"], c["destination"], c["site"])
Questions about form destinations
How do I find out where a form sends its data?
Read the resolved action in the browser, not the HTML: open the developer tools, select the form element and inspect its action property, which accounts for base URLs and formaction overrides. This checker does that for every control on the page at once.
Is an off-site form submission a problem?
Not by itself. Payment providers, identity providers and mailing services all receive form posts legitimately. The report flags the fact; whether the recipient is expected is for you to decide.
Does the scan submit anything?
No. Nothing is typed, clicked or posted. Destinations are resolved from the page's DOM and the browser's URL resolution.
Why is a JavaScript-driven form shown as posting to the page itself?
Because that is its declared action. The request a script sends on submit is not visible without submitting, which the report refuses to do. Single-page applications show fewer destinations than they use.
What does the destination guard do with a flagged control?
In an agent run it refuses to submit a control whose resolved destination leaves the site, and reports the refusal as content rather than an error. The report you see here is the same resolution, without the refusal.
Let the guard check before the agent types
Five browser hours, no card. Run destinationReport on any page your workflow touches.