O que é um iframe em sandbox?

Um iframe em sandbox é um documento incorporado no navegador ao qual o atributo sandbox do iframe aplica restrições adicionais. Com um valor vazio de sandbox, o navegador parte de uma configuração restritiva; tokens allow-* individuais devolvem apenas as permissões necessárias ao conteúdo incorporado. Para uma prévia de HTML, a abordagem útil mais segura não é “confiar no código”, mas “isolar a prévia, conceder o mínimo de permissões e manter dados secretos fora do experimento”.

O que muda quando um iframe é colocado em sandbox?

Um iframe comum cria um contexto de navegação aninhado. A política de mesma origem, a Política de Permissões, a Política de Segurança de Conteúdo e os cabeçalhos do próprio site incorporado continuam relevantes, mas o iframe não perde automaticamente todas as funcionalidades do navegador.

Adicionar sandbox instrui o navegador a impor um conjunto extra de restrições. O Padrão HTML do WHATWG define o atributo como um conjunto não ordenado de tokens separados por espaços. A ausência de um token mantém a restrição correspondente do sandbox; acrescentá-lo remove uma restrição específica.

É fácil interpretar essa lógica de forma invertida:

<iframe sandbox srcdoc="<p>Static preview</p>"></iframe>

Esta é a forma restritiva. Isso não significa “nenhuma opção de sandbox selecionada”. Isso significa que o sandbox está ativo e nenhum de seus recursos opcionais foi restaurado.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</button>">
</iframe>

Essa versão permite a execução de scripts e o funcionamento de formulários, mantendo as demais restrições. O resultado em termos de segurança ainda depende da origem do conteúdo e do que a aplicação que o incorpora expõe.

Quais restrições se aplicam por padrão?

O padrão completo contém mais detalhes do que cabem em uma lista de verificação, mas estas categorias explicam a maior parte do comportamento de uma prévia.

A referência da MDN sobre iframes lista os tokens atuais e explica o que cada um habilita. Consulte essa referência em vez de copiar uma lista antiga de tokens para um controle de segurança que será usado por muito tempo.

O que os tokens de permissão comuns restauram?

Trate cada token como uma decisão sobre permissões, não como uma opção de conveniência.

Alguns tokens interagem entre si. Revisá-los individualmente é necessário, mas não suficiente. A origem do documento incorporado, o uso de srcdoc ou de uma URL remota, a Política de Segurança de Conteúdo da página principal e qualquer canal de mensagens entre o iframe e a página que o incorpora afetam o isolamento.

O diagrama descreve um limite de permissão. Ele não afirma que qualquer conjunto de tokens torne o código arbitrário inofensivo.

Por que uma origem opaca é importante?

Sem allow-same-origin, o conteúdo em sandbox é tratado como proveniente de uma origem especial que não passa nas verificações normais de mesma origem. Desenvolvedores costumam chamá-la de origem opaca ou única.

Em uma prévia incorporada com srcdoc, essa separação é valiosa. A prévia pode renderizar um documento sem ser tratada como pertencente à mesma origem da página do editor. Ela não pode simplesmente acessar o DOM da página que a incorpora nem ler seu armazenamento de mesma origem como se fosse outro componente dessa página.

Uma origem opaca não significa “offline” nem “rede desativada”. Se scripts forem permitidos, o código da prévia ainda poderá fazer requisições de rede autorizadas pelas políticas do navegador e pelo destino. Ele pode usar CPU e memória, manipular seu próprio DOM e se comunicar pelos canais que a página principal expõe deliberadamente. O isolamento reduz os privilégios; não certifica o código.

A MDN alerta especialmente para a combinação de allow-scripts e allow-same-origin quando o conteúdo incorporado tem a mesma origem e consegue remover seu próprio atributo sandbox. A lição depende do contexto: não restabeleça ambas as permissões apenas porque um exemplo não funciona sem elas.

Como a prévia do ClockTools configura seu sandbox?

O editor HTML em tempo real do ClockTools disponível no site constrói a prévia com srcdoc. Quando o JavaScript está ativado, o valor do atributo sandbox do iframe é:

allow-scripts allow-forms allow-modals

A implementação omite deliberadamente allow-same-origin, allow-popups, permissões de navegação da página principal e permissão de download. A interface identifica a prévia como um sandbox de origem opaca, deixando visível a decisão sobre a origem, em vez de escondê-la no código-fonte.

Essa configuração permite exemplos didáticos comuns: scripts podem atualizar a prévia, formulários podem testar a validação do navegador e o comportamento de envio, e exemplos com modais podem ser executados. Ela não transforma código desconhecido em código confiável. Por isso, as próprias orientações do editor recomendam não incluir dados secretos e revisar scripts desconhecidos.

