Como usar iframe sandbox com segurança em landing pages criadas por IA — Blog

Uma landing page criada por IA pode incorporar vídeo, checkout, formulário, demonstração ou conteúdo de parceiro em um iframe. O atributo sandbox permite começar com várias capacidades bloqueadas e devolver somente as que a integração realmente precisa.

O ganho desaparece quando a lista de exceções é copiada sem análise. Tokens como allow-scripts, allow-same-origin, allow-forms, allow-popups e allow-top-navigation não são uma coleção de boas práticas: cada um remove uma restrição específica. A configuração correta nasce do contrato do embed, da origem que o serve e dos testes de rejeição.

Este guia mostra como inventariar frames, escolher tokens mínimos, separar sandbox de outras políticas do navegador e validar o resultado na Version publicada.

Comece com todas as restrições

Um atributo vazio ativa o conjunto de restrições do sandbox:

<iframe src="https://widget.exemplo/preview" title="Prévia do projeto" sandbox></iframe>

Nesse estado, o conteúdo perde capacidades como executar scripts, enviar formulários, abrir janelas e navegar o contexto superior. Sem allow-same-origin, ele também recebe uma origem opaca para várias verificações de mesma origem.

A lógica é de menor privilégio: comece vazio, execute o fluxo e libere uma capacidade por vez somente quando uma falha esperada demonstrar a necessidade. A referência de iframe da MDN descreve cada token e alerta que certas combinações podem anular o isolamento pretendido.

Não aplique sandbox às cegas em um widget já em produção. Uma restrição nova pode interromper pagamento, autenticação, download, formulários ou comunicação com a página pai. Faça a mudança em ambiente controlado, com conta de teste e matriz de comportamento.

Inventarie todos os frames e recursos relacionados

Procure HTML estático, componentes, templates e criação dinâmica:

rg -n \
  '<iframe|createElement\(["'"']iframe|sandbox=|\.sandbox\.|postMessage\(|frame-src|Permissions-Policy' \
  src public

Para cada frame, registre:

arquivo e linha:
src e redirects possíveis:
origem proprietária:
conteúdo controlado por:
scripts necessários:
formulários necessários:
armazenamento ou cookies:
pop-ups e downloads:
navegação do topo:
postMessage enviado e recebido:
permissões de câmera, microfone ou geolocalização:
tokens atuais:
evidência de cada token:

Inclua frames criados por gerenciadores de tags e SDKs. Se a integração injeta o elemento em runtime, a ausência de <iframe> no HTML fonte não encerra a busca.

Confirme também a cadeia de redirects do src. Um host aprovado pode encaminhar o frame para outra origem, alterando cookies, mensagens e acesso a recursos.

Libere somente capacidades demonstradas

Uma demonstração que precisa executar JavaScript, mas não depende da origem real, pode começar assim:

<iframe
  src="https://demo.exemplo/embed"
  title="Demonstração interativa"
  sandbox="allow-scripts"
></iframe>

Um fluxo que precisa enviar um formulário pode exigir allow-forms. Um botão que abre documentação em outra aba pode exigir allow-popups. Não adicione o token antes de confirmar o caso e o destino.

Use uma tabela de decisão:

Necessidade comprovada	Token candidato	O que testar
executar JavaScript	`allow-scripts`	fluxo funciona sem liberar origem ou navegação
enviar formulário	`allow-forms`	destino e métodos permanecem aprovados
abrir nova janela	`allow-popups`	URL, `opener` e sandbox da janela resultante
download iniciado pela pessoa	`allow-downloads`	tipo, origem e nome do arquivo
navegar o topo após gesto	`allow-top-navigation-by-user-activation`	apenas gesto real e destino permitido

Evite allow-top-navigation quando a versão condicionada a ativação resolve o fluxo. Evite allow-popups-to-escape-sandbox sem revisar por que a nova janela precisa abandonar as restrições herdadas.

Um token libera uma categoria de comportamento, não apenas o botão observado no teste feliz. Revise todos os caminhos que passam a caber nessa categoria.

Trate allow-scripts com allow-same-origin como combinação crítica

Sem allow-same-origin, o documento sandboxed costuma ser tratado como origem opaca. Isso restringe acesso a cookies, armazenamento e APIs que dependem de origem. Adicionar o token preserva a origem real do recurso.

Quando um documento de mesma origem recebe ao mesmo tempo allow-scripts e allow-same-origin, ele pode executar código e acessar o elemento no documento pai. A MDN e o HTML Living Standard alertam que esse cenário pode permitir remover o atributo sandbox, eliminando o benefício.

Não trate a combinação como proibida em qualquer contexto, mas exija uma justificativa forte:

o conteúdo é realmente de outra origem?
essa origem possui isolamento operacional próprio?
scripts e identidade de origem são ambos indispensáveis?
o frame consegue navegar ou abrir o conteúdo fora do sandbox?
uma página intermediária controlada pode reduzir as permissões?

