Pular para o conteúdo principal

Política de Mesma Origem e Proxies Web: Uma Análise Técnica de Segurança

Escrito por
Smith
Smith
Tempo de leitura
17 min de leitura
Publicado em
2 de mar. de 2026
Política de Mesma Origem e Proxies Web: Uma Análise Técnica de Segurança

Ao construirmos o ProxyOrb, nos deparamos com um paradoxo fundamental em cada decisão de design: um proxy web funciona fazendo o navegador acreditar que conteúdo de terceiros é conteúdo de mesma origem. Ou seja, por definição, enganar o modelo de segurança central do navegador. No entanto, os navegadores modernos passaram quinze anos empilhando defesas cada vez mais sofisticadas precisamente contra esse tipo de confusão de origem.

Este artigo examina essa tensão a partir dos princípios básicos. Se você é um pesquisador de segurança, pentester ou engenheiro de segurança de navegadores que quer entender como os proxies web realmente interagem com a política de mesma origem — não em nível conceitual, mas no nível de cabeçalhos HTTP, código-fonte do Chromium e trade-offs de engenharia em produção — este artigo é para você.

Vamos cobrir a base do SOP, reescrita de URLs, CORS, CORB/CORP, COEP/COOP, Service Workers, iframes e as implicações de segurança para operadores de proxy e seus usuários.

1. A Base da Política de Mesma Origem

A política de mesma origem (SOP) é definida por uma tripla: esquema + host + porta. Duas URLs são de mesma origem apenas se todos os três componentes coincidirem exatamente. https://example.com:443 e http://example.com:80 são cross-origin apesar de apontarem para o mesmo servidor.

O que frequentemente é mal compreendido é o que o SOP efetivamente impede versus o que ele permite. O SOP não bloqueia:

  • Carregar imagens (<img src>) entre origens
  • Carregar scripts (<script src>) entre origens
  • Carregar folhas de estilo (<link rel="stylesheet">) entre origens
  • Embutir iframes entre origens (embora o conteúdo do documento embutido seja isolado)
  • Enviar submissões de formulário (<form action>) entre origens

O que o SOP de fato impede é a leitura da resposta de requisições cross-origin feitas via fetch() ou XMLHttpRequest. A requisição sai — o round-trip de rede acontece — mas o corpo e os cabeçalhos da resposta são retidos do JavaScript rodando em uma origem diferente.

Essa distinção é extremamente importante para proxies web. O trabalho central de um proxy é colapsar duas origens (o servidor proxy e o servidor alvo) em uma só, eliminando a fronteira cross-origin. Assim que todos os recursos parecem vir de https://proxyorb.com, as restrições do SOP sobre leitura de respostas simplesmente não se aplicam.

O "espaço legítimo" que os proxies web exploram é a reescrita de URLs: em vez de https://example.com/api/data, toda requisição vira https://proxyorb.com/api/data?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==. Do ponto de vista do navegador, essa é uma requisição de mesma origem. O SOP não foi contornado — ele foi tornado irrelevante ao mudar a origem aparente de todo o conteúdo.

2. A Arquitetura de Reescrita de URLs do ProxyOrb

Para entender as implicações de segurança, você precisa compreender o mecanismo de codificação. O ProxyOrb usa um parâmetro de URL chamado __pot (proxy origin token) que contém a origem alvo codificada em Base64.

O Parâmetro __pot

O parâmetro __pot sempre codifica a origem (esquema + host, sem o caminho) do alvo, não a URL completa. Isso significa que https://example.com/some/deep/path?foo=bar e https://example.com/other/page geram o mesmo valor de __pot: aHR0cHM6Ly9leGFtcGxlLmNvbQ== (a codificação Base64 de https://example.com). O caminho e a query string reais são preservados literalmente no próprio caminho e query string da URL proxy.

Quando um usuário navega para https://proxyorb.com/?__pot=aHR0cHM6Ly9leGFtcGxlLmNvbQ==, o gateway decodifica e reconstrói a URL original:

-- 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

O gateway então encaminha a requisição para o servidor alvo real, reescrevendo o cabeçalho Origin para que o servidor upstream veja seu próprio domínio em vez do domínio do 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

