Se sei qui, probabilmente hai trovato questa riga nei tuoi log di accesso:
Root92-MigrationScanner/1.0 (+https://webappscanner.root92.com/about-scanner)
Siamo noi. Questa pagina spiega esattamente cosa ha fatto quella richiesta, e come fermarla. Si legge in un minuto, e se ti interessa solo l’ultima cosa c’è una sezione «come farci smettere» in fondo.
Chi siamo#
Root92. Migriamo applicazioni costruite con builder AI verso codice che il proprietario controlla davvero.
Il check gratuito di superficie è il modo in cui quella conversazione comincia: il proprietario di un’app incolla il suo indirizzo, spunta una casella in cui conferma di esserne il proprietario o di essere autorizzato a farla analizzare, e riceve un referto su cosa si vede da fuori. Non c’è nessun crawler, nessuna lista, nessuna scoperta automatica. Guardiamo solo un indirizzo che qualcuno ha scritto di persona.
Riferimenti legali: Root92 sh.p.k., NIPT (codice fiscale albanese) M52111038D, Don Bosko, Njesia Administrative Nr.11, Zyre F-101, shkalla F.kati , ambienti 1, Tirane, Albania.
Cosa leggiamo dal tuo server#
In una sola sessione, entro un budget totale di 20 secondi e 20 MB per tutto:
/robots.txt, per primo, prima di qualunque altra cosa.- L’HTML della home page, seguendo al massimo 3 redirect.
- Fino a 40 bundle JavaScript di prima parte, quelli che il markup dichiara da sé — con
<script src>,<link rel="modulepreload">o<link rel="preload" as="script">. Gli script di terze parti non li scarichiamo. - Una richiesta
HEAD— solo il codice di stato, mai il corpo — su esattamente quattro percorsi:/.env,/.git/config, i file.mapdichiarati da un bundle già scaricato, e/sitemap.xml. - Un handshake TLS sulla porta 443, per leggere la versione del protocollo e la scadenza del certificato. Non ci passa nessun dato.
- I record DNS pubblici del tuo dominio: SPF e DMARC (
TXT),MXeCAA.
Sul sottodominio di un builder saltiamo sia l’handshake TLS sia i record DNS: sono della piattaforma, non dell’app.
Di tutto questo conserviamo metadati: quale builder ha prodotto il sito, se è referenziato un backend, quali header di sicurezza c’erano, dimensioni e tempi. Non conserviamo il contenuto delle pagine.
Verifica di proprietà: le poche richieste in più#
Prima di un check più approfondito, chi l’ha chiesto deve dimostrare di controllare l’hostname. Sceglie un metodo, pubblica un token che gli diamo, e ci chiede di guardare. Niente di quanto segue succede se qualcuno non avvia una verifica per il tuo hostname esatto, e ogni controllo è uno di questi:
- DNS: una ricerca TXT di
_root92-verify.<il tuo hostname>, e dei nomi genitori fino al tuo dominio registrabile, per un valore che inizia conroot92-verify=. È una query al DNS, non una richiesta al tuo server. - File:
GET https://<il tuo hostname>/.well-known/root92-verification.txt, e nient’altro. Solo HTTPS, al massimo 1 KB letti, redirect seguiti solo sullo stesso hostname e al massimo 3. Questo solo percorso non consultarobots.txt: il file esiste solo se il proprietario l’ha messo lì, quindi se non l’ha fatto non c’è niente di tuo da leggere — nei log vedrai un404. Un redirect verso un altro percorso esce dall’eccezione e chiede prima arobots.txt. - Meta tag: la homepage, cercando
<meta name="root92-verification">dentro<head>. Questo rispettarobots.txtesattamente come il check di superficie. - Referto per email: al posto di tutto questo, la persona può indicarci un indirizzo del tuo dominio (per esempio
nome@tuodominio) e chiedere che il referto arrivi lì. Non dimostra la proprietà. Una persona del nostro team esamina ogni richiesta; solo se la approva eseguiamo il check e mandiamo il referto a quell’indirizzo. Sul nostro sito non compare niente.
Al massimo 50 controlli di verifica all’ora verso lo stesso hostname, chiunque li chieda; di questi, al massimo 10 da una stessa sessione del browser, e 30 all’ora dalla stessa persona. Il token è legato alla sua sessione del browser e al tuo hostname esatto: non copre gli altri tuoi sottodomini, e scade con la sessione.
Dopo che una prova DNS, file o meta è stata trovata, la cerchiamo di nuovo circa ogni 60 minuti finché la verifica è aperta, con la stessa richiesta e dentro un limite orario suo. La cerchiamo ancora una volta subito prima che parta il check approfondito, e prima del passo dell’email se l’ultima volta l’abbiamo trovata più di 120 minuti prima. Se la prova ora porta un token diverso, o il robots.txt ora vieta la lettura, la verifica decade subito. Se la prova semplicemente manca, non chiudiamo la verifica per una sola lettura: una cache DNS o un deploy possono nascondere una prova che c’è ancora. Decade solo se manca ancora almeno 60 minuti dopo la prima volta che non l’abbiamo trovata, o se il ricontrollo orario fallisce 3 volte di fila. Niente di ciò che una verifica decaduta aveva aperto resta aperto.
Dimostrata la proprietà e dato un secondo consenso, il check approfondito è la stessa sessione descritta sopra — stesso budget, stessi percorsi, robots.txt rispettato — solo sull’hostname verificato. Non legge il tuo database e non prova nessuna chiave che trova.
Cosa non leggiamo mai#
- Non leggiamo mai dati dal tuo database. Nemmeno una riga, nemmeno un conteggio, nemmeno «solo per vedere se risponde».
- Non usiamo mai una chiave o un token che troviamo. Una chiave pubblica trovata in un bundle si decodifica e si riporta; non viene mai presentata al tuo backend, in nessuna forma.
- Non scarichiamo mai il corpo di
/.envo/.git/config, nemmeno quando rispondono200. Registriamo lo status code e chiudiamo la connessione. La finding è «è raggiungibile», e non ha un campo per il contenuto. - Non scarichiamo mai le source map. Verifichiamo solo che esistano.
- Non tiriamo mai a indovinare. Nessuna wordlist, nessun
/.env.local, nessun/backup.zip, nessun nome di tabella. I percorsi qui sopra, richieste di verifica comprese, sono l’elenco completo. - Non scriviamo mai niente da nessuna parte.
- Non travestiamo mai la richiesta. Lo user-agent qui sopra è l’unico che usiamo.
Con che diritto#
Perché il proprietario dell’applicazione ce l’ha chiesto, un indirizzo alla volta, con una spunta, prima che partisse la prima richiesta.
Quel consenso è registrato insieme alla versione del testo con cui è stato dato, ed è l’unica cosa che fa partire uno scan. Non esiste un percorso di codice che scansioni qualcosa fuori da quel form: nessun batch, nessuna lista, nessun job programmato, nemmeno in sviluppo.
Se stai leggendo questa pagina e non sei tu che hai chiesto, allora qualcuno ha inserito un indirizzo che non era suo. Diccelo all’indirizzo qui sotto e ce ne occupiamo.
Una verifica è lo stesso genere di richiesta: qualcuno che dice che l’hostname è suo ci chiede di cercare un token che ha pubblicato. Se non ha potuto pubblicarlo, i controlli non trovano niente e non succede altro.
Perché non chiediamo al proprietario una prova#
Il check gratuito legge solo ciò che il tuo server consegna già a qualunque browser, quindi chiediamo una dichiarazione e non una prova di proprietà. A rendere innocua una dichiarazione falsa è la forma stessa del check: un indirizzo alla volta, al massimo 3 check all’ora sullo stesso hostname chiunque li chieda, il tuo robots.txt rispettato, nessuna chiave usata, nulla scaricato oltre la superficie pubblica, e ogni check registrato con orario, indirizzo e provenienza della richiesta. Tutto ciò che andrebbe oltre — per esempio verificare se un database risponde senza login — non fa mai parte di questo check automatico.
Quanto carico ti costa#
Deliberatamente poco, perché uno strumento che stressa il sito che sta controllando sarebbe lo strumento sbagliato.
- Una sessione per check, con un tetto di 20 secondi e 20 MB in totale — non per richiesta. Quando il budget finisce lo scan si ferma e riporta quello che è riuscito a stabilire.
- Al massimo 40 bundle.
- Al massimo 3 check all’ora verso lo stesso hostname, chiunque li chieda, e 20 all’ora dallo stesso mittente. Un check può valere fino a due sessioni di scan: il referto si calcola quando l’indirizzo viene inviato, e si ricalcola se poi quella persona chiede di essere ricontattata, così quello salvato è fresco. Per questo in un’ora puoi vederne fino a 6 e non 3. Il tetto segue i redirect: se l’indirizzo che ci hanno dato rimanda al tuo, è il tuo hostname a essere contato.
Come farci smettere#
Due strade, e non ce n’è una terza.
Mettici nel tuo robots.txt. Lo leggiamo prima della homepage e lo rispettiamo — se il percorso è vietato al nostro token non lo chiediamo, e il check si chiude come bloccato senza aver raccolto niente:
User-agent: Root92-MigrationScannerDisallow: /
Questo ferma tutto tranne il solo file di verifica descritto sopra (/.well-known/root92-verification.txt), che può creare solo un proprietario e che altrimenti è un 404. Per fermare anche quello, non pubblicare il file — oppure scrivici.
Oppure scrivici a info@root92.it, indicando l’hostname, e blocchiamo l’indirizzo dalla nostra parte, verifica compresa.
Se una nostra richiesta ti ha creato un problema vero, dillo in quella email. Preferiamo saperlo che non saperlo.