O target="_blank" é o atributo do link que manda o navegador abrir o endereço em uma nova aba (ou em uma nova janela, se o usuário configurou o navegador assim). A vulnerabilidade ligada a ele, em que a página aberta conseguia trocar a aba de origem por uma página falsa, já é bloqueada por padrão nos navegadores atuais.
Isso não quer dizer que o assunto morreu. Ainda há situações em que vale escrever rel="noopener" ou rel="noreferrer" por conta própria, e há casos em que abrir uma nova aba atrapalha mais do que ajuda. Abaixo você vê o que o atributo faz, como era o ataque, o que mudou e como escrever seus links hoje.
O que o target=”_blank” faz
O atributo target diz ao navegador onde abrir o link. Sem ele, o link abre na mesma aba, substituindo a página atual. Com o valor _blank, o navegador cria um contexto novo, que normalmente é uma aba:
<!-- abre na mesma aba (comportamento padrão) -->
<a href="https://exemplo.com.br">Mesma aba</a>
<!-- abre em uma nova aba -->
<a href="https://exemplo.com.br" target="_blank">Nova aba</a>
O _blank é o valor mais usado, mas não é o único. A documentação do elemento <a> na MDN lista as palavras reservadas:
| Valor do target | Onde o link abre |
|---|---|
_self (padrão) | Na mesma aba ou no mesmo frame |
_blank | Em uma nova aba (ou nova janela, conforme a configuração do usuário) |
_parent | No frame “pai” da página atual; se não houver frame, age como _self |
_top | Na janela inteira, saindo de todos os frames; se não houver frame, age como _self |
Um nome qualquer, como ajuda | Na aba que tem esse nome; se ela não existir, o navegador cria e reaproveita nos cliques seguintes |
O target não muda a velocidade de carregamento, não tira o link do histórico e não converte o tipo de arquivo. Ele só define o destino. É por isso que target="blank", sem o sublinhado, não é a mesma coisa: o navegador entende “blank” como o nome de uma aba. O primeiro clique abre uma aba nova, e os cliques seguintes em links com o mesmo target reaproveitam essa aba em vez de abrir outra.
Como funcionava o ataque: reverse tabnabbing
Antes da mudança nos navegadores, a página aberta pelo link recebia uma referência à aba de origem pela propriedade window.opener. Se o destino fosse de outro domínio, ele não conseguia ler o conteúdo da sua página, mas podia mandar a aba de origem navegar para outro endereço. Esse truque ganhou o nome de reverse tabnabbing, e funcionava assim:
- Seu site publica um link para outro site com
target="_blank". Pode ser um link seu ou um link deixado por alguém num comentário, fórum ou perfil. - O visitante clica e a página externa abre na nova aba.
- Um script nessa página troca, em segundo plano, o endereço da aba anterior por uma cópia da sua tela de login.
- O visitante fecha a aba nova, volta para a sua, vê um aviso de “sessão expirada” e digita a senha na página falsa.
Do lado do atacante, bastavam três linhas:
<script>
if (window.opener) {
window.opener.location = "https://login-falso.exemplo/entrar";
}
</script>
O perigo está no último passo. A aba trocada é justamente a que o visitante já conhecia, e a troca acontece longe dos olhos dele. É uma variação do phishing, golpe que explicamos no artigo sobre perigos da internet.