Reescrita de URLs no Lado do Cliente via Service Worker

O gateway cuida do lado do servidor. O lado do cliente — reescrever URLs nas respostas de HTML, JavaScript e CSS para que todas as sub-requisições continuem passando pelo proxy — é feito por um Service Worker.

A transformação central converte qualquer URL encontrada no conteúdo da página para o 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

Por exemplo, https://cdn.example.com/bundle.js referenciado dentro de uma página sendo proxiada vira https://proxyorb.com/bundle.js?__pot=aHR0cHM6Ly9jZG4uZXhhbXBsZS5jb20=.

Essa reescrita é abrangente: cobre fetch(), XMLHttpRequest, <script src>, <img src>, conexões WebSocket e tags <link>. Quando toda URL na página aponta para a origem do proxy, o navegador nunca faz uma requisição cross-origin — toda requisição é de mesma origem por construção.

Recuperando o __pot Sem Navegação Completa

Um caso de borda sutil surge com requisições originadas dentro de uma página proxiada mas que não possuem o parâmetro __pot — por exemplo, um fetch('/api/data') relativo disparado antes que o Service Worker tenha reescrito a URL, ou uma requisição emitida por um script injetado dinamicamente que passou pelo reescritor de URLs.

O Service Worker resolve o token ausente por meio de uma busca em 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

O gateway tem um caminho de recuperação paralelo: se uma requisição chega sem __pot mas carrega um cabeçalho Referer apontando para uma URL de mesma origem que contém __pot, o gateway extrai o token do referer e o anexa à requisição atual. Isso lida com cenários de navegação onde o token foi removido pelo próprio JavaScript da página antes que o gateway recebesse a requisição.

3. CORS: O Sistema Explícito de Permissão Cross-Origin

O CORS (Cross-Origin Resource Sharing) foi projetado para permitir que servidores optem pelo acesso cross-origin enviando cabeçalhos de resposta específicos. Do ponto de vista do proxy, o CORS cria dois problemas distintos.

Problema 1: Interceptação de Preflight CORS

Quando o JavaScript rodando em uma página faz uma requisição fetch() com cabeçalhos não simples (como Authorization ou Content-Type: application/json), o navegador envia primeiro uma requisição OPTIONS de preflight. Se a resposta de preflight do servidor alvo não incluir cabeçalhos CORS permissivos, a requisição real é bloqueada.

Na arquitetura do ProxyOrb, o Service Worker intercepta todas as requisições OPTIONS e as responde sinteticamente — antes mesmo de chegarem ao gateway — retornando uma resposta que desbloqueia a requisição real:

-- 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",
    })

No nível do gateway, cada resposta proxiada recebe cabeçalhos CORS equivalentes:

-- 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: Requisições com Credenciais

A combinação de Access-Control-Allow-Credentials: true com um Access-Control-Allow-Origin que não é coringa é significativa. O CORS exige um valor de origem explícito (não *) sempre que credenciais são incluídas. O Service Worker emite todas as requisições de saída com credentials: 'include', então o gateway precisa ecoar de volta a origem exata da requisição em vez de um coringa.

Isso significa que todos os cookies armazenados em proxyorb.com — acumulados de cada site alvo que o usuário visitou através do proxy — são enviados em todas as requisições proxiadas. Isso é intencional (mantém o estado de sessão para sites onde o usuário está autenticado), mas também é uma consideração importante de segurança que discutimos na Seção 8.

O Padrão de Strip-and-Replace dos Cabeçalhos CORS

Uma resposta proxiada pode carregar cabeçalhos CORS do servidor alvo que estão errados do ponto de vista do navegador (eles referenciam a origem alvo, não a origem do proxy). O Service Worker remove e os substitui:

-- 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: As Defesas Mais Rígidas do Chromium

O CORS opera com opt-in explícito dos servidores. O Chromium adicionou dois mecanismos que são ativos por padrão, independentemente da configuração CORS.

Cross-Origin Read Blocking (CORB)

