Il tuo repo Cursor può trasformare una URL in una porta d’ingresso

Una nuova API rende il browser un componente del backend

Bun 1.4 ha introdotto Bun.WebView, una funzione che porta l’automazione del browser dentro Bun: può usare WebKit su macOS oppure controllare Chromium tramite Chrome DevTools Protocol. L’esperimento descritto nella fonte costruisce un’API capace di caricare una pagina ed eseguire JavaScript, con un consumo stimato di 192–256 MB per un browser completo su pagine complesse.

La notizia è raccontata da A shot-scraper-style JSON API on Bun 1.4's new Bun.WebView, pubblicato il 20 agosto 2026.

Per un founder, il punto è immediato: una funzione che accetta una URL, apre una pagina e restituisce il risultato può diventare una feature utile in pochi minuti. Ma se hai costruito il backend con Cursor, quella stessa funzione può anche trasformarsi in una richiesta server-side verso destinazioni che l’utente non dovrebbe poter raggiungere.

Il buco tecnico di oggi è l’SSRF, cioè Server-Side Request Forgery: il server esegue una richiesta verso una risorsa scelta o influenzata dall’utente, aggirando i confini di rete previsti dall’architettura.

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina un prodotto che offre una funzione “analizza questa pagina”. L’utente inserisce un indirizzo, il backend avvia un browser, aspetta il caricamento, esegue uno script e restituisce HTML, testo o JSON.

Il percorso può essere molto semplice:

POST /api/render
{
  "url": "https://example.com/report"
}

Il server apre la pagina e produce il risultato. In sviluppo funziona. La demo è convincente. Il problema è cosa succede quando url non punta a un sito pubblico ordinario.

Se il backend può raggiungere indirizzi interni, una richiesta potrebbe tentare di accedere a:

• servizi disponibili soltanto nella rete privata;
• pannelli amministrativi interni;
• endpoint cloud accessibili dall’ambiente di esecuzione;
• porte locali esposte da altri processi;
• sistemi di staging non pensati per essere pubblici.

Non serve che l’attaccante conosca già il contenuto. È sufficiente che il tuo server faccia da intermediario e restituisca una risposta, un errore dettagliato o un comportamento osservabile.

Il rischio aumenta quando l’automazione del browser non si limita a una singola richiesta HTTP. Una pagina può caricare risorse secondarie, seguire redirect, eseguire JavaScript, effettuare chiamate successive o scaricare file. Se il tuo endpoint consente tutto questo senza un perimetro chiaro, hai trasformato una semplice funzione di rendering in un proxy molto potente.

Cursor non è il problema. Il problema è lasciare a una URL ricevuta dal client il controllo su destinazione, redirect, protocolli, porte e accesso alla rete.

Perché ora ti serve un audit: devi verificare il confine tra URL e rete

Un audit VibeInspect serve a capire se il repository applica davvero un limite alle destinazioni raggiungibili oppure se il browser server-side può muoversi liberamente.

Nel caso dell’SSRF, l’analisi deve ricostruire il flusso completo:

• dove viene ricevuta la URL;
• se il valore viene validato prima di essere usato;
• quali protocolli sono consentiti;
• se vengono bloccati indirizzi locali, privati e riservati;
• come vengono gestiti DNS e redirect;
• se la validazione avviene soltanto prima della prima richiesta;
• se il browser può eseguire JavaScript o caricare risorse esterne;
• quali header, cookie o credenziali vengono inoltrati;
• quali dati della risposta tornano al client;
• quali limiti esistono su tempo, dimensione, numero di richieste e porte.

Questo è il punto in cui un audit diventa più utile di una semplice verifica manuale. Non basta vedere una funzione isValidUrl(). Devi sapere se la destinazione effettiva dopo redirect e risoluzione DNS resta autorizzata. Non basta vietare localhost come testo: devi considerare anche indirizzi equivalenti o risolti dinamicamente. Non basta bloccare la navigazione principale se una pagina può caricare risorse da una rete interna.

