Che cos’è lo scanner

01Chi siamo#

Root92. Migriamo applicazioni costruite con builder AI verso codice che il proprietario controlla davvero.

Il check 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 programma che esplora il web in automatico (crawler), nessuna lista, nessuna scoperta automatica di siti. Guardiamo solo un indirizzo che qualcuno ha scritto di persona, e ne seguiamo i link solo nel check approfondito descritto più sotto: dentro quell’unico hostname, al massimo 10 pagine, e solo dopo che il proprietario ha dimostrato di controllarlo e l’ha chiesto.

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.

02Cosa leggiamo dal tuo server#

In una sola sessione, entro un limite complessivo 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 reindirizzamenti (redirect).
• Fino a 40 file JavaScript del sito stesso (bundle), quelli che il codice HTML della pagina dichiara — con <script src>, <link rel="modulepreload"> o <link rel="preload" as="script">. Gli script di terze parti non li scarichiamo.
• Niente che un browser non chiederebbe alla prima visita. In particolare, il check di superficie non chiede mai se esistono /.env, /.git/config, le tue source map, /sitemap.xml, /.DS_Store, /.htpasswd o la documentazione della tua API, e non manda mai la richiesta CORS con un’origine inventata: spuntare la casella non prova che il sito sia tuo, quindi quelle richieste aspettano il check approfondito descritto più sotto.
• Un avvio di connessione cifrata (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, DMARC, MTA-STS e TLS-RPT (TXT), MX e CAA. Quando il tuo record SPF rimanda ad altri record SPF (include:, redirect=), leggiamo anche quei record pubblici, al massimo 10 ricerche TXT in più, solo per contare le ricerche DNS che servirebbero a un server di posta.

Sul sottodominio di un builder saltiamo sia la connessione TLS sia i record DNS: sono della piattaforma, non dell’app.

Da quella sessione il check produce un breve riepilogo tecnico: quale builder ha prodotto il sito, se è referenziato un backend, quali intestazioni di sicurezza (header) c’erano, dimensioni e tempi. Non conserviamo il contenuto delle pagine. Abbiamo adottato misure tecniche e organizzative adeguate per tenere al sicuro queste informazioni.

03Verifica 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 con root92-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, reindirizzamenti seguiti solo sullo stesso hostname e al massimo 3. Questo solo percorso non consulta robots.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 un 404. Un reindirizzamento verso un altro percorso esce dall’eccezione e chiede prima a robots.txt.
• Meta tag: la home page, cercando <meta name="root92-verification"> dentro <head>. Questo rispetta robots.txt esattamente come il check di superficie.

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, subito prima che il suo referto parta per email verso il proprietario, e ogni volta che mostriamo al proprietario le rilevazioni nascoste al pubblico, salvo che l’abbiamo trovata meno di 10 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 aggiornamento del sito 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. Quando una verifica decade, tutto ciò che aveva sbloccato viene richiuso.

Chi avvia una verifica autorizza il check approfondito insieme alla ricerca del token, nello stesso consenso. Dimostrata la proprietà, il check approfondito parte appena il proprietario lo conferma. È la stessa sessione descritta sopra — stessi limiti, stessi percorsi, robots.txt rispettato — solo sull’hostname verificato, più una cosa che il check di superficie non fa mai: una richiesta HEAD — solo il codice di stato, mai il corpo — solo su questi percorsi fissi: /.env, /.git/config, i file .map dichiarati da un file JavaScript già scaricato, /sitemap.xml, /.DS_Store, /.htpasswd, e gli indirizzi predefiniti della documentazione API /openapi.json, /swagger.json e /v3/api-docs. Quando uno di loro sembra rispondere come un file, o risponde solo «vietato», una HEAD in più verso un indirizzo inventato (casuale, nuovo a ogni analisi) distingue una risposta vera da un sito che risponde allo stesso modo a qualunque indirizzo. Per un file il cui nome comincia col punto (/.DS_Store, /.htpasswd) un secondo indirizzo inventato comincia anche lui col punto, per un sito che risponde allo stesso modo a ogni nome così; per la documentazione API l’indirizzo inventato sta nella stessa cartella, quindi una HEAD così per cartella. Una HEAD alla tua home page su http:// in chiaro, dopo aver letto il robots.txt di quell’origine, solo per vedere se manda i visitatori su https://; nessun redirect viene seguito. E una HEAD alla tua home page con un header Origin che porta un indirizzo inventato sotto il dominio riservato .example, solo per leggere se il tuo server permette a qualunque sito di leggere le sue risposte con i cookie del visitatore; il corpo non viene mai letto.

Il proprietario può anche spuntare caselle separate. Ognuna aggiunge solo ciò che è descritto qui:

• Source map: il check approfondito scarica le source map indicate dai tuoi script e ricostruisce il codice in memoria, solo per indicare il file e la riga di una chiave esposta. Il codice non viene mai scritto su disco né conservato.
• Composizione del codice: il check approfondito usa lo stesso codice ricostruito, senza richieste in più, per misurare il codice non usato e le librerie incluse più volte. Conserviamo solo i percorsi dei file (senza nomi utente), i nomi e le versioni delle librerie e le dimensioni in byte.
• Accessibilità sulle pagine rese: un browser isolato, con lo stesso user-agent, apre al massimo 10 pagine dell’hostname verificato — la home page e le pagine a cui porta, fino a 2 link di distanza, ognuna confrontata con robots.txt prima di aprirla — e ne esegue il JavaScript, entro 3 minuti. Può raggiungere solo il tuo hostname, invia solo richieste GET e HEAD (moduli, caricamenti di file e WebSocket sono bloccati dentro il browser), parte senza cookie e viene distrutto alla fine. Conserviamo solo i percorsi delle pagine e le misure.
• Richieste di rete: lo stesso browser isolato apre una volta la home page, se robots.txt lo permette, ne esegue il JavaScript per i primi secondi dopo il caricamento senza cliccare niente, e registra le richieste che la pagina fa: metodi, indirizzi senza i loro valori, nomi dei parametri e delle intestazioni e host di terzi, mai i valori. Per giudicare la performance della pagina — in una finestra da desktop, senza rallentare la rete né il processore, quindi i tempi sono una misura di laboratorio e non ciò che vede un visitatore da telefono — legge anche quanti byte ha trasferito ogni risposta, il suo tipo di file, il protocollo con cui è arrivata e se era compressa, quando sono comparsi il primo contenuto e l’elemento più grande e quanto si è spostato il layout; e, nella pagina caricata, se l’immagine principale e quelle più in basso sono impostate per caricarsi dopo, quanti fogli di stile trattengono il primo disegno e se i fogli di stile usano @import o font senza font-display. Si conservano solo gli esiti sì/no di quindici controlli, mai i numeri, gli indirizzi o il contenuto della pagina; per ora quei quindici controlli sono spenti, e finché non si accendono non se ne conserva nessun esito. Raggiunge solo il tuo hostname e invia solo richieste GET e HEAD, come il controllo di accessibilità.

Nessuna di queste caselle legge il tuo database o prova una chiave che troviamo.

Se il proprietario spunta la casella della connessione sicura, e il server è suo e non di una piattaforma condivisa, il check approfondito apre al massimo 7 connessioni TLS in più verso di esso, una alla volta, entro 20 secondi: una come quella di un browser di oggi, una per ogni versione di TLS da 1.0 a 1.3, e due che offrono solo suite di cifratura vecchie. Non passa nessuna richiesta HTTP, quindi non portano nessuno user-agent; si chiudono appena la cifratura è concordata. Per le altre caselle che il proprietario può spuntare, il check approfondito chiede a servizi esterni del tuo sito e non manda niente al tuo server: l’indirizzo del sito a un insieme pubblico di dati sulla velocità per i visitatori reali, il nome del dominio al registro della sua estensione, il nome host alla lista HTTPS pubblica dei browser, nome e versione esatta delle librerie che riconosciamo a un database aperto di segnalazioni di sicurezza, il nome del dominio a un database pubblico di violazioni di dati note e a una piattaforma pubblica di codice. L’informativa privacy elenca cosa riceve ognuno e cosa conserviamo.

04Cosa 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 file JavaScript si decodifica e si riporta; non viene mai presentata al tuo backend, in nessuna forma.
• Non scarichiamo mai il corpo di /.env, /.git/config, /.DS_Store, /.htpasswd o di un file di documentazione API, nemmeno quando rispondono 200. Registriamo il codice di stato e chiudiamo la connessione. La rilevazione dice solo «è raggiungibile», e non ha un campo per il contenuto.
• Non scarichiamo mai le source map al di fuori del check approfondito descritto sopra, e solo quel check chiede se esistono.
• Non procediamo mai per tentativi. Nessun elenco di nomi da provare, nessun /.env.local, nessun /backup.zip, nessun nome di tabella. I percorsi qui sopra, richieste di verifica comprese, e nel check approfondito le pagine a cui porta il tuo stesso sito, sono l’elenco completo.
• Non scriviamo mai niente da nessuna parte.
• Non mascheriamo mai la richiesta. Lo user-agent qui sopra è l’unico che usiamo.

05Con quale 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 un’analisi. Non esiste un percorso di codice che scansioni un indirizzo che nessuno ha inviato: nessuna elaborazione in serie, nessun elenco, nessun crawler. Gli unici controlli che si ripetono da soli sono quelli descritti sopra per un proprietario verificato: il ricontrollo periodico della sua prova e, se lo chiede, il check approfondito ripetuto.

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.

06Perché non chiediamo al proprietario una prova#

Il check di superficie 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 (tranne il proprietario, una volta provata la proprietà), 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 autenticazione — non fa mai parte di questo check automatico.

07Quanto carico generiamo sul tuo server#

Molto poco, per scelta: uno strumento che sovraccarica 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 limite è raggiunto l’analisi si ferma e riporta quello che è riuscito a stabilire.
• Al massimo 40 file JavaScript.
• Nel check approfondito, solo se il proprietario lo chiede: al massimo 10 caricamenti di pagina in un browser, una pagina alla volta, entro 3 minuti — più o meno quello che causa un visitatore che legge qualche pagina.
• Nel check approfondito, solo se il proprietario lo chiede e il server è suo: al massimo 7 connessioni TLS, una alla volta, entro 20 secondi, senza chiedere nessuna pagina.
• 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 analisi: 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 reindirizzamenti: se l’indirizzo che ci hanno dato rimanda al tuo, è il tuo hostname a essere contato. L’unica eccezione sei tu: dopo che hai provato di essere il proprietario del sito, i tuoi check non contano per questo tetto e non riducono quelli disponibili per gli altri.

08Come fermarci#

Ci sono due modi.

Aggiungi una regola per noi nel tuo robots.txt. Lo leggiamo prima della home page 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-MigrationScanner
• Disallow: /

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, scrivilo in quella email. Preferiamo saperlo.