O CORB foi introduzido no Chrome 67 (2018) como parte das mitigações Spectre. A percepção central: mesmo que o corpo de uma resposta cross-origin nunca seja lido pelo JavaScript, o fato de que ela foi buscada e decodificada pelo processo de renderização significa que ela existe no espaço de endereços desse processo. Ataques da classe Spectre podem então extraí-la por canais laterais.

O CORB impede que certas respostas cross-origin jamais entrem no processo de renderização. Especificamente, quando uma tag <script> ou <img> busca uma resposta cross-origin e essa resposta tem um Content-Type de text/html, text/xml ou application/json, o Chromium inspeciona o corpo (usando um sniffer de tipo MIME definido na especificação CORB) e, se o tipo corresponder, substitui a resposta por uma vazia antes que o renderizador a veja.

Para um proxy web, o CORB seria catastrófico se as requisições fossem genuinamente cross-origin. Um endpoint de API retornando application/json buscado de uma tag <script> retornaria silenciosamente vazio. Porém, como o ProxyOrb reescreve todas as URLs para serem de mesma origem, a condição cross-origin do CORB nunca é disparada — o navegador nunca vê uma resposta JSON cross-origin, pois do seu ponto de vista, todas as respostas vêm de proxyorb.com.

O único caso em que o CORB importa é durante o período de transição antes que o Service Worker esteja totalmente registrado e interceptando requisições. Se alguma requisição escapar da reescrita de URL durante essa janela, o CORB pode bloqueá-la. Essa condição de corrida é o motivo pelo qual o ProxyOrb também mantém uma camada de interceptação na thread principal que corrige XMLHttpRequest, fetch e setters de atributos do DOM de forma síncrona antes que qualquer JavaScript da página seja executado — servindo como fallback durante a inicialização do Service Worker.

Vale ressaltar que o CORB foi parcialmente substituído pelo Opaque Response Blocking (ORB), que o Chromium está em processo de adotar. O ORB refina as regras do CORB para reduzir falsos positivos mantendo as proteções contra Spectre. As implicações de compatibilidade com proxy são similares.

Cross-Origin Resource Policy (CORP)

O CORP, definido na especificação Fetch, permite que servidores declarem que seus recursos só devem ser carregados por contextos de mesma origem ou mesmo site:

Cross-Origin-Resource-Policy: same-origin

Quando o Chromium encontra esse cabeçalho em uma requisição de sub-recurso cross-origin, bloqueia a resposta completamente. Isso é mais agressivo que o CORB — aplica-se independentemente do tipo de conteúdo e não pode ser contornado por sniffing de MIME.

Mais uma vez, como a reescrita de URLs do ProxyOrb garante que todas as requisições sejam de mesma origem do ponto de vista do navegador, os cabeçalhos CORP dos servidores alvo não disparam bloqueios. O gateway também remove esses cabeçalhos das respostas de forma defensiva, tratando quaisquer casos de borda em que uma requisição passe sem reescrita de URL.

A questão mais profunda com o CORP é, na verdade, um caso em que a arquitetura de proxy ajuda a compatibilidade: se https://api.example.com e https://www.example.com estão ambos sendo proxiados, ambos mapeiam para a mesma origem proxy, então uma requisição de um para o outro é genuinamente de mesma origem — as restrições CORP deixam de se aplicar entre eles.

5. COEP e COOP: Isolamento Cross-Origin

A partir do Chrome 92 (2021), o acesso ao SharedArrayBuffer — e por extensão, os timers de alta resolução usados por certas APIs de performance — foi restrito a páginas que optaram pelo isolamento cross-origin. Esse opt-in exige dois cabeçalhos de resposta funcionando em conjunto.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp

Quando uma página envia esse cabeçalho, o navegador exige que todo sub-recurso carregado por ela:

  1. Seja de mesma origem, OU
  2. Envie Cross-Origin-Resource-Policy: cross-origin explicitamente, OU
  3. Tenha uma resposta CORS permissiva para o fetch com credenciais

O problema para proxies web: se um site alvo envia COEP: require-corp no seu documento principal, e esse documento é servido pelo proxy com o cabeçalho preservado, o navegador agora exige que todo sub-recurso carregado por essa página também opte por isso. Qualquer recurso que não faça isso — e a maioria não vai — causa um erro de rede.

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy: same-origin