Conteúdo não confiável deve ser servido de uma origem separada. O sandbox só existe enquanto o documento está naquele contexto; se a pessoa abrir o mesmo conteúdo diretamente, as restrições do elemento não o acompanham.

Não confunda sandbox com outras fronteiras

O sandbox controla capacidades do documento incorporado. Ele não substitui:

frame-ancestors, que define quem pode incorporar a sua página;
frame-src, que limita quais origens sua página pode carregar como frame;
Permissions Policy e o atributo allow, que governam capacidades como câmera e microfone;
validação de postMessage, que protege o protocolo entre janelas;
CSP de scripts, conexões e outros recursos;
autorização no backend.

Por exemplo:

<iframe
  src="https://video.exemplo/embed/123"
  title="Vídeo de demonstração"
  sandbox="allow-scripts"
  allow="fullscreen"
></iframe>

O atributo allow não torna o sandbox mais restritivo; ele representa outra política. A capacidade precisa ser permitida pelas camadas relevantes para funcionar.

Se a página incorporada troca mensagens com o pai, valide event.origin, event.source e o schema. O guia de uso seguro de postMessage cobre esse protocolo. Para proteger a sua página contra incorporação indevida, consulte o guia de prevenção de clickjacking.

Revise pop-ups, downloads e navegação

Frames de checkout e autenticação frequentemente abrem novas janelas. Teste:

se o pop-up herda restrições;
se window.opener permanece acessível;
quais redirects acontecem antes do destino final;
se uma janela nomeada é reutilizada;
se o frame consegue navegar a página superior;
se downloads partem de gesto explícito;
se URLs dinâmicas usam origem e protocolo aprovados.

Não libere navegação do topo para corrigir um redirect mal modelado. Quando o frame só precisa informar sucesso, uma mensagem mínima ao pai pode ser mais controlável — desde que o protocolo seja validado e o backend confirme estados críticos.

O artigo sobre reverse tabnabbing ajuda a revisar opener, janelas nomeadas e destinos externos.

Teste bloqueios, não apenas o fluxo feliz

Monte uma matriz por integração:

Caso	Resultado esperado
script sem `allow-scripts`	execução bloqueada
formulário sem `allow-forms`	envio bloqueado
pop-up sem token correspondente	abertura bloqueada
tentativa de navegar o topo	bloqueada sem capacidade explícita
origem ou janela errada em `postMessage`	mensagem ignorada
recurso que precisa de permissão não concedida	falha controlada
fluxo aprovado com tokens mínimos	concluído sem exceções extras

Observe Console e Network, mas registre o comportamento, não apenas mensagens específicas que podem mudar entre navegadores. Repita na matriz de browsers suportados e com dados de teste.

Evite testar widgets de terceiros com ações reais ou contas de produção. A evidência necessária é que capacidades indevidas são rejeitadas e o caso autorizado continua funcionando.

Publique e verifique o artefato final

O contrato de Publicação envia os arquivos HTML, CSS, JavaScript e assets preparados pelo projeto. O Site no Ar não deduz quais tokens um widget precisa nem reescreve seus iframes.

Antes de publicar:

gere o pacote final;
inspecione os elementos criados em runtime;
confirme tokens e atributos allow;
execute a matriz de bloqueio;
registre integrações que não suportam menor privilégio;
confira se nenhum segredo foi incluído no frontend.

Depois, abra a URL padrão e cada domínio próprio ativo. Origens mudam com esquema, host e porta; isso pode afetar armazenamento, cookies, mensagens e permissões. Teste novamente o fluxo real publicado.

Se ajustar tokens ou mover o conteúdo para uma origem isolada, gere uma nova versão e republique o mesmo Site para preservar a URL já aprovada.

Prompt copiável para o agente

Revise todos os iframes desta landing page antes de publicar.

Pasta publicável: [caminho]
URL de teste: [URL]
Domínios finais: [lista]
Integrações aprovadas: [lista]

- Inventarie iframes estáticos, dinâmicos e injetados por SDKs.
- Comece com sandbox vazio e libere um token por necessidade comprovada.
- Documente scripts, formulários, pop-ups, downloads e navegação do topo.
- Trate allow-scripts + allow-same-origin como combinação crítica.
- Prefira origem separada para conteúdo não confiável.
- Não confunda sandbox, frame-ancestors, frame-src, Permissions Policy e postMessage.
- Teste bloqueios e o fluxo autorizado em navegadores suportados.
- Não execute ações reais em contas ou sistemas de terceiros.
- Verifique o DOM final na URL publicada e em domínios próprios.
- Entregue tokens mínimos, evidências e riscos restantes.

Checklist final

iframe sandbox funciona melhor como uma lista explícita de exceções a um bloqueio inicial. Quando cada capacidade tem motivo, proprietário e teste, o embed deixa de depender de uma sequência copiada e passa a ter um contrato verificável.