Browser Use cambia il perimetro: controlla l’SSRF nel tuo repo v0

Il browser non è più una semplice finestra: è un confine di sicurezza

Anthropic ha presentato Browser Use, uno strumento che permette a Claude di leggere la struttura accessibile di una pagina, individuare elementi interattivi e inviare azioni come click, compilazioni e navigazione. Il punto importante è architetturale: Anthropic non esegue il browser al posto dello sviluppatore. Il browser, la sessione e i relativi file restano nell’ambiente dell’applicazione che integra l’API.

La fonte originale è Anthropic’s new browser tool doesn’t actually run a browser.

Questa scelta lascia più controllo al team, ma anche più responsabilità. Se il tuo prodotto accetta un URL e lo fa visitare, analizzare o trasformare da un browser automatizzato, quell’URL diventa un input potenzialmente ostile. Il problema concreto di oggi è SSRF: una richiesta server-side che, usando un indirizzo controllato dall’utente, raggiunge risorse interne che non dovrebbero essere accessibili dall’esterno.

Cosa significa se il tuo codice l’ha scritto v0

Con v0 puoi costruire rapidamente un’interfaccia che riceve un URL, mostra un’anteprima, estrae contenuti o avvia una procedura automatizzata. Il flusso sembra innocuo:

1. l’utente incolla un indirizzo;
2. il frontend lo invia al backend;
3. il backend apre la pagina con una libreria HTTP o un browser headless;
4. il risultato torna nella UI.

Il buco arriva quando il server tratta ogni URL come una destinazione valida. Un utente può provare a passare un indirizzo pubblico, ma anche un hostname interno, una destinazione locale o un endpoint accessibile soltanto dalla rete del deployment. Se il backend segue redirect, risolve DNS senza ulteriori controlli o permette protocolli non previsti, la funzione di anteprima può diventare un proxy verso l’infrastruttura.

In un repo generato con v0, il rischio può comparire in forme diverse:

• un endpoint /api/fetch che usa direttamente url ricevuto dal client;
• una funzione browser che naviga verso qualsiasi schema o hostname;
• redirect seguiti automaticamente senza rivalidare la destinazione finale;
• controlli basati soltanto su una lista di domini consentiti, aggirati con DNS o varianti del nome;
• accesso dal server a localhost, reti private o metadata del provider cloud;
• una risposta dell’endpoint che restituisce troppo contenuto o errori interni.

Non è un’accusa a v0. È l’effetto normale di uno scaffolding veloce: l’interfaccia e il percorso felice arrivano prima delle regole che definiscono il perimetro di rete. Se Browser Use lascia il browser nel tuo ambiente, il tuo ambiente deve decidere con precisione dove quel browser può andare.

Perché ora ti serve un audit: il verdetto sulla destinazione

Il punto non è chiedere a un agente di “controllare l’URL”. Il punto è sapere quale destinazione viene effettivamente raggiunta dopo parsing, risoluzione DNS, redirect e navigazione.

Per il tuo repo v0, l’audit deve rispondere a una domanda precisa:

un input controllato dall’utente può indurre il backend o il browser headless a raggiungere una rete interna o una risorsa non autorizzata?

Per arrivare al verdetto bisogna seguire il flusso completo:

1. dove nasce l’URL nella UI;
2. quale endpoint lo riceve;
3. quali validazioni vengono applicate prima della richiesta;
4. quale client effettua la connessione;
5. se vengono seguiti redirect;
6. se l’hostname viene risolto e ricontrollato dopo il DNS;
7. quali protocolli, porte e intervalli IP sono consentiti;
8. quali dati della risposta vengono restituiti all’utente o al modello.

Questo è il lavoro che manca tra “la demo apre una pagina” e “il servizio ha un confine verificabile”. Un audit VibeInspect prende il repository ZIP, ricostruisce i percorsi rilevanti e restituisce un PDF con score e verdetto. Nel piano Diagnostic può indicare file, righe ed evidenze del percorso che collega input, richiesta e destinazione.

