Salta al contenuto principale

Politica Stessa Origine e Proxy Web: Analisi Tecnica della Sicurezza

Scritto da
Smith
Smith
Tempo di lettura
17 min di lettura
Pubblicato il
2 mar 2026
Politica Stessa Origine e Proxy Web: Analisi Tecnica della Sicurezza

Quando abbiamo costruito ProxyOrb, ci siamo trovati di fronte a un paradosso fondamentale a ogni decisione progettuale: un proxy web funziona facendo credere al browser che contenuti di terze parti siano contenuti same-origin. Il che equivale, per definizione, a ingannare il modello di sicurezza centrale del browser. Eppure i browser moderni hanno trascorso quindici anni ad aggiungere difese sempre più sofisticate proprio contro questo tipo di confusione delle origini.

Questo articolo esamina quella tensione partendo dai principi fondamentali. Se sei un ricercatore di sicurezza, un penetration tester o un ingegnere di sicurezza browser che vuole capire come i proxy web interagiscono concretamente con la politica stessa origine — non a livello concettuale, ma a livello di header HTTP, sorgente di Chromium e decisioni ingegneristiche in produzione — questo articolo fa per te.

Copriremo le fondamenta della SOP, il riscrittura degli URL, CORS, CORB/CORP, COEP/COOP, i Service Worker, gli iframe e le implicazioni di sicurezza sia per gli operatori di proxy che per i loro utenti.

1. Le Fondamenta della Politica Stessa Origine

La politica stessa origine (SOP) è definita da una tripla: schema + host + porta. Due URL sono same-origin solo se tutti e tre i componenti corrispondono esattamente. https://example.com:443 e http://example.com:80 sono cross-origin nonostante puntino allo stesso server.

Ciò che viene spesso frainteso è cosa la SOP impedisce effettivamente rispetto a ciò che permette. La SOP non blocca:

  • Il caricamento di immagini (<img src>) tra origini diverse
  • Il caricamento di script (<script src>) tra origini diverse
  • Il caricamento di fogli di stile (<link rel="stylesheet">) tra origini diverse
  • L'incorporamento di iframe tra origini diverse (anche se il contenuto del documento incorporato è isolato)
  • L'invio di form (<form action>) verso origini diverse

Ciò che la SOP impedisce è la lettura della risposta delle richieste cross-origin effettuate tramite fetch() o XMLHttpRequest. La richiesta parte — il round-trip di rete avviene — ma il corpo della risposta e gli header vengono tenuti nascosti al JavaScript in esecuzione su un'origine diversa.

Questa distinzione è di enorme importanza per i proxy web. Il compito principale di un proxy è proprio quello di collassare due origini (il server proxy e il server di destinazione) in una sola, eliminando il confine cross-origin. Una volta che tutte le risorse sembrano provenire da https://proxyorb.com, le restrizioni della SOP sulla lettura delle risposte diventano semplicemente irrilevanti.

Lo "spazio legittimo" che i proxy web sfruttano è la riscrittura degli URL: invece di https://example.com/api/data, ogni richiesta diventa https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==. Dal punto di vista del browser, si tratta di una richiesta same-origin. La SOP non è stata aggirata — è stata resa irrilevante cambiando l'origine apparente di tutti i contenuti.

2. L'Architettura di Riscrittura degli URL di ProxyOrb

Per capire le implicazioni di sicurezza, è necessario comprendere il meccanismo di codifica. ProxyOrb utilizza un parametro URL chiamato __pot (proxy origin token) che contiene l'origine di destinazione codificata in Base64.

Il Parametro __pot

Il parametro __pot codifica sempre l'origine (schema + host, senza il path) della destinazione, non l'URL completo. Questo significa che https://example.com/some/deep/path?foo=bar e https://example.com/other/page generano entrambi lo stesso valore __pot: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (la codifica Base64 di https://example.com). Il path effettivo e la query string vengono preservati verbatim nel path e nella query string dell'URL proxy.

Quando un utente naviga verso https://proxyorb.com/?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==, il gateway lo decodifica e ricostruisce l'URL originale:

-- Gateway pseudocode: decoding the proxy request

function resolve_original_url(proxy_url):
    pot_value = parse_query_param(proxy_url, "__pot")
    if not pot_value:
        return error("Missing origin token")

    original_origin = base64_decode(pot_value)
    -- e.g. "https://example.com"

    validate_not_private_ip(original_origin)  -- SSRF protection

    -- Replace the proxy host with the target host, keep path/query intact
    original_url = replace_origin(proxy_url, original_origin)
    return original_url

