Skip to content
Root scanner
ENIT
← Back to the check
How the check worksAbout the scannerPrivacy policy

About this scanner

You found Root92-MigrationScanner in your logs. Here is who we are, what we read, what we never read, and how to make us stop.

8 sections · 7 min read

On this page
  1. 01Who we are
  2. 02What we read from your server
  3. 03Ownership verification: the few extra requests
  4. 04What we never read
  5. 05Why we were allowed to
  6. 06Why we do not ask the owner for proof
  7. 07How much load this puts on you
  8. 08How to make us stop

On this page

  1. 01Who we are
  2. 02What we read from your server
  3. 03Ownership verification: the few extra requests
  4. 04What we never read
  5. 05Why we were allowed to
  6. 06Why we do not ask the owner for proof
  7. 07How much load this puts on you
  8. 08How to make us stop

If you are here, you probably found this line in your access logs:

  • Root92-MigrationScanner/1.0 (+https://webappscanner.root92.com/about-scanner)

That is us. This page explains exactly what that request did, and how to stop it. It takes about a minute to read, and there is a "how to make us stop" section at the bottom if that is all you want.

01Who we are#

Root92. We migrate apps built with AI app builders to code the owner actually controls.

The free surface check is how that conversation starts: the owner of an app pastes its address, ticks a box confirming they own it or are authorised to have it analysed, and gets a report on what an outsider can see from the outside. There is no crawler, no list, no discovery. We only ever look at an address somebody typed in themselves.

Legal contact: Root92 sh.p.k., NIPT (Albanian tax ID) M52111038D, Don Bosko, Njesia Administrative Nr.11, Zyre F-101, shkalla F.kati , ambienti 1, Tirane, Albania.

02What we read from your server#

In one session, within a total budget of 20 seconds and 20 MB across everything:

  • /robots.txt, first, before anything else.
  • The HTML of the home page, following at most 3 redirects.
  • Up to 40 first-party JavaScript bundles that the markup itself declares — via <script src>, <link rel="modulepreload"> or <link rel="preload" as="script">. Third-party scripts are not fetched.
  • A HEAD request — status code only, never the body — on exactly four paths: /.env, /.git/config, any .map file a bundle we already downloaded declares, and /sitemap.xml.
  • One TLS handshake on port 443, to read the protocol version and the certificate’s expiry date. No data is exchanged on it.
  • Public DNS records of your domain: SPF and DMARC (TXT), MX and CAA.

On an app builder’s own subdomain we skip both the TLS handshake and the DNS records: they belong to the platform, not to the app.

From all of that we keep metadata: which builder produced the site, whether a backend is referenced, which security headers were present, sizes and timings. We do not keep page content.

03Ownership verification: the few extra requests#

Before a deeper check, the person who asked has to prove they control the hostname. They choose one method, publish a token we give them, and ask us to look. Nothing below happens unless someone starts a verification for your exact hostname, and each look is one of these:

  • DNS: a TXT lookup of _root92-verify.<your hostname>, and of its parent names up to your registrable domain, for a value starting with root92-verify=. That is a query to DNS, not a request to your server.
  • File: GET https://<your hostname>/.well-known/root92-verification.txt, and nothing else. HTTPS only, at most 1 KB read, redirects followed only on the same hostname and at most 3. This one path does not consult robots.txt: the file only exists if the owner put it there, so there is nothing of yours for us to read if they did not — you will see one 404 in your logs. A redirect to any other path leaves this exception and asks robots.txt first.
  • Meta tag: the home page, looking for <meta name="root92-verification"> inside <head>. This obeys robots.txt exactly like the surface check.
  • Report by email: instead of any of the above, the person can give us an address on your domain (for example name@yourdomain) and ask for the report to be sent there. This does not prove ownership. A person on our team reviews each request; only if they approve it do we run the check and email the report to that address. Nothing is shown on our website.

At most 50 verification looks per hour against the same hostname, whoever asks; of those, at most 10 from a single browser session, and 30 per hour from the same person. The token is tied to their browser session and to your exact hostname: it does not cover your other subdomains, and it expires with the session.

Once a DNS, file or meta proof has been found, we look for it again about every 60 minutes while the verification is open, with the same request and inside an hourly limit of its own. We also look for it once more right before the deeper check starts, and before the email step if it was last found more than 120 minutes earlier. If the proof now carries a different token, or robots.txt now forbids the look, the verification lapses at once. If the proof is simply missing, we do not end the verification on one look: a DNS cache or a deploy can hide a proof that is still there. It lapses only if it is still missing at least 60 minutes after we first missed it, or if the hourly look fails 3 times in a row. Nothing opened by a lapsed verification stays open.

Once ownership is proven and the owner consents again, the deeper check is the same session described above — same budget, same paths, robots.txt obeyed — on the verified hostname only. It does not read your database and does not try any key it finds.

04What we never read#

  • We never read data from your database. Not a row, not a count, not "just to see if it answers".
  • We never use a key or token we find. A public key in a bundle gets decoded and reported; it is never presented to your backend, in any form.
  • We never download the body of /.env or /.git/config, even when they answer 200. We record the status code and close the connection. The finding is "this is reachable", and it has no field for the contents.
  • We never download source maps. We only check whether they exist.
  • We never guess. No wordlists, no /.env.local, no /backup.zip, no table names. The paths above, including the verification requests, are the entire list.
  • We never write anything anywhere.
  • We never disguise the request. The user-agent above is the only one we use.

05Why we were allowed to#

Because the owner of the application asked us to, one address at a time, with a tick box, before the first request went out.

That consent is recorded with the version of the text it was given under, and it is the only thing that starts a scan. There is no code path that scans anything outside that form: no batch, no list, no scheduled job, not even in development.

If you are reading this and you are not the person who asked, then somebody submitted an address that was not theirs. Tell us at the address below and we will handle it.

A verification is the same kind of request: someone who says the hostname is theirs asks us to look for a token they published. If they could not publish it, the looks find nothing and nothing further happens.

06Why we do not ask the owner for proof#

The free check reads only what your server already hands to any browser, so we ask for a declaration rather than proof of ownership. What keeps a false declaration harmless is the shape of the check itself: one address at a time, at most 3 checks an hour against the same hostname whoever asks, your robots.txt respected, no key used, nothing downloaded beyond the public surface, and every check logged with the time, the address and where the request came from. Anything that would go further — such as testing whether a database answers without a login — is never part of this automatic check.

07How much load this puts on you#

Deliberately little, because a tool that stresses the site it is checking would be the wrong tool.

  • One session per check, capped at 20 seconds and 20 MB in total — not per request. When the budget runs out the scan stops and reports what it managed to establish.
  • At most 40 bundles.
  • At most 3 checks per hour against the same hostname, no matter who asks, and 20 per hour from the same submitter. One check can mean up to two scan sessions: the report is computed when the address is submitted, and computed again if that person then asks to be contacted, so the saved report is the fresh one. That is why you may see up to 6 sessions in an hour and not 3. The cap follows redirects: if the address we were given forwards to yours, it is your hostname that is counted.

08How to make us stop#

Two ways, and there is no third.

Put us in your robots.txt. We read it before the home page and we respect it — if the path is disallowed for our token, we do not fetch it, and the check closes as blocked with nothing collected:

  • User-agent: Root92-MigrationScanner
  • Disallow: /

That stops everything except the single verification file described above (/.well-known/root92-verification.txt), which only an owner can create and which is a 404 otherwise. To stop that too, do not publish the file — or write to us.

Or write to us at info@root92.it, telling us the hostname, and we will block the address on our side, verification included.

If a request from us caused you a real problem, say so in that email. We would rather hear it than not.

↑ Back to top

Keep reading

How the free check works →What the Root92 surface check reads, what it never touches, how your four scores are calculated, and what the full audit adds.Privacy policy →What we collect when you run a free surface check, why, for how long, and how to have it deleted.
← Back to the check