Para testar: a página de demonstração de Mathias Bynens reproduz o ataque. Num navegador atualizado ela não funciona mais, o que já mostra o efeito da mudança descrita a seguir.
O que mudou nos navegadores
A regra do HTML passou a determinar que links com target="_blank" se comportem como se tivessem rel="noopener". Na prática, a página aberta recebe window.opener igual a null e não tem como mexer na aba de origem. Segundo a página do noopener na MDN (em inglês) e a tabela de compatibilidade que ela traz, os principais navegadores adotaram esse comportamento entre 2019 e 2021:
| Navegador | Primeira versão com noopener implícito | Lançamento |
|---|---|---|
| Safari | 12.1 | Março de 2019 |
| Firefox | 79 | Julho de 2020 |
| Chrome | 88 | Janeiro de 2021 |
| Edge | 88 | Janeiro de 2021 |
A regra vale para links (<a> e <area>) e para formulários com target="_blank". Quem usa uma versão do Chrome, Edge, Firefox ou Safari dos últimos anos já está protegido, mesmo que o site não tenha escrito nada além do target.
O WordPress acompanhou a mudança. Até 2024, o núcleo do sistema acrescentava rel="noopener" sozinho nos links com target="_blank". Na versão 6.7, lançada em novembro de 2024, esse ajuste automático foi removido, justamente porque os navegadores já fazem o trabalho. Os links salvos antes disso continuam com o rel que já tinham, e não há nada a corrigir neles.
Quando ainda vale escrever rel=”noopener”
O comportamento automático cobre o caso mais comum, mas deixa algumas brechas de fora. Nestas situações, escreva a proteção de forma explícita:
- Janelas abertas por JavaScript com
window.open(). Aqui não existe noopener implícito: a nova janela recebewindow.opener, a menos que você peça o contrário. - Links com target nomeado, como
target="ajuda"ou o erro de digitaçãotarget="blank". A proteção automática só se aplica ao valor_blank. - Visitantes com navegador desatualizado ou que abrem seu site pelo navegador embutido de algum aplicativo antigo.
- Conteúdo enviado por usuários (comentários, fóruns, perfis, anúncios), onde você não controla para onde os links apontam.
Para o window.open(), a proteção vai no terceiro parâmetro:
// sem proteção: a nova janela recebe window.opener
window.open("https://parceiro.exemplo/");
// com proteção: window.opener fica null na nova janela
window.open("https://parceiro.exemplo/", "_blank", "noopener");
Nos links em HTML, escrever rel="noopener" mesmo com a proteção automática não custa nada. Deixa a intenção clara para quem for revisar o código e evita alertas de ferramentas que ainda apontam target="_blank" sem rel, como a regra jsx-no-target-blank do ESLint em projetos React.
Existe também o caminho inverso. Se você precisa que a janela aberta converse com a página de origem (por exemplo, um login em janela pop-up que devolve o resultado), use rel="opener" para manter o vínculo de propósito, e só com destinos que você controla.
noopener x noreferrer: qual a diferença
Os dois valores aparecem juntos com tanta frequência que muita gente acha que são a mesma coisa. Não são. O noreferrer faz tudo o que o noopener faz e mais uma coisa: esconde de onde veio a visita.
| rel=”noopener” | rel=”noreferrer” | |
|---|---|---|
| Bloqueia o acesso ao window.opener | Sim | Sim |
| Envia o cabeçalho Referer (a origem da visita) | Sim, normalmente só o domínio | Não |
| Como a visita aparece nas estatísticas do outro site | Vinda do seu domínio | Acesso direto, sem origem |
| Quando usar | Links externos em geral e janelas abertas por JavaScript | Quando o endereço de origem não deve ser revelado, como links saindo de um painel interno ou de páginas com dados na URL |
Um detalhe que muda a decisão: por padrão, os navegadores atuais já enviam ao outro site só o domínio de origem (por exemplo, https://seusite.com.br/), e não o caminho completo da página. Na maioria dos sites, então, o noreferrer não protege nenhuma informação sensível e só apaga o crédito pela visita.
Se você tem parceria com outro site e quer aparecer como fonte de tráfego nas estatísticas de acesso dele, prefira só o noopener:
<!-- bloqueia o window.opener; o destino ainda vê a origem -->
<a href="https://parceiro.exemplo" target="_blank" rel="noopener">Parceiro</a>
<!-- bloqueia o window.opener e esconde a origem -->
<a href="https://exemplo.com" target="_blank" rel="noopener noreferrer">Link externo</a>
Escrever noopener noreferrer juntos é redundante, já que o segundo inclui o primeiro, mas não causa problema. Você ainda encontra por aí a recomendação de usar noreferrer porque “o Firefox não entende noopener“. Isso valia só para versões do Firefox de muitos anos atrás.
Quando não abrir o link em nova aba
Com a segurança resolvida pelos navegadores, sobra a questão de usabilidade. Abrir uma aba nova tira do visitante uma escolha que ele pode fazer sozinho, com o botão do meio do mouse ou Ctrl/Cmd + clique. Na aba nova, o botão Voltar também deixa de funcionar, o que confunde quem não percebeu a troca.
A MDN chama atenção para quem tem baixa visão, usa leitor de tela ou tem dificuldades cognitivas: uma aba que abre sem aviso pode desorientar, e leitores de tela mais antigos nem anunciam a mudança. Por isso, prefira a mesma aba quando:
- o link leva para outra página do seu próprio site;
- a maior parte do público acessa pelo celular, onde a troca de aba é pouco visível;
- o link é o próximo passo natural da leitura, como a página de compra ou de contato.
A nova aba faz sentido quando a pessoa está no meio de uma tarefa e perderia o que já preencheu, como um link para os termos de uso dentro de um formulário de cadastro ou para a ajuda durante o checkout. Nesses casos, avise no próprio texto do link:
<a href="https://seusite.com.br/termos.pdf" target="_blank" rel="noopener">
Termos de uso (PDF, abre em nova aba)
</a>
Acessibilidade: as diretrizes de acessibilidade para a web (WCAG) recomendam avisar antes que um link abra uma nova janela. Um texto como “abre em nova aba” ou um ícone com texto alternativo já resolve.
Como revisar os links do seu site
Uma revisão rápida resolve os casos que a proteção automática não cobre e ainda melhora a navegação:
- Procure
target=no código do tema, nos modelos de página e no conteúdo (no WordPress, o editor de código mostra o HTML de cada bloco). - Nos links para páginas do seu próprio domínio, pergunte se a nova aba é mesmo necessária. Na dúvida, tire o
target. - Nos links externos que vão continuar abrindo em nova aba, acrescente
rel="noopener", ourel="noopener noreferrer"se não quiser revelar a origem. - Procure
window.open(nos arquivos JavaScript e inclua"noopener"no terceiro parâmetro quando o destino for de outro domínio. - Corrija erros de digitação que anulam a proteção:
target="blank",target="_black"erel="noreferer"(com um “r” só, o navegador ignora o valor). - Em comentários e outros conteúdos de usuários, deixe o sistema marcar os links com
rel="nofollow ugc noopener"ou remova otargetdesses links.
Quem administra o servidor pode ir além com um cabeçalho HTTP que corta o vínculo entre a sua página e qualquer janela de outro domínio aberta a partir dela, mesmo que algum link escape da revisão:
Cross-Origin-Opener-Policy: same-origin
Teste antes de aplicar no site inteiro: esse cabeçalho pode quebrar fluxos que dependem de janelas pop-up de outros domínios, como login social e algumas telas de pagamento. Para outras medidas de proteção, veja as dicas de segurança do WordPress.
Na SAN: links bem escritos fecham uma porta para o phishing, mas o golpe também pode chegar por um site invadido que passa a hospedar páginas falsas. A Proteção Avançada da hospedagem da SAN usa inteligência artificial para bloquear malware e phishing no seu site.
Se você desconfia que isso já aconteceu, o guia sobre site com vírus ou malware mostra como identificar e limpar.
Perguntas frequentes
Ele indica que o link deve abrir em um novo contexto de navegação, normalmente uma nova aba. Sem o atributo target, o link abre na mesma aba.
Nos links em HTML, os navegadores atuais (Chrome e Edge desde a versão 88, Firefox desde a 79 e Safari desde a 12.1) já aplicam o noopener sozinhos. Continue usando em janelas abertas com window.open(), em targets com nome e quando o público pode ter navegadores antigos.
O noopener impede que a página aberta acesse a aba de origem pelo window.opener. O noreferrer faz o mesmo e também deixa de informar ao outro site de onde veio a visita.
Abre uma nova aba no primeiro clique, mas o navegador trata “blank” como o nome de uma aba e reaproveita essa mesma aba nos cliques seguintes. A proteção automática de noopener também não se aplica, então use _blank.
O efeito do noreferrer é nas estatísticas de quem recebe a visita, que passa a contá-la como acesso direto, sem o seu site como origem. Para parceiros que querem ver o tráfego vindo de você, prefira só o noopener.