Il gateway inoltra quindi la richiesta al server di destinazione reale, riscrivendo l'header Origin in modo che il server upstream veda il proprio dominio anziché quello del proxy:

-- Set outbound headers toward the target server

request.headers["Host"]   = target_host
request.headers["Origin"] = target_origin   -- e.g. "https://example.com"
-- Remove all internal proxy headers before forwarding

Riscrittura degli URL Lato Client tramite Service Worker

Il gateway gestisce il lato server. Il lato client — riscrivere gli URL nelle risposte HTML, JavaScript e CSS affinché tutte le sotto-richieste continuino a passare attraverso il proxy — è gestito da un Service Worker.

La trasformazione centrale converte qualsiasi URL trovato nel contenuto della pagina nel formato proxy:

-- Service Worker pseudocode: toProxyURL()

function toProxyURL(originalUrl, currentPageUrl):
    if isSameOrigin(originalUrl, currentPageUrl):
        return originalUrl   -- already proxy-origin, no rewrite needed

    -- Extract path/query/hash from the original URL
    -- Build a new URL rooted at the proxy origin
    proxyPath   = extractPathAndQuery(originalUrl)
    potValue    = base64encode(extractOrigin(originalUrl))
    proxyUrl    = proxy_origin + proxyPath + "?__pot=" + potValue

    return proxyUrl

Per esempio, https://cdn.example.com/bundle.js referenziato all'interno di una pagina in proxy diventa https://proxyorb.com/bundle.js?__pot=aHR0cHM6Ly9jZG4uZXhhbXBsZS5jb20=.

Questa riscrittura è capillare: copre fetch(), XMLHttpRequest, <script src>, <img src>, connessioni WebSocket e tag <link>. Quando ogni URL nella pagina punta all'origine del proxy, il browser non effettua mai una richiesta cross-origin — ogni richiesta è same-origin per costruzione.

Recupero del __pot Senza Navigazione Completa

Un caso limite sottile si presenta con richieste che originano dall'interno di una pagina in proxy ma sono prive del parametro __pot — ad esempio, un fetch('/api/data') relativo che parte prima che il Service Worker abbia riscritto l'URL, oppure una richiesta emessa da uno script iniettato dinamicamente che ha bypassato il rewriter degli URL.

Il Service Worker risolve il token mancante tramite una ricerca a cascata:

-- Service Worker pseudocode: recovering the origin token

function resolveMissingPot(fetchEvent):
    candidates = [
        getUrlOfControlledTab(fetchEvent.clientId),   -- most reliable
        inferUrlFromFetchEvent(fetchEvent),             -- from clientId / resultingClientId
        fetchEvent.request.referrer,                    -- referrer header
    ]

    for url in candidates:
        pot = extractQueryParam(url, "__pot")
        if pot: return pot

    return null   -- cannot recover; let the gateway handle or reject

Il gateway dispone di un percorso di recupero parallelo: se una richiesta arriva senza __pot ma porta un header Referer che punta a un URL same-origin che include __pot, il gateway estrae il token dal referer e lo associa alla richiesta corrente. Questo gestisce scenari di navigazione in cui il token è stato rimosso dal JavaScript della pagina prima che la richiesta raggiungesse il gateway.

3. CORS: Il Sistema di Permessi Cross-Origin Espliciti

CORS (Cross-Origin Resource Sharing) è stato progettato per permettere ai server di aderire volontariamente all'accesso cross-origin inviando specifici header di risposta. Dal punto di vista del proxy, CORS crea due problemi distinti.

Problema 1: Intercettazione del Preflight CORS

Quando il JavaScript in esecuzione su una pagina esegue una richiesta fetch() con header non semplici (ad es. Authorization, Content-Type: application/json), il browser invia prima una richiesta OPTIONS di preflight. Se la risposta al preflight del server di destinazione non include header CORS permissivi, la richiesta reale viene bloccata.

Nell'architettura di ProxyOrb, il Service Worker intercetta tutte le richieste OPTIONS e risponde sinteticamente — prima ancora che raggiungano il gateway — restituendo una risposta che sblocca la richiesta reale:

-- Service Worker pseudocode: synthetic CORS preflight

function handlePreflight(request):
    origin = request.headers["Origin"] or "*"

    return Response(status=204, headers={
        "Access-Control-Allow-Origin":      origin,
        "Access-Control-Allow-Methods":     "GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD",
        "Access-Control-Allow-Headers":     "*",
        "Access-Control-Allow-Credentials": "true",
        "Access-Control-Max-Age":           "86400",
        "Vary":                             "Origin",
    })