O COOP controla se uma página pode compartilhar um grupo de contexto de navegação com páginas cross-origin. Quando definido como same-origin, uma navegação cross-origin abre um novo grupo de contexto de navegação, quebrando referências de window.opener e canais de postMessage entre a página e quaisquer openers cross-origin.

Para um proxy, o COOP é menos imediatamente destrutivo que o COEP, mas ainda quebra sites que dependem de fluxos cross-origin de postMessage (fluxos de popup OAuth sendo o exemplo mais comum).

O Dilema do Operador de Proxy

Esse é o trade-off mais difícil que enfrentamos no ProxyOrb:

Opção A: Remover COEP e COOP das respostas.

  • Pró: O carregamento de sub-recursos funciona normalmente; a página proxiada não aplica essas restrições.
  • Contra: Estamos removendo cabeçalhos de segurança que o site alvo definiu intencionalmente. Se o site usava isolamento cross-origin para proteger dados sensíveis de ataques da classe Spectre, remover esses cabeçalhos re-expõe esse risco.

Opção B: Preservar COEP e COOP.

  • Pró: A intenção de segurança do site alvo é respeitada.
  • Contra: Qualquer sub-recurso que não definir explicitamente CORP: cross-origin falhará ao carregar, quebrando a maioria das aplicações web complexas.

A estratégia atual do ProxyOrb é a Opção A: o gateway remove Cross-Origin-Embedder-Policy e Cross-Origin-Opener-Policy das respostas. Isso maximiza a compatibilidade com sites. O trade-off de segurança é feito conscientemente: usuários de um proxy web aceitam que estão executando conteúdo em um ambiente diferente do seu contexto de implantação pretendido.

Cada novo mecanismo de segurança do navegador segue um padrão: é introduzido como opt-in (sites podem enviar o cabeçalho se quiserem proteção), depois se torna obrigatório para novas APIs, e eventualmente é considerado para aplicação mandatória. O COEP seguiu esse caminho: opcional no Chrome 83, obrigatório para SharedArrayBuffer no Chrome 91. Sites que incorporavam conteúdo de terceiros sem coordenação viram seus conteúdos quebrarem. Proxies web ampliam esse problema porque medeiam conteúdo de terceiros por definição.

A comunidade de segurança de navegadores está ciente desse problema. A proposta emergente Document-Isolation-Policy visa desacoplar o isolamento de processo dos requisitos de isolamento cross-origin, potencialmente tornando possível obter mitigações Spectre sem exigir que todos os sub-recursos optem por isso. Quando isso for lançado, a compatibilidade de proxies com cabeçalhos de isolamento pode melhorar.

6. Service Worker como Camada de Confiança no Navegador

O Service Worker não é meramente uma otimização — ele é arquiteturalmente essencial para o modelo de segurança do ProxyOrb. Veja o porquê.

O Escopo de Registro Vincula-se à Origem

Um Service Worker é registrado com um scope que está sempre dentro da origem da página que o registra. Quando o ProxyOrb registra seu Service Worker, o escopo é https://proxyorb.com/, o que significa que ele intercepta todo fetch de qualquer página sob essa origem.

Essa é a razão fundamental pela qual a reescrita de URLs para mesma origem funciona: uma vez que o SW está controlando um cliente, toda requisição de rede desse cliente — independentemente de qual URL o JavaScript na página tenta buscar — passa pelo Service Worker primeiro.

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

O Pipeline de Interceptação

Quando o Service Worker intercepta uma requisição, ela passa por vários estágios de decisão:

-- 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)

Encaminhamento Transparente de Cabeçalhos

Um desafio sutil: o navegador restringe o JavaScript de definir certos cabeçalhos de requisição "proibidos" (Host, Origin, Referer, etc.) via a Fetch API. O Service Worker contorna isso codificando os cabeçalhos restritos em um único cabeçalho personalizado de passagem; o gateway então decodifica e os aplica antes de encaminhar ao servidor alvo:

-- 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")