A página também captura mensagens do console e oferece um painel de verificação do documento. Esses recursos ajudam a observar o funcionamento, mas não são permissões do sandbox. Um painel de console ajuda a explicar uma falha; não impede uma requisição. Uma verificação estrutural pode apontar a ausência de um rótulo; não faz uma análise completa de segurança.

O que mostrou a verificação de permissões?

Inspecionei o elemento da prévia renderizada no ambiente do ClockTools disponível no site, em vez de me basear apenas no texto de divulgação.

O título do iframe era “Prévia de HTML em tempo real”, o que também informa às tecnologias assistivas a finalidade do documento incorporado.

Essa inspeção confirma o isolamento configurado naquele momento. Ela não prova que todo script possível seja seguro nem substitui uma revisão do canal de mensagens, do tratamento de recursos externos, da Política de Segurança de Conteúdo ou de futuras alterações no código.

Quais combinações de tokens merecem cuidado extra?

Faça uma análise baseada em ameaças, em vez de usar uma combinação universal de tokens.

allow-scripts junto com allow-same-origin

Essa combinação pode enfraquecer seriamente o isolamento quando o documento incorporado tem a mesma origem e consegue alterar as condições de sua incorporação. Se ambas as permissões forem necessárias, sirva o conteúdo não confiável a partir de uma origem deliberadamente separada e analise as possibilidades de escapar do sandbox, em vez de tratar o atributo como a única barreira.

Formulários e acesso à rede

allow-forms restabelece o envio de formulários, mas scripts e elementos HTML comuns também podem enviar requisições de outras formas. Nunca coloque credenciais, dados privados de clientes ou tokens de acesso do tipo bearer em uma prévia não confiável presumindo que o sandbox impedirá seu vazamento.

Pop-ups e escape do sandbox

allow-popups permite que um iframe abra um novo contexto de navegação. allow-popups-to-escape-sandbox permite que o novo contexto não herde as restrições do sandbox. Isso pode ser útil para um anúncio ou link externo deliberadamente isolado, mas amplia o escopo da análise.

Navegação da página principal

As permissões de navegação da página principal permitem que o iframe substitua a página que o incorpora sob condições definidas. Um ambiente de experimentação de código raramente precisa disso. Se a navegação fizer parte da atividade, considere interceptar e exibir o destino em vez de dar à prévia controle sobre a página principal.

O que um sandbox não consegue proteger?

Um sandbox é um mecanismo do navegador, não uma plataforma completa para executar código hostil.

• Ele não impede que o usuário abra o mesmo conteúdo diretamente fora do iframe.
• Ele não garante que os scripts permitidos sejam rápidos, não incomodem o usuário ou estejam livres de loops infinitos.
• Ele não bloqueia automaticamente todas as solicitações de rede.
• Ele não sanitiza o HTML nem comprova que uma URL seja segura.
• Ele não protege segredos já colocados na visualização.
• Ele não substitui a validação no servidor para formulários reais.
• Ele não valida acessibilidade, semântica ou comportamento entre navegadores.
• Ele não protege outro serviço que aceite uma requisição da prévia.

O isolamento também muda com a evolução dos navegadores e dos padrões. Teste o comportamento dos recursos nos navegadores que o público realmente usa e revise a lista de tokens com base nas especificações atuais.

Como projetar uma prévia de código no navegador?

Comece com o atributo sandbox vazio e acrescente uma permissão por vez. Para cada acréscimo, crie um pequeno teste de aceitação e um teste correspondente de uso abusivo.

Mantenha restrito o protocolo de mensagens entre a página principal e o iframe. Valide o remetente, a estrutura das mensagens e os comandos permitidos. Não aceite código arbitrário nem instruções de navegação por uma mensagem genérica de “execução”, a menos que esse seja o produto explicitamente isolado que você pretende criar.

Ofereça um modo com JavaScript desativado para inspeção estática. Acrescente controles para parar, reiniciar ou recarregar exemplos que saiam de controle. Exiba erros do console sem copiar dados sensíveis da página principal para o iframe. Trate folhas de estilo e scripts externos como dependências de rede cujos servidores e conteúdos futuros estão fora do controle do editor.

Para um experimento focado, o editor HTML em tempo real oferece larguras responsivas, captura do console, verificações e a indicação do estado do sandbox de origem opaca. Para trabalhos de lançamento que envolvam pacotes, servidores, credenciais, testes ou implantação, leve o código para um repositório local e adote um processo mais completo de desenvolvimento e revisão de segurança.