Il verdetto che ti serve è concreto: l’endpoint accetta URL HTTPS, ma segue redirect verso reti private senza rivalidazione; oppure il browser viene avviato con accesso alla rete interna e restituisce il corpo della risposta all’utente. In alternativa, il flusso può risultare sufficientemente delimitato da allowlist, isolamento e controlli coerenti.

VibeInspect parte da uno ZIP del repository, analizza codice e configurazione con specialisti AI e produce un PDF con score, verdetto ed evidenze. Non richiede un server dedicato e il sorgente viene cancellato a fine analisi.

Per un sospetto tecnico come una URL interna raggiungibile dal backend, il piano adatto è Diagnostic: servono file, righe ed evidenze sul percorso di rete e sull’effettivo controllo delle destinazioni.

Cosa un linter non vede

Un linter può verificare sintassi, tipi, import inutilizzati e alcuni pattern locali. Non può stabilire se una URL pubblica viene trasformata, dopo un redirect, in una richiesta verso una rete privata.

Questo codice può essere perfettamente valido:

const target = new URL(req.body.url);
const page = await browser.open(target.href);
return page.content();

Il problema non è la sintassi. È il contesto operativo. Il linter non sa quali reti può raggiungere il processo, se Chromium segue redirect, se il browser usa cookie di servizio o se la risposta viene restituita integralmente all’utente.

Nemmeno una scansione delle dipendenze è sufficiente. Potresti usare librerie aggiornate e non avere vulnerabilità note, ma mantenere comunque un’API che permette al client di scegliere qualunque destinazione. L’SSRF spesso nasce dall’uso legittimo di componenti legittimi.

Anche i test possono essere troppo ottimisti. Un test che apre https://example.com dimostra soltanto che il caso nominale funziona. Non dimostra cosa succede con redirect, porte non standard, hostname risolti più volte, errori di rete o risorse caricate dalla pagina.

Il difetto è una proprietà del sistema: input controllato dall’utente, browser server-side, rete disponibile e risposta osservabile. Sono quattro elementi che un controllo locale raramente comprende insieme.

Cosa fare questa settimana

Se hai spedito con Cursor una funzione che apre pagine o esegue JavaScript lato server, fai questo controllo:

1. Elenca tutti gli endpoint che ricevono URL, hostname, webhook o destinazioni di callback.
2. Definisci esplicitamente quali domini e protocolli sono ammessi.
3. Blocca indirizzi locali, privati, riservati e metadati cloud non necessari.
4. Rivalida la destinazione dopo ogni redirect e dopo la risoluzione DNS.
5. Impedisci protocolli diversi da quelli realmente necessari, come file:, data: o schemi personalizzati.
6. Valuta se JavaScript, cookie, upload e download servono davvero al caso d’uso.
7. Esegui il browser in un ambiente isolato con rete e credenziali minime.
8. Imposta timeout, limiti di risposta e numero massimo di richieste secondarie.
9. Non restituire al client errori di rete, header o contenuti più ampi del necessario.
10. Aggiungi test negativi per redirect, host interni, porte alternative e risoluzioni DNS inattese.

La domanda decisiva è semplice: una URL controllata dall’utente può convincere il tuo server a parlare con una rete che l’utente non dovrebbe vedere?

“Il browser apre la pagina” non è un verdetto. “Sono ammesse soltanto destinazioni esplicite, i redirect vengono rivalidati, il processo non ha accesso inutile alla rete interna e la risposta è filtrata” lo è.

Se vuoi un primo orientamento, carica il tuo repo su VibeInspect.ai con Snapshot. Se hai già un endpoint che apre URL, esegue JavaScript o restituisce contenuti remoti, scegli Diagnostic per ottenere evidenze su file, righe e flusso.

Cursor può aiutarti a trasformare una API sperimentale in una feature pronta per gli utenti. Prima del go-live, verifica però che il tuo server sappia distinguere una pagina pubblica da una porta d’ingresso verso la rete privata.