Implicações de Segurança do SW como Intermediário Confiável

Do ponto de vista da segurança do navegador, o Service Worker ocupa uma posição privilegiada: ele pode inspecionar, modificar e forjar qualquer requisição feita por qualquer página em seu escopo. Para uso legítimo de proxy, esse é o objetivo inteiro. Para um proxy malicioso, isso seria uma superfície de ataque extremamente poderosa.

É por isso que a confiabilidade do próprio script do Service Worker é primordial. O ProxyOrb serve o script do interceptor a partir de sua própria origem via HTTPS com controles rígidos de cache. Se um atacante conseguisse injetar um Service Worker modificado, ele poderia interceptar todo o tráfego dos usuários afetados — não apenas o tráfego proxy, mas qualquer requisição de páginas sob aquela origem.

7. iframes: O Problema do Frame-Ancestors

Os iframes representam um desafio distinto dos sub-recursos comuns porque envolvem um contexto de navegação aninhado com sua própria navegação, sua própria fronteira SOP e seu próprio conjunto de restrições de incorporação.

X-Frame-Options e frame-ancestors

Dois mecanismos impedem que páginas sejam incorporadas em iframes:

Legado: X-Frame-Options: DENY ou X-Frame-Options: SAMEORIGIN

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

Quando o gateway proxia uma página alvo que envia qualquer um desses, a página não pode ser incorporada em um iframe sob a origem do proxy. Como X-Frame-Options: SAMEORIGIN referencia a origem alvo (example.com), e o proxy serve a página de proxyorb.com, a verificação de mesma origem do navegador falha.

O proxy precisa remover esses cabeçalhos das respostas proxiadas e substituir o CSP por uma versão 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'"

Interceptação de iframe e Injeção de Script

iframes incorporados apresentam um segundo problema: seu conteúdo é carregado pelo proxy, mas o contexto de navegação do iframe não tem automaticamente o Service Worker ou o interceptor da thread principal ativo. Se a página proxiada criar um <iframe src="https://widget.example.com/...">, essa URL do iframe também precisa ser reescrita para o formato proxy, e os scripts do interceptor do proxy precisam ser injetados no documento do iframe.

O interceptor de iframe opera em dois níveis:

Nível 1 — Patch de prototype (captura criação programática de 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

Nível 2 — Fallback com MutationObserver (captura iframes inseridos no 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 })

O Problema do Atributo sandbox

O atributo HTML sandbox restringe o que um iframe pode fazer: sandbox="allow-scripts allow-same-origin" controla execução de scripts, submissão de formulários, acesso cross-origin, etc. Para que a injeção do proxy funcione, o iframe precisa executar scripts e ter acesso ao contexto proxy do pai.

O token allow-same-origin é particularmente sutil: quando presente junto com allow-scripts, ele derrota o isolamento de origem do sandbox — o iframe roda com a origem da página que o incorpora. Quando ausente, o iframe recebe uma origem opaca única, o que quebraria a injeção de scripts do proxy por completo.

A abordagem atual do ProxyOrb para atributos sandbox é remover o atributo sandbox completamente antes de injetar o 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)

Esse é um trade-off de segurança significativo: o sandboxing foi colocado intencionalmente pelo site original para restringir as capacidades do conteúdo incorporado. Removê-lo expande o que esse conteúdo pode fazer. É o tipo de decisão que é invisível para os usuários finais, mas afeta materialmente a postura de segurança da sessão proxy.

8. Implicações de Segurança para Operadores de Proxy

O Panorama da Superfície de Ataque

Quando usuários navegam pelo ProxyOrb, várias categorias de dados sensíveis fluem pela origem do proxy:

Cookies de Sessão: Como todos os sites alvo são proxiados por proxyorb.com, os cookies são armazenados sob essa origem. As sessões autenticadas de um usuário com seu banco, e-mail e redes sociais são todas cookies sob um único domínio. O credentials: 'include' do Service Worker significa que esses cookies acompanham toda requisição proxiada.

