Verificador de iframe
Verificador de iframe online gratuito: insira o URL de qualquer página para inspecionar seus cabeçalhos X-Frame-Options e frame-ancestors do Content-Security-Policy, descubra se a página pode ser incorporada em um iframe e confirme com uma pré-visualização ao vivo. O histórico é mantido apenas para a sessão atual do navegador.
Histórico (esta sessão)
Salvo apenas nesta aba (sessionStorage); apagado ao fechar a aba. Nenhuma informação é enviada ao servidor.
Como funciona a verificação
- Insira o URL de destino e clique em Verificar. O servidor acessa a página como uma solicitação real de iframe (com Sec-Fetch-Dest: iframe) e lê os cabeçalhos de resposta.
- O resultado é determinado pelo X-Frame-Options (DENY / SAMEORIGIN bloqueiam a exibição em iframe) e pelo frame-ancestors do Content-Security-Policy (apenas * ou coringas de protocolo permitem que terceiros incorporem a página livremente).
- O mesmo URL é carregado no iframe de pré-visualização ao vivo para que você possa confirmar o comportamento real do navegador, incluindo mecanismos de "frame-busting" em JavaScript que os cabeçalhos não revelam.
O que determina se uma página pode ser incorporada?
A possibilidade de uma página ser exibida dentro de um <iframe> em outro site é decidida pelo navegador, com base nos cabeçalhos de resposta enviados pela própria página. Este verificador replica a mesma análise no lado do servidor e entrega um resultado imediato.
O X-Frame-Options é o cabeçalho clássico: DENY proíbe a incorporação em todas as páginas, SAMEORIGIN permite apenas que páginas da mesma origem as incorporem, e ALLOW-FROM foi removido dos navegadores modernos. Na ausência desse cabeçalho, regras legadas não bloqueiam a incorporação.
O Content-Security-Policy frame-ancestors é a alternativa moderna. Ele lista as origens permitidas para incorporar a página — por exemplo, frame-ancestors 'self' https:\/\/example.com. O valor * (ou apenas um protocolo como https:) permite qualquer página pai via HTTPS; valores mais restritivos bloqueiam a incorporação por terceiros.
Os cabeçalhos não contam toda a história: scripts da página podem executar código anti-incorporação (comparando top !== self e forçando navegação de nível superior), e páginas de login ou endpoints georestringidos podem se comportar de forma diferente para solicitações originadas de datacenters. Por isso, cada resultado vem acompanhado de uma pré-visualização ao vivo.
Guia rápido: configuração dos cabeçalhos de resposta
Se você controla o site, gerencie a incorporação diretamente pelos cabeçalhos de resposta.
Bloquear incorporação de qualquer página
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'
Os navegadores negam exibir a página em qualquer <iframe> — a proteção mais rigorosa contra clickjacking.
Permitir incorporação apenas da mesma origem
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Apenas páginas com mesmo esquema, host e porta podem incorporá-la; sites de terceiros são bloqueados.
Permitir apenas origens específicas
Content-Security-Policy: frame-ancestors 'self' https:\/\/trusted.example.com
Adicione as origens confiáveis no frame-ancestors; origens não listadas serão bloqueadas.
Permitir incorporação de qualquer página
Não defina o X-Frame-Options
Content-Security-Policy: frame-ancestors *
Qualquer site pode carregar a página em um <iframe>. Avalie o impacto na segurança.
Nota: O X-Frame-Options foi substituído pelo CSP frame-ancestors. Quando ambos estão presentes, o CSP prevalece — prefira frame-ancestors.
Como o servidor detecta se uma solicitação vem de um iframe?
Desde ~2020, navegadores baseados em Chromium e Firefox anexam automaticamente um conjunto de cabeçalhos Fetch Metadata a cada solicitação de navegação e subrecurso. O mais útil para verificações de incorporação é o Sec-Fetch-Dest — ele informa ao servidor qual tipo de contexto solicitou o recurso, sem exigir cooperação da página que faz a requisição.
- Sec-Fetch-Dest: document — navegação de nível superior, fora de qualquer frame.
- Sec-Fetch-Dest: iframe — a solicitação é carregada dentro de um elemento <iframe>.
- Sec-Fetch-Dest: frame — carregado dentro de um <frame> legado (frameset).
- Sec-Fetch-Dest: embed \/ object — carregado dentro de um elemento <embed> ou <object>.
Este verificador envia sua própria solicitação de teste com `Sec-Fetch-Dest: iframe`, simulando exatamente o que um navegador real envia ao incorporar uma página — assim, o veredito reflete como o servidor de destino realmente se comporta em chamadas genuínas de iframe, e não apenas em buscas genéricas (`fetch`).
`Sec-Fetch-Dest` é um sinal útil, mas não uma barreira de segurança: ele é enviado apenas por navegadores modernos, e clientes fora de navegador — curl, bots, algumas webviews e navegadores mais antigos — podem ignorá-lo totalmente ou enviar um valor arbitrário. Um servidor deve registrar logs ou aplicar limitação de taxa com base nisso, mas nunca depender exclusivamente dele para decidir se a inserção em frame é segura; essa decisão cabe ainda aos cabeçalhos `X-Frame-Options` e `CSP frame-ancestors`, que os navegadores aplicam independentemente dos cabeçalhos da solicitação.
No lado do cliente, uma página também pode detectar que está rodando dentro de um frame sem precisar de nenhum cabeçalho, por exemplo, comparando `window.top !== window.self` (ou lendo `window.frameElement` para frames de mesma origem), e então agir — exibir um aviso ou forçar um redirecionamento de nível superior. Essa é a técnica frame-busting mencionada anteriormente, e funciona independentemente dos cabeçalhos enviados na solicitação.
Exemplos de configuração de servidor: bloquear incorporação em iframe
Os trechos abaixo mostram como configurar cada servidor ou framework para bloquear totalmente a incorporação por <iframe> (X-Frame-Options: DENY + CSP frame-ancestors 'none') — a configuração mais rigorosa do guia rápido acima.
server {
location / {
add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;
}
}
<IfModule mod_headers.c>
Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "frame-ancestors 'none'"
</IfModule>
app.use((req, res, next) => {
res.setHeader('X-Frame-Options', 'DENY');
res.setHeader('Content-Security-Policy', "frame-ancestors 'none'");
next();
});
// next.config.js
module.exports = {
async headers() {
return [
{
source: '/:path*',
headers: [
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'Content-Security-Policy', value: "frame-ancestors 'none'" },
],
},
];
},
};
class SetFrameOptions
{
public function handle(Request $request, Closure $next): Response
{
$response = $next($request);
$response->headers->set('X-Frame-Options', 'DENY');
$response->headers->set('Content-Security-Policy', "frame-ancestors 'none'");
return $response;
}
}
export default {
async fetch(request) {
const response = await fetch(request);
const headers = new Headers(response.headers);
headers.set('X-Frame-Options', 'DENY');
headers.set('Content-Security-Policy', "frame-ancestors 'none'");
return new Response(response.body, { status: response.status, headers });
},
};
Precisa permitir apenas seu próprio domínio, ou uma lista reduzida de permitidos, para incorporar a página em vez de bloquear todos? Troque DENY por SAMEORIGIN e 'none' por 'self' ou uma lista explícita de origens — o restante da configuração permanece igual.
Pontos de atenção em plataformas conhecidas
Deixando as regras gerais de cabeçalhos de lado, algumas plataformas bem conhecidas têm particularidades próprias — vale a pena saber disso antes de assumir que algo está \"bloqueado\" ou \"incorporável\" só com base nos cabeçalhos.
| Plataforma \/ cenário | Veredito | Por que |
|---|---|---|
| Página de visualização do YouTube (youtube.com\/watch) | Bloqueado | Use a URL oficial do player do YouTube (`youtube.com\/embed\/ {id}`) no lugar — a página normal de visualização envia uma política de incorporação restritiva. |
| Página de local do Google Maps | Bloqueado | Apenas a URL do iframe da API de Incorporação do Maps (google.com\/maps\/embed) foi projetada para ser incorporada. |
| Páginas de login OAuth do Google \/ Microsoft | Bloqueado | Bloqueado intencionalmente desde 2015 para evitar phishing de credenciais em iframes; o fluxo de login deve ser executado em uma janela de nível superior ou pop-up. |
| Páginas de finalização de pagamento (Stripe Checkout, PayPal, a maioria dos gateways bancários) | Bloqueado | Incorporar formulários de pagamento em frames é um vetor clássico de clickjacking, por isso os processadores negam totalmente esse comportamento. |
| Páginas de repositórios \/ arquivos do GitHub | Bloqueado | Diretriz `frame-ancestors 'none'` aplicada ao site inteiro; utilize a API REST\/GraphQL ou um print screen em vez de incorporar via iframe. |
| Páginas \"Publique na web\" do Notion \/ Google Docs | Incorporável | Projetadas explicitamente para incorporação, além de oferecerem código pronto para uso no produto. |
| Artigos da Wikipédia | Incorporável | Sem `X-Frame-Options`\/CSP restritivo por padrão, mas verifique os termos de licenciamento e atribuição antes de incorporar em larga escala. |
Casos de uso comuns
- Defina se um widget, painel ou documento de terceiros pode ser incorporado ao seu produto antes de escrever o código de integração.
- Verifique se o seu próprio site está enviando a política de `X-Frame-Options` ou `CSP frame-ancestors` desejada.
- Depurar a proteção contra clickjacking: entenda por que uma página exibe `about:blank` ou uma mensagem de bloqueio dentro de um iframe.
- Validar em lote URLs candidatas durante a agregação de conteúdo ou integração com portais, utilizando o histórico da sessão para revisar os resultados.
- Prepare-se para auditorias de segurança ou testes de penetração documentando a política de incorporação de dependências externas.