Non modifica il codice. Non è un pentest. Non esegue una scansione live della tua rete. Ti dice però se nel repository esiste una protezione dimostrabile oppure se una funzione server-side si fida di un URL che l’utente controlla.

Il verdetto utile non è “abbiamo usato una libreria sicura”. È: l’URL viene limitato a destinazioni consentite in ogni passaggio, inclusi redirect e risoluzione DNS, oppure esiste un percorso che può portare il server fuori dal perimetro previsto.

Le evidenze che distinguono una protezione reale da un filtro superficiale

L’SSRF raramente si dimostra con una singola riga. Di solito emerge dalla combinazione tra input, client HTTP e rete.

• URL passato direttamente al client. Chiamate come fetch(userUrl), page.goto(userUrl) o equivalenti meritano una verifica immediata.
• Allowlist applicata solo al testo iniziale. Controllare il dominio prima della richiesta non basta se un redirect porta a un’altra destinazione.
• DNS non ricontrollato. Un hostname può risolvere verso un indirizzo pubblico durante il controllo e verso una rete privata quando parte la connessione, oppure cambiare tra validazione e uso.
• Schemi e porte troppo permissivi. Se il codice accetta più protocolli del necessario o consente porte arbitrarie, il perimetro si allarga senza motivo.
• Browser con accesso alla rete del server. Un browser headless eseguito nello stesso ambiente del backend può raggiungere servizi interni anche se la UI è pubblica.
• Redirect e navigazioni secondarie. La pagina iniziale può caricare risorse, iframe o script da destinazioni che il controllo iniziale non ha valutato.
• Risposte troppo dettagliate. Header, messaggi di errore o body restituiti senza filtro possono rivelare informazioni sull’infrastruttura oltre al contenuto richiesto.

L’audit non deve produrre una lista di termini tecnici. Deve collegare la regola al comportamento: quale URL entra, quale connessione esce e quali controlli separano l’utente da una risorsa interna.

Cosa un linter non vede

Un linter può segnalare una funzione non usata, un tipo errato, una promessa non gestita o una dipendenza obsoleta. Può anche individuare chiamate potenzialmente rischiose. Ma non dimostra da solo che il server non possa raggiungere una rete privata.

Non vede, da solo, che:

• l’allowlist controlla il dominio ma non l’indirizzo IP risolto;
• un redirect conduce a localhost o a una rete privata;
• il browser e l’API condividono credenziali o accesso alla stessa rete;
• il controllo sull’URL avviene prima di una seconda navigazione;
• una variabile d’ambiente abilita proxy o networking più ampio in produzione;
• un errore di rete restituisce dettagli interni al client.

Nemmeno un test felice è sufficiente. Puoi verificare che un URL pubblico venga aperto correttamente e non aver mai testato redirect, hostname locali, indirizzi IPv6, rappresentazioni alternative degli IP o risposte lente che cambiano il percorso.

Il linter controlla la forma locale. L’audit verifica il confine tra input utente, richiesta server-side e rete raggiungibile.

Cosa fare questa settimana

Scegli una sola funzione del prodotto che riceve un URL: anteprima, importazione, scraping, rendering o automazione del browser.

Poi documenta:

• quali schemi sono consentiti;
• quali domini sono necessari;
• come vengono risolti e verificati gli indirizzi;
• cosa succede dopo un redirect;
• quali porte e reti sono raggiungibili dal runtime;
• quale parte della risposta viene restituita;
• quali log permettono di ricostruire destinazione e risultato.

Se non sai indicare file, funzione e regola che impediscono a un URL controllato dall’utente di raggiungere una risorsa interna, non aggiungere ancora un’altra automazione. Ti serve prima un verdetto sul repo.

Carica lo ZIP su VibeInspect.ai. Per questo caso sceglierei il piano Diagnostic, perché il problema è tecnico e hai bisogno di evidenze su file, righe, validazioni e percorso di rete.

L’obiettivo non è dimostrare che v0 abbia scritto codice “sbagliato”. È sapere se la tua funzione apre soltanto le pagine che deve aprire, oppure se può diventare una porta verso la rete che non avevi intenzione di esporre.