Cabeçalhos Referer: O cabeçalho Referer enviado aos servidores upstream revela qual página o usuário estava visualizando. O proxy remove cuidadosamente seu próprio domínio dos valores do referer antes de encaminhar ao servidor alvo. Se uma requisição se origina de https://proxyorb.com/some/path?__pot=..., o cabeçalho Referer de saída é reconstruído como a URL alvo original (https://example.com/some/path) — o domínio do proxy nunca é vazado para servidores 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

Contexto de Execução JavaScript: Todo arquivo JavaScript servido pelo proxy é modificado (URLs reescritas) e executado na origem do proxy. Um script malicioso de evil.example.com proxiado pelo ProxyOrb roda na origem proxyorb.com e tem acesso total ao local storage, cookies e IndexedDB dessa origem — o que inclui dados de todos os outros sites alvo que o usuário acessou pelo proxy.

O Modelo de Ameaça do Proxy Malicioso

Para fins educativos, vale ser explícito sobre o que um proxy malicioso poderia fazer, que o ProxyOrb deliberadamente não faz:

  1. Coleta de Credenciais: Um proxy malicioso poderia registrar todo corpo de requisição (contendo senhas e dados de formulário) conforme passa pelo gateway.

  2. Sequestro de Sessão: Como todos os cookies de sites alvo são armazenados sob o domínio do proxy, um operador de proxy malicioso poderia acessar esses cookies no lado do servidor pelo gateway.

  3. Injeção de Conteúdo: O proxy necessariamente modifica o conteúdo da página (para injetar o Service Worker e reescrever URLs). Um proxy malicioso poderia injetar JavaScript arbitrário — keyloggers, mineradores de criptomoeda, scripts de fraude publicitária — invisível ao usuário.

  4. SSL Stripping: Se o proxy fizer downgrade de conexões HTTPS para HTTP no trecho gateway-para-usuário, todo o tráfego fica em texto simples.

O ProxyOrb opera com HTTPS de ponta a ponta e não registra corpos de requisição. O operador de qualquer proxy web tem essas capacidades, e é por isso que escolher um operador de proxy confiável importa tanto quanto escolher um provedor de VPN confiável.

Conteúdo Misto

Navegadores modernos aplicam bloqueio de conteúdo misto: uma página HTTPS não pode carregar sub-recursos HTTP. O ProxyOrb lida com isso aplicando HTTPS em todas as conexões de saída do gateway, mesmo quando a URL alvo usa HTTP. O override de CSP inclui upgrade-insecure-requests para instruir o navegador a atualizar qualquer URL de sub-recurso HTTP para HTTPS antes de carregar.

Isso geralmente é desejável, mas pode quebrar sites que intencionalmente servem recursos via HTTP (CDNs legados, recursos localhost, etc.).

9. A Corrida Armamentista Contínua: Conclusão

Quando começamos a construir o ProxyOrb, os principais desafios de compatibilidade eram CORS e X-Frame-Options. Desde então, o Chromium lançou CORB, CORP, COEP, COOP e está desenvolvendo o Document-Isolation-Policy. A direção é clara: os navegadores estão se tornando mais agressivos na aplicação das fronteiras cross-origin, e cada novo mecanismo exige que a infraestrutura de proxy se adapte.

O desafio mais significativo pela frente é provavelmente o deploy completo do COEP nos principais aplicativos web. Sites que usam SharedArrayBuffer para performance (editores de vídeo, IDEs, ferramentas colaborativas) estão cada vez mais definindo COEP: require-corp. Como o ProxyOrb remove esse cabeçalho para manter a compatibilidade, usuários que precisam das funcionalidades de alto desempenho que o COEP habilita vão encontrá-las degradadas em um contexto de proxy.

Para pesquisadores de segurança, a arquitetura de proxy revela algo importante: a política de mesma origem não é um firewall. É um modelo de confiança baseado na estrutura de URL. Proxies web exploram o fato de que o SOP não faz nenhuma distinção intrínseca entre "esses dois recursos são legitimamente de mesma origem" e "esses dois recursos foram reescritos para parecerem de mesma origem". Toda a pilha de segurança do navegador acima do SOP — CORS, CORB, CORP, COEP, COOP — pode ser vista como uma tentativa de adicionar defesas mais robustas do que a identidade de origem baseada em URL.