A livello di gateway, ogni risposta in proxy riceve header CORS equivalenti:

-- Gateway pseudocode: set CORS on outbound response

response.headers["Access-Control-Allow-Origin"]      = original_origin
response.headers["Access-Control-Allow-Headers"]     = "*"
response.headers["Access-Control-Allow-Credentials"] = "true"

Problema 2: Richieste con Credenziali

La combinazione di Access-Control-Allow-Credentials: true e un Access-Control-Allow-Origin non wildcard è significativa. CORS richiede un valore di origine esplicito (non *) ogniqualvolta le credenziali sono incluse. Il Service Worker emette tutte le richieste in uscita con credentials: 'include', quindi il gateway deve restituire l'esatta origine richiedente anziché un wildcard.

Questo significa che tutti i cookie memorizzati sotto proxyorb.com — accumulati da ogni sito di destinazione visitato dall'utente attraverso il proxy — vengono inviati su ogni richiesta in proxy. È intenzionale (mantiene lo stato di sessione per i siti in cui si è effettuato l'accesso), ma è anche un'importante considerazione di sicurezza di cui discutiamo nella Sezione 8.

Il Pattern Strip-and-Replace degli Header CORS

Una risposta in proxy può portare header CORS dal server di destinazione che sono errati dal punto di vista del browser (fanno riferimento all'origine di destinazione, non a quella del proxy). Il Service Worker li rimuove e li sostituisce:

-- Service Worker pseudocode: sanitize response headers

function sanitizeResponseHeaders(response):
    headers = copy(response.headers)

    -- Remove target-site directives that would confuse the browser
    headers.delete("Content-Security-Policy")
    headers.delete("Content-Security-Policy-Report-Only")
    headers.delete("X-Frame-Options")
    headers.delete("X-Content-Type-Options")

    -- Replace with proxy-origin-correct CORS headers
    headers.set("Access-Control-Allow-Origin",      proxy_origin)
    headers.set("Access-Control-Allow-Credentials", "true")
    headers.set("Access-Control-Allow-Headers",     "*")
    headers.set("Vary", "Origin")

    return headers

4. CORB e CORP: Le Difese più Aggressive di Chromium

CORS opera su adesione esplicita dei server. Chromium ha aggiunto due meccanismi attivi per impostazione predefinita, indipendentemente dalla configurazione CORS.

Cross-Origin Read Blocking (CORB)

CORB è stato introdotto in Chrome 67 (2018) come parte delle mitigazioni Spectre. L'intuizione centrale: anche se il corpo di una risposta cross-origin non viene mai letto dal JavaScript, il fatto che sia stato scaricato e decodificato dal processo di rendering significa che esiste nello spazio di indirizzamento di quel processo. Gli attacchi di classe Spectre possono quindi estrarlo tramite canali laterali.

CORB impedisce a certe risposte cross-origin di entrare nel processo di rendering. Nello specifico, quando un tag <script> o <img> scarica una risposta cross-origin con Content-Type text/html, text/xml o application/json, Chromium ispeziona il corpo (usando uno sniffer MIME definito nella spec CORB) e, se il tipo corrisponde, sostituisce la risposta con una vuota prima che il renderer la veda.

Per un proxy web, CORB sarebbe catastrofico se le richieste fossero effettivamente cross-origin. Un endpoint API che restituisce application/json scaricato da un tag <script> tornerebbe silenziosamente vuoto. Tuttavia, poiché ProxyOrb riscrive tutti gli URL per essere same-origin, la condizione cross-origin di CORB non viene mai innescata — il browser non vede mai una risposta JSON cross-origin, perché dal suo punto di vista tutte le risposte provengono da proxyorb.com.

L'unico caso in cui CORB è rilevante è durante il periodo di transizione prima che il Service Worker sia completamente registrato e stia intercettando le richieste. Se una richiesta sfugge alla riscrittura degli URL durante quella finestra, CORB potrebbe bloccarla. Questa race condition è il motivo per cui ProxyOrb mantiene anche un livello di intercettazione nel thread principale che patcha XMLHttpRequest, fetch e i setter degli attributi DOM in modo sincrono prima che qualsiasi JavaScript della pagina venga eseguito — fornendo un fallback durante l'avvio del Service Worker.

Vale la pena notare che CORB è stato parzialmente sostituito da Opaque Response Blocking (ORB), che Chromium sta adottando. ORB affina le regole di CORB per ridurre i falsi positivi mantenendo le protezioni Spectre. Le implicazioni di compatibilità per i proxy sono simili.

Cross-Origin Resource Policy (CORP)

CORP, definito nella specifica Fetch, consente ai server di dichiarare che le proprie risorse devono essere caricate solo da contesti same-origin o same-site:

Cross-Origin-Resource-Policy: same-origin

Quando Chromium incontra questo header su una richiesta di sotto-risorsa cross-origin, blocca completamente la risposta. Questo è più aggressivo di CORB — si applica indipendentemente dal tipo di contenuto e non può essere aggirato tramite MIME sniffing.

Ancora una volta, poiché la riscrittura degli URL di ProxyOrb garantisce che tutte le richieste siano same-origin dal punto di vista del browser, gli header CORP dei server di destinazione non innescano il blocco. Il gateway rimuove anche questi header dalle risposte in modo difensivo, gestendo eventuali casi limite in cui una richiesta sfugge alla riscrittura degli URL.

Il problema più profondo con CORP è in realtà un caso in cui l'architettura proxy aiuta la compatibilità: se https://api.example.com e https://www.example.com vengono entrambi proxati, entrambi mappano alla stessa origine proxy, quindi una fetch dall'uno all'altro è ora genuinamente same-origin — le restrizioni CORP non si applicano più tra di loro.

5. COEP e COOP: Isolamento Cross-Origin

A partire da Chrome 92 (2021), l'accesso a SharedArrayBuffer — e di conseguenza ai timer ad alta risoluzione usati da alcune API di performance — è stato limitato alle pagine che hanno aderito all'isolamento cross-origin. Questa adesione richiede due header di risposta che operano in tandem.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

Quando una pagina invia questo header, il browser impone che ogni sotto-risorsa caricata da quella pagina soddisfi uno di questi requisiti:

  1. Sia same-origin, OPPURE
  2. Invii esplicitamente Cross-Origin-Resource-Policy: cross-origin, OPPURE
  3. Abbia una risposta CORS permissiva per la fetch con credenziali

Il problema per i proxy web: se un sito di destinazione invia COEP: require-corp sul suo documento principale, e quel documento viene servito attraverso il proxy con l'header preservato, il browser ora richiede che ogni sotto-risorsa caricata da quella pagina aderisca anch'essa. Qualsiasi risorsa che non lo fa — e la maggior parte non lo farà — causa un errore di rete.

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

COOP controlla se una pagina può condividere un browsing context group con pagine cross-origin. Quando impostato su same-origin, una navigazione cross-origin apre un nuovo browsing context group, interrompendo i riferimenti window.opener e i canali postMessage tra la pagina e qualsiasi opener cross-origin.

Per un proxy, COOP è meno immediatamente distruttivo di COEP, ma rompe comunque i siti che si basano su flussi postMessage cross-origin (i flussi OAuth con popup sono l'esempio più comune).

Il Dilemma dell'Operatore Proxy

Questo è il compromesso più difficile che affrontiamo in ProxyOrb:

Opzione A: Rimuovere COEP e COOP dalle risposte.

  • Pro: Il caricamento delle sotto-risorse funziona normalmente; la pagina in proxy non applica queste restrizioni.
  • Contro: Stiamo rimuovendo header di sicurezza che il sito di destinazione ha intenzionalmente impostato. Se il sito usava l'isolamento cross-origin per proteggere dati sensibili dagli attacchi di classe Spectre, rimuovere questi header re-espone quel rischio.

Opzione B: Preservare COEP e COOP.

  • Pro: L'intento di sicurezza del sito di destinazione viene rispettato.
  • Contro: Qualsiasi sotto-risorsa che non imposta esplicitamente CORP: cross-origin non riuscirà a caricarsi, rompendo la maggior parte delle applicazioni web complesse.

La strategia attuale di ProxyOrb è l'Opzione A: il gateway rimuove Cross-Origin-Embedder-Policy e Cross-Origin-Opener-Policy dalle risposte. Questo massimizza la compatibilità con i siti. Il compromesso di sicurezza è una scelta consapevole: gli utenti di un proxy web accettano che i contenuti vengano eseguiti in un ambiente diverso dal contesto di distribuzione previsto.

Ogni nuovo meccanismo di sicurezza del browser segue uno schema: viene introdotto come opt-in (i siti possono inviare l'header se vogliono la protezione), poi reso gradualmente obbligatorio per le nuove API, e alla fine considerato per l'applicazione obbligatoria. COEP ha seguito questo percorso: opzionale in Chrome 83, obbligatorio per SharedArrayBuffer in Chrome 91. I siti che incorporano contenuti di terze parti senza coordinazione hanno trovato i propri contenuti compromessi. I proxy web amplificano questo problema perché mediano per definizione contenuti di terze parti.

La comunità di sicurezza dei browser è consapevole di questo problema. La proposta emergente Document-Isolation-Policy mira a disaccoppiare l'isolamento dei processi dai requisiti di isolamento cross-origin, rendendo potenzialmente possibile ottenere le mitigazioni Spectre senza richiedere che tutte le sotto-risorse aderiscano. Quando questa verrà rilasciata, la compatibilità dei proxy con gli header di isolamento potrebbe migliorare.

6. Il Service Worker come Livello di Fiducia Lato Browser

Il Service Worker non è semplicemente un'ottimizzazione — è architetturalmente essenziale al modello di sicurezza di ProxyOrb. Ecco perché.

Lo Scope di Registrazione è Legato all'Origine

Un Service Worker viene registrato con uno scope che si trova sempre all'interno dell'origine della pagina che lo registra. Quando ProxyOrb registra il proprio Service Worker, lo scope è https://proxyorb.com/, il che significa che intercetta ogni fetch da qualsiasi pagina sotto quella origine.

Questo è il motivo fondamentale per cui la riscrittura degli URL verso same-origin funziona: una volta che il SW controlla un client, ogni richiesta di rete da quel client — indipendentemente dall'URL che il JavaScript nella pagina tenta di scaricare — passa prima attraverso il Service Worker.

// Service Worker entry point
self.addEventListener('fetch', (event) => {
  event.respondWith(handleProxyRequest(event))
})

La Pipeline di Intercettazione

Quando il Service Worker intercetta una richiesta, esegue diversi stadi decisionali:

-- Service Worker pseudocode: request interception pipeline

function handleProxyRequest(fetchEvent):
    request = fetchEvent.request

    -- Stage 1: Synthetic CORS preflight (never hits the network)
    if request.method == "OPTIONS":
        return syntheticCORSResponse(request)

    -- Stage 2: Pass through requests that shouldn't be proxied
    if shouldBypass(request.url):
        return originalFetch(request)

    -- Stage 3: Ensure __pot is present; recover from context if missing
    enrichedRequest = attachOriginToken(request, fetchEvent)

    -- Stage 4: Forward to gateway
    response = originalFetch(enrichedRequest)

    -- Stage 5: Strip and replace security headers in the response
    return sanitizeAndReturn(response)

Inoltro Trasparente degli Header

Una sfida sottile: il browser limita la possibilità per JavaScript di impostare certi header di richiesta "vietati" (Host, Origin, Referer, ecc.) tramite la Fetch API. Il Service Worker aggira questo problema codificando gli header ristretti in un unico header passthrough personalizzato; il gateway lo decodifica poi e li applica prima di inoltrare al server di destinazione:

-- Pseudocode: encode browser-restricted headers for the gateway

function addPassthroughHeaders(request, outboundHeaders):
    restricted = {}
    for name, value in request.headers:
        if name not in COMMON_ALLOWED_HEADERS:
            restricted[name] = value

    if restricted is not empty:
        outboundHeaders["X-Proxy-Passthrough"] = json_encode(restricted)

-- Gateway side: decode and apply before forwarding upstream
function applyPassthroughHeaders(incomingHeaders):
    encoded = incomingHeaders["X-Proxy-Passthrough"]
    if encoded:
        for name, value in json_decode(encoded):
            request.headers[name] = value
        request.headers.delete("X-Proxy-Passthrough")

Implicazioni di Sicurezza del SW come Intermediario Fidato

Dal punto di vista della sicurezza, il Service Worker occupa una posizione privilegiata: può ispezionare, modificare e falsificare qualsiasi richiesta effettuata da qualsiasi pagina nel suo scope. Per un proxy legittimo, questo è esattamente il punto. Per un proxy malevolo, questo sarebbe una superficie di attacco estremamente potente.

Ecco perché l'affidabilità dello script del Service Worker stesso è fondamentale. ProxyOrb serve lo script dell'interceptor dalla propria origine tramite HTTPS con controlli di cache rigorosi. Se un attaccante riuscisse a iniettare un Service Worker modificato, potrebbe intercettare tutto il traffico degli utenti colpiti — non solo il traffico proxy, ma qualsiasi richiesta dalle pagine sotto quella origine.

7. Gli iframe: Il Problema dei Frame-Ancestors

Gli iframe rappresentano una sfida distinta rispetto alle sotto-risorse ordinarie perché coinvolgono un contesto di navigazione annidato con la propria navigazione, il proprio confine SOP e il proprio insieme di restrizioni di incorporamento.

X-Frame-Options e frame-ancestors

Due meccanismi impediscono alle pagine di essere incorporate in iframe:

Legacy: X-Frame-Options: DENY o X-Frame-Options: SAMEORIGIN

Moderno: Content-Security-Policy: frame-ancestors 'none' o frame-ancestors 'self'

Quando il gateway proxa una pagina di destinazione che invia uno di questi, la pagina non può essere incorporata in un iframe sotto l'origine del proxy. Poiché X-Frame-Options: SAMEORIGIN fa riferimento all'origine di destinazione (example.com), e il proxy serve la pagina da proxyorb.com, il controllo same-origin del browser fallisce.

Il proxy deve rimuovere questi header dalle risposte in proxy e sostituire il CSP con una versione permissiva:

-- Gateway pseudocode: override embedding-restrictive headers

response.headers.delete("X-Frame-Options")
response.headers.delete("Content-Security-Policy")
response.headers.delete("Content-Security-Policy-Report-Only")

-- Set a permissive replacement that allows the proxy to embed content
response.headers["Content-Security-Policy"] =
    "upgrade-insecure-requests; frame-ancestors 'self'; " +
    "default-src * data: blob: about: ws: wss: 'unsafe-inline' 'unsafe-eval'"

Intercettazione degli iframe e Iniezione degli Script

Gli iframe incorporati presentano un secondo problema: il loro contenuto viene caricato dal proxy, ma il contesto di navigazione dell'iframe non ha automaticamente il Service Worker o l'interceptor del thread principale attivi. Se la pagina in proxy crea un <iframe src="https://widget.example.com/...">, anche quell'URL dell'iframe deve essere riscritto nel formato proxy, e gli script dell'interceptor del proxy devono essere iniettati nel documento dell'iframe.

L'interceptor per iframe opera su due livelli:

Livello 1 — Patching del prototipo (cattura la creazione programmatica degli iframe):

-- Pseudocode: intercept iframe src assignment

override HTMLIFrameElement.prototype.src setter:
    if value is not already a proxy URL:
        value = toProxyURL(value)   -- rewrite to proxy format
    call original setter(value)
    scheduleProxyInjection(this)    -- inject interceptor into iframe document

Livello 2 — Fallback MutationObserver (cattura gli iframe inseriti nel DOM):

-- Pseudocode: observe DOM for dynamically added iframes

observer = new MutationObserver(mutations):
    for mutation in mutations:
        for node in mutation.addedNodes:
            if node is an <iframe>:
                rewriteSrcIfNeeded(node)
                injectProxyScript(node)

observer.observe(document, { childList: true, subtree: true })

Il Problema dell'Attributo sandbox

L'attributo HTML sandbox limita ciò che un iframe può fare: sandbox="allow-scripts allow-same-origin" controlla l'esecuzione degli script, l'invio di form, l'accesso cross-origin, ecc. Affinché l'iniezione del proxy funzioni, l'iframe deve poter eseguire script e avere accesso al contesto proxy del genitore.

Il token allow-same-origin è particolarmente sfumato: quando presente insieme ad allow-scripts, vanifica l'isolamento di origine della sandbox — l'iframe viene eseguito con l'origine della pagina che lo incorpora. Quando è assente, l'iframe ottiene un'origine opaca univoca, il che interromperebbe completamente l'iniezione degli script proxy.

L'approccio attuale di ProxyOrb per gli attributi sandbox è rimuovere completamente l'attributo sandbox prima di iniettare lo script proxy:

-- Pseudocode: handle sandbox attribute before proxy injection

function handleSandboxedIframe(iframe):
    if iframe.hasAttribute("sandbox"):
        -- Remove so the proxy can inject scripts and access contentWindow
        iframe.removeAttribute("sandbox")
    injectProxyScript(iframe)

Si tratta di un compromesso di sicurezza significativo: il sandboxing era stato intenzionalmente inserito dal sito originale per limitare le capacità del contenuto incorporato. Rimuoverlo espande ciò che quel contenuto può fare. È il tipo di decisione invisibile agli utenti finali, ma che incide materialmente sulla postura di sicurezza della sessione proxy.

8. Implicazioni di Sicurezza per gli Operatori Proxy

Il Panorama della Superficie di Attacco

Quando gli utenti navigano attraverso ProxyOrb, diverse categorie di dati sensibili scorrono attraverso l'origine del proxy:

Cookie di Sessione: Poiché tutti i siti di destinazione vengono proxati attraverso proxyorb.com, i cookie vengono memorizzati sotto quella origine. Le sessioni autenticate di un utente con la propria banca, email e social media sono tutte cookie sotto un unico dominio. L'impostazione credentials: 'include' del Service Worker significa che questi cookie accompagnano ogni richiesta in proxy.

Header Referer: L'header Referer inviato ai server upstream rivela quale pagina stava visitando l'utente. Il proxy rimuove attentamente il proprio dominio dai valori referer prima di inoltrarli al server di destinazione. Se una richiesta origina da https://proxyorb.com/some/path?__pot=..., l'header Referer in uscita viene ricostruito come l'URL di destinazione originale (https://example.com/some/path) — il dominio del proxy non viene mai rivelato ai server upstream.

-- Pseudocode: normalize referer before forwarding upstream

function sanitizeReferer(referer):
    if referer is a proxy URL:
        return reconstruct_original_url(referer)   -- e.g. "https://example.com/path"
    if referer's origin equals proxy_origin:
        return ""   -- suppress: don't leak proxy domain to upstream
    return referer

Contesto di Esecuzione JavaScript: Ogni file JavaScript servito attraverso il proxy viene modificato (URL riscritti) ed eseguito nell'origine del proxy. Uno script malevolo da evil.example.com proxato attraverso ProxyOrb viene eseguito nell'origine proxyorb.com e ha pieno accesso al local storage, ai cookie e all'IndexedDB di quell'origine — il che include i dati di ogni altro sito di destinazione a cui l'utente ha acceduto tramite il proxy.

Il Modello di Minaccia del Proxy Malevolo

Per scopi educativi, vale la pena essere espliciti su cosa potrebbe fare un proxy malevolo che ProxyOrb deliberatamente non fa:

  1. Raccolta di Credenziali: Un proxy malevolo potrebbe registrare ogni corpo di richiesta (contenente password e dati dei form) mentre transita attraverso il gateway.

  2. Dirottamento di Sessione: Poiché tutti i cookie dei siti di destinazione sono memorizzati sotto il dominio del proxy, un operatore proxy malevolo potrebbe accedere a quei cookie lato server tramite il gateway.

  3. Iniezione di Contenuto: Il proxy modifica necessariamente il contenuto delle pagine (per iniettare il Service Worker e riscrivere gli URL). Un proxy malevolo potrebbe iniettare JavaScript arbitrario — keylogger, crypto miner, script di frode pubblicitaria — invisibili all'utente.

  4. SSL Stripping: Se il proxy degrada le connessioni HTTPS in HTTP per il tratto gateway-utente, tutto il traffico è in chiaro.

ProxyOrb opera tramite HTTPS end-to-end e non registra i corpi delle richieste. L'operatore di qualsiasi proxy web dispone di queste capacità, motivo per cui scegliere un operatore proxy affidabile è importante quanto scegliere un provider VPN affidabile.

Contenuto Misto

I browser moderni applicano il blocco dei contenuti misti: una pagina HTTPS non può caricare sotto-risorse HTTP. ProxyOrb gestisce questo imponendo HTTPS su tutte le connessioni in uscita dal gateway, anche quando l'URL di destinazione usa HTTP. L'override del CSP include upgrade-insecure-requests per istruire il browser ad aggiornare qualsiasi URL di sotto-risorsa HTTP in HTTPS prima del caricamento.

Questo è generalmente auspicabile, ma può rompere siti che servono deliberatamente risorse tramite HTTP (CDN legacy, risorse localhost, ecc.).

9. La Corsa agli Armamenti Continua: Conclusione

Quando abbiamo iniziato a costruire ProxyOrb, le principali sfide di compatibilità erano CORS e X-Frame-Options. Da allora, Chromium ha rilasciato CORB, CORP, COEP, COOP e sta sviluppando Document-Isolation-Policy. La direzione è chiara: i browser stanno diventando sempre più aggressivi nell'applicare i confini cross-origin, e ogni nuovo meccanismo richiede che l'infrastruttura proxy si adatti.

La sfida più significativa in arrivo è probabilmente il pieno dispiegamento di COEP nelle principali applicazioni web. I siti che usano SharedArrayBuffer per le prestazioni (editor video, IDE, strumenti di collaborazione) stanno impostando sempre più COEP: require-corp. Poiché ProxyOrb rimuove questo header per mantenere la compatibilità, gli utenti che necessitano delle funzionalità ad alte prestazioni abilitate da COEP le troveranno degradate in un contesto proxy.

Per i ricercatori di sicurezza, l'architettura proxy rivela qualcosa di importante: la politica stessa origine non è un firewall. È un modello di fiducia basato sulla struttura degli URL. I proxy web sfruttano il fatto che la SOP non fa alcuna distinzione intrinseca tra "queste due risorse sono legittimamente same-origin" e "queste due risorse sono state riscritte tramite URL per sembrare same-origin". L'intero stack di sicurezza del browser sopra la SOP — CORS, CORB, CORP, COEP, COOP — può essere visto come un tentativo di aggiungere difese più robuste rispetto all'identità di origine basata sugli URL.

Comprendere questo è essenziale per chiunque stia effettuando l'audit di servizi proxy, progettando policy di sicurezza del browser, o valutando la postura di sicurezza reale di applicazioni che potrebbero essere accessibili tramite proxy.

Domande Frequenti

Un proxy web aggira la politica stessa origine?

Non esattamente. Un proxy web funziona tramite la riscrittura degli URL: trasforma tutti gli URL cross-origin in URL same-origin, rendendo irrilevanti le restrizioni cross-origin della SOP anziché aggirarle. Dal punto di vista del browser, tutto il contenuto sembra provenire dall'origine propria del proxy, quindi nessun confine cross-origin viene attraversato. Questo è architetturalmente diverso da un bypass — la SOP applica ancora le proprie regole; il proxy ingegnerizza semplicemente il contenuto in modo che quelle regole non vengano mai attivate.

Come funziona un proxy web rispetto a CORS?

CORS influenza i server proxy su due livelli. Primo, il proxy deve intercettare le richieste di preflight OPTIONS e rispondere con header CORS permissivi, poiché la risposta al preflight del server di destinazione reale (che fa riferimento all'origine di destinazione) non soddisferebbe il controllo CORS del browser per l'origine del proxy. Secondo, il proxy deve rimuovere gli header CORS dalle risposte del server di destinazione e sostituirli con header che fanno riferimento all'origine del proxy. L'impostazione Access-Control-Allow-Credentials: true, combinata con credentials: 'include' nel Service Worker, significa che tutti i cookie dell'origine del proxy accompagnano ogni richiesta in proxy.

Cos'è CORB e come impatta i servizi proxy?

Cross-Origin Read Blocking (CORB) è una difesa di Chromium che impedisce a certe risposte cross-origin sensibili (HTML, JSON, XML) di entrare nel processo di rendering quando caricate come sotto-risorse cross-origin. Per i proxy web correttamente configurati, CORB generalmente non viene attivato perché la riscrittura degli URL rende tutte le richieste same-origin. Tuttavia, CORB può causare problemi durante il periodo precedente alla registrazione completa del Service Worker, quando alcune richieste possono sfuggire alla riscrittura degli URL ed essere inviate come genuine richieste cross-origin. CORB è stato introdotto come mitigazione Spectre ed è definito nella specifica WHATWG Fetch.

No. I cookie HttpOnly sono impostati dal server di destinazione e non possono essere letti dal JavaScript — incluso il JavaScript in esecuzione in un Service Worker. Tuttavia, il gateway riceve questi cookie quando inoltra le richieste per conto dell'utente, poiché il browser li invia negli header di richiesta. Il flag HttpOnly impedisce il furto JavaScript lato client ma non impedisce al server proxy stesso di vedere i valori dei cookie in transito. Questo è analogo a come HttpOnly protegge contro XSS ma non contro l'intercettazione lato server.

Usare un proxy web è sicuro dal punto di vista della sicurezza del browser?

Dipende dal modello di minaccia. Dal punto di vista del browser, tutto il contenuto servito attraverso un proxy web viene eseguito nell'origine del proxy, il che significa che una vulnerabilità nel JavaScript di un sito proxato potrebbe potenzialmente accedere ai dati della sessione di un altro sito proxato (poiché condividono il cookie jar e lo storage della stessa origine). Anche l'operatore del proxy è una parte fidata con accesso a tutto il traffico in transito. Per accedere a contenuti non sensibili in ambienti con restrizioni, il rischio è tipicamente accettabile. Per sessioni autenticate con servizi sensibili (banca, salute, governo), gli utenti devono comprendere che l'operatore proxy ha la capacità tecnica di osservare quel traffico, e dovrebbero usare solo servizi proxy con policy di no-log verificabili e solide pratiche di sicurezza operativa.

Questo articolo riflette l'architettura di ProxyOrb all'inizio del 2026. I meccanismi di sicurezza del browser evolvono rapidamente; i lettori sono incoraggiati a consultare lo Standard WHATWG Fetch, la specifica W3C Content Security Policy e i documenti di progettazione della sicurezza di Chromium per le informazioni più aggiornate.