Entender isso é essencial para qualquer pessoa que audita serviços de proxy, projeta políticas de segurança do navegador ou avalia a postura real de segurança de aplicações que podem ser acessadas por meio de proxies.

Perguntas Frequentes

Um proxy web contorna a política de mesma origem?

Não exatamente. Um proxy web funciona por reescrita de URLs: ele transforma todas as URLs cross-origin em URLs de mesma origem, tornando as restrições cross-origin do SOP irrelevantes em vez de contorná-las. Do ponto de vista do navegador, todo conteúdo parece vir da própria origem do proxy, então nenhuma fronteira cross-origin é cruzada. Isso é arquiteturalmente diferente de um bypass — o SOP ainda aplica suas regras; o proxy apenas engenhara o conteúdo para que essas regras nunca sejam disparadas.

Como o CORS afeta servidores proxy web?

O CORS afeta servidores proxy em dois níveis. Primeiro, o proxy precisa interceptar requisições de preflight OPTIONS e responder com cabeçalhos CORS permissivos, já que a resposta de preflight do servidor alvo real (referenciando a origem alvo) não satisfaria a verificação CORS do navegador para a origem do proxy. Segundo, o proxy precisa remover os cabeçalhos CORS das respostas do servidor alvo e substituí-los por cabeçalhos referenciando a origem do proxy. A configuração Access-Control-Allow-Credentials: true, combinada com credentials: 'include' no Service Worker, significa que todos os cookies da origem do proxy acompanham toda requisição proxiada.

O que é CORB e como ele impacta serviços de proxy?

O Cross-Origin Read Blocking (CORB) é uma defesa do Chromium que impede que certas respostas cross-origin sensíveis (HTML, JSON, XML) entrem no processo de renderização quando carregadas como sub-recursos cross-origin. Para proxies web corretamente configurados, o CORB geralmente não é disparado porque a reescrita de URLs torna todas as requisições de mesma origem. Porém, o CORB pode causar problemas durante o período antes que o Service Worker esteja totalmente registrado, quando algumas requisições podem escapar da reescrita de URL e ser enviadas como requisições genuinamente cross-origin. O CORB foi introduzido como mitigação Spectre e está definido na especificação WHATWG Fetch.

Proxies web conseguem acessar cookies HTTP-only?

Não. Cookies HttpOnly são definidos pelo servidor alvo e não podem ser lidos por JavaScript — incluindo JavaScript rodando em um Service Worker. Porém, o gateway recebe esses cookies ao encaminhar requisições em nome do usuário, já que o navegador os envia nos cabeçalhos de requisição. O flag HttpOnly impede o roubo por JavaScript do lado do cliente, mas não impede que o próprio servidor proxy veja os valores dos cookies em trânsito. Isso é análogo a como HttpOnly protege contra XSS mas não contra interceptação no lado do servidor.

Usar um proxy web é seguro do ponto de vista da segurança do navegador?

Depende do modelo de ameaça. Do ponto de vista do navegador, todo conteúdo servido por um proxy web roda na origem do proxy, o que significa que uma vulnerabilidade no JavaScript de um site proxiado poderia potencialmente acessar dados da sessão de outro site proxiado (já que eles compartilham o mesmo jar de cookies e armazenamento da origem). O operador do proxy também é uma parte confiável com acesso a todo o tráfego em trânsito. Para acessar conteúdo não sensível em ambientes restritos, o risco é geralmente aceitável. Para sessões autenticadas com serviços sensíveis (banco, saúde, governo), os usuários devem entender que o operador do proxy tem a capacidade técnica de observar esse tráfego, e devem usar apenas serviços de proxy com políticas auditáveis de não registro de logs e práticas rigorosas de segurança operacional.

Este artigo reflete a arquitetura do ProxyOrb no início de 2026. Os mecanismos de segurança dos navegadores evoluem rapidamente; os leitores são encorajados a consultar o Padrão WHATWG Fetch, a especificação W3C Content Security Policy e os documentos de design de segurança do Chromium para as informações mais atuais.