Rejeite no servidor qualquer token ausente ou cuja validação falhe; depois, encaminhe a pessoa ao fluxo de confirmação por e-mail que seu produto já usa. Essa é a opção segura se você está testando sua própria integração da Chrome Email Verification API: valide separadamente o token, o estado da conta e a mensagem de recuperação recebida. Um resultado positivo em apenas uma dessas verificações não aprova o fluxo completo.
Este guia é para você que revisa a segurança de contas ou prepara uma liberação gradual e precisa garantir que uma falha no recurso experimental não contorne a verificação existente.
O limite do teste: controle do endereço não é recebimento
A API trata de uma prova associada à sessão do provedor de e-mail e ao controle de um endereço. Isso não comprova, por si só, que seu aplicativo enviou uma mensagem, que ela chegou à caixa de entrada ou que o link de confirmação funciona. Para esses resultados, você precisa testar seu próprio servidor e, separadamente, o fluxo de e-mail.
A documentação para desenvolvedores descreve a Email Verification API como uma proposta no Chrome Origin Trial e orienta o servidor a verificar declarações, vínculo de chave e assinatura do Email Verification Token (EVT). Se o token não estiver presente ou uma etapa de validação falhar, o site deve recorrer ao processo de confirmação de e-mail já existente. Confira a documentação da API e o fluxo de falha antes de definir os critérios da sua versão: a proposta pode evoluir, e não é prudente tratar comportamentos ainda não documentados como garantias estáveis.
A referência oficial identifica declarações como email, aud, nonce, iat e exp para a validação. São cinco campos que você pode incluir em uma matriz de casos negativos, sempre comparando cada valor com o que seu servidor espera, e não com uma suposição genérica sobre o protocolo. A orientação de verificação no servidor é a fonte para conferir esse limite.
Prepare o ambiente antes de injetar falhas
Faça os testes apenas na sua aplicação de desenvolvimento, em uma implantação de teste isolada ou em outro ambiente para o qual você tenha autorização. Não provoque falhas em contas de terceiros nem use dados pessoais reais para simular cadastros. Prefira endereços controlados e identificadores de teste que não correspondam a pessoas.
Antes de começar, confirme que você consegue observar, sem expor segredos:
- a requisição de cadastro e o identificador que permite correlacioná-la com os registros do servidor;
- o resultado de cada etapa de validação, sem gravar o EVT ou material criptográfico sensível em logs;
- o estado da conta antes e depois da tentativa;
- a mensagem exibida na interface;
- o disparo e a leitura da mensagem de confirmação, quando o caso exigir retorno ao fluxo de e-mail.
Defina de antemão o que significa “recusar” no seu produto. Pode significar não criar uma sessão autenticada, manter a conta em estado pendente ou impedir uma ação protegida até a confirmação. O detalhe depende da arquitetura. O ponto invariável é que o servidor não deve registrar a propriedade do endereço como comprovada só porque o cliente enviou um token ou porque uma chamada terminou sem erro.
Se você estiver organizando dados de cadastro de teste, consulte também as recomendações de privacidade para formulários de inscrição. A separação entre ambientes e a minimização de dados ajudam a evitar que uma rodada de QA acione comunicações para pessoas reais.
Cenário: nenhuma declaração EVT acompanha a solicitação
O que fazer quando não há token na solicitação? Simule o caso em que o navegador ou o fluxo de integração não fornece um EVT. Isso pode representar uma sessão sem suporte ao recurso, um token não emitido ou uma resposta que não chegou ao seu código. O teste não precisa determinar qual dessas situações ocorreu: ele precisa demonstrar que seu servidor não converte ausência em aprovação.
Envie uma solicitação de cadastro sem a informação esperada e observe o comportamento de ponta a ponta. A tela deve oferecer uma orientação compatível com o produto. A conta deve permanecer sem verificação de propriedade do endereço. Se o desenho do seu fluxo permitir cadastro pendente, confirme que operações protegidas continuam bloqueadas até a confirmação tradicional.
A documentação oficial indica que, na ausência do token, o site deve voltar ao fluxo padrão de confirmação por e-mail. Portanto, registre se o seu sistema inicia esse fluxo e se a conta continua pendente enquanto a mensagem não for confirmada. Não trate apenas a exibição de uma mensagem na interface como prova de que o e-mail foi enviado.
Esse cenário também detecta uma falha comum de integração: o cliente omite o campo, mas o servidor interpreta a ausência como um caso dispensado de validação. A decisão deve ser explícita. Seu código precisa distinguir “não há token validável” de “o endereço foi comprovado”.
Cenário: o EVT contém declarações inesperadas
Como validar email, aud, nonce ou exp incorretos? Crie casos isolados em que cada valor não corresponda ao contexto esperado pela aplicação. O mesmo vale para iat, conforme as regras de validação implementadas no servidor e a orientação oficial. Não invente limites de idade, tolerâncias ou regras temporais que a documentação do protocolo não estabeleça.
Para email, use uma identidade controlada e confirme que o servidor compara o endereço comprovado com o endereço associado à solicitação. Para aud, confira a correspondência com o destinatário ou contexto esperado pela sua implementação. Para nonce, associe o valor à instância correta do formulário. Envie um valor de outra sessão de teste e confirme que ele não autoriza a conta atual. Para iat e exp, construa cenários que seu validador reconheça como inconsistentes com a política implementada; não suponha uma duração padrão nem uma estratégia de renovação.
Um teste útil é abrir dois formulários de cadastro independentes no seu ambiente de teste e cruzar os dados de contexto de forma controlada. O servidor deve avaliar o nonce em relação à solicitação que está processando, não apenas verificar se existe algum nonce. Depois, confirme o estado da conta de cada fluxo. Se a API devolver uma resposta de falha, mas a aplicação marcar uma das contas como verificada, o caso falhou.
| Caso preparado | Resultado a verificar no servidor | Evidência necessária no produto |
|---|---|---|
| Token ausente | Não aprovar a propriedade do endereço | Conta pendente e fluxo tradicional iniciado, quando aplicável |
email diferente do cadastro |
Recusar a correspondência | Nenhuma conta errada marcada como verificada |
aud incompatível |
Recusar conforme a implementação | Registro correlacionado à solicitação correta |
nonce de outro formulário |
Recusar a associação de contexto | Cada conta conserva seu estado esperado |
iat ou exp fora da política |
Recusar o token | Motivo de validação identificável sem expor o token |
| Assinatura ou vínculo de chave inválidos | Não liberar a conta | Estado pendente e caminho de recuperação disponível |
A tabela é uma matriz de trabalho, não uma definição independente do protocolo. Confirme os detalhes das declarações e do processo de validação com a especificação da proposta WICG e com a documentação atual do verificador. Use dados de teste que permitam reproduzir cada cenário sem reutilizar tokens ou credenciais reais.
Cenário: falha na assinatura ou no Key Binding JWT
O teste de Key Binding JWT precisa demonstrar que a aplicação rejeita uma prova cuja assinatura ou vínculo de chave não passa pela validação esperada. Faça isso em um ambiente isolado, usando fixtures preparadas para teste ou uma implementação de teste que produza o resultado inválido de forma controlada. Não altere tráfego de usuários nem publique tokens de teste em registros compartilhados.
Mantenha evidências suficientes para investigar o resultado, sem registrar o conteúdo integral do token. Em geral, o registro de teste deve permitir relacionar a tentativa ao caso, identificar qual etapa de validação falhou e consultar o estado final da conta. Inclua o resultado do vínculo de chave e da validação do EVT de forma separada quando a sua implementação permitir. Assim, você não confunde uma assinatura rejeitada com uma falha posterior no processamento do cadastro.
A RFC 9901 sobre SD-JWT pode ajudar a equipe a entender o contexto técnico dos dados estruturados usados em tokens. Ela não substitui as instruções específicas da proposta de verificação de e-mail. Não extrapole uma regra da RFC para deduzir códigos de erro, comportamento de repetição ou política de replay que a documentação da API não tenha definido.
Cenário: emissor, descoberta ou chave pública não correspondem
Teste também a rejeição quando a identidade do emissor indicada no token não corresponde ao resultado da descoberta, ou quando os metadados e a chave pública não permitem concluir a validação prevista. O objetivo não é declarar que qualquer falha de consulta prova uma falsificação. É verificar que o servidor não aprova o endereço sem completar as verificações exigidas.
Separe dois resultados que podem parecer iguais no cadastro. Um é a rejeição protocolar: os dados não correspondem, ou a verificação criptográfica falha. Outro é uma indisponibilidade temporária: por exemplo, uma dependência de rede não respondeu. Sua política pode tratar ambos sem aprovar a conta, mas os registros devem ajudar a distinguir o motivo. Não atribua um erro isolado ao navegador ou ao provedor de e-mail sem evidência.
Use registros correlacionados para guardar o contexto da descoberta, a etapa que não pôde ser concluída e o estado final do cadastro. Não invente códigos de erro, número de tentativas ou tempos de espera como se fossem regras universais. Se sua aplicação aplicar uma política própria de indisponibilidade, documente-a como decisão do produto e teste-a separadamente do resultado de validação do token.
Valide o retorno ao e-mail com uma decisão condicional
Depois de exercitar os cenários de falha, escolha o próximo passo pelo resultado observado. Este é o critério de aceite para o seu fluxo:
- Se o token estiver ausente, inválido ou não puder ser validado, então rejeite a prova e mantenha a conta sem confirmação.
- Se a política do produto prevê confirmação tradicional nesses casos, então inicie esse processo e verifique que a mensagem corresponde ao ambiente e à conta do teste.
- Se a mensagem chegar, mas o link não atualizar o estado esperado, então a recuperação ainda não passou; investigue o processamento do link e a transição de estado.
- Se um serviço de validação estiver temporariamente indisponível, então não converta a indisponibilidade em propriedade comprovada. Aplique a política explícita do seu produto e deixe o cadastro em um estado seguro.
- Se o serviço exige um endereço duradouro, respostas por e-mail ou recuperação futura de conta, então prefira um endereço controlado de longo prazo, e não uma caixa temporária.
A confirmação por e-mail deve ser testada com uma caixa controlada no ambiente autorizado. Verifique o conteúdo, o endereço destinatário, a origem do ambiente e o link de confirmação. Abra o link dentro das condições de teste e confira a alteração de estado no aplicativo. Anote se a mensagem foi recebida e se o endereço foi recusado pelo seu sistema; isso documenta esta execução específica, não uma garantia de entrega em produção.
O recebimento de uma mensagem de teste demonstra que você conseguiu ler aquela mensagem no cenário executado. Não demonstra que a infraestrutura de produção sempre entregará mensagens, nem que todos os filtros externos aceitarão o destinatário. Para planejar a coleta de evidências, veja também como escolher um endereço para testes de cadastro e como pensar sobre a janela de recebimento de mensagens.
Faça o aceite sem confundir respostas técnicas e estado da conta
Antes de liberar a integração, execute os cenários da matriz e guarde resultados reproduzíveis. Para cada tentativa, anote o identificador do caso, o contexto da solicitação, a etapa de validação alcançada, a decisão do servidor, o estado da conta e o resultado do fluxo de recuperação. Evite conservar tokens completos, chaves privadas ou dados pessoais desnecessários. A evidência deve permitir auditoria sem criar um novo risco de exposição.
A resposta do servidor basta para aprovar o teste? Não. Uma resposta de rejeição pode coexistir com uma atualização incorreta no banco de dados ou com uma sessão autenticada já criada. Consulte a persistência e as permissões efetivas da conta. Da mesma forma, uma resposta tecnicamente bem-sucedida não comprova que a confirmação por e-mail foi entregue nem que o link alterou o estado correto.
Como confirmar que uma falha do Key Binding JWT não verificou a conta? Correlacione a tentativa com o registro da conta e confira o estado antes e depois. Teste também uma ação que exija a conta verificada. Se a tentativa inválida permitir essa ação, ou se o campo de verificação mudar, reprove o caso mesmo que a API tenha informado uma falha.
Como provar que o fallback por e-mail funciona? Confirme a decisão de iniciar a confirmação, leia a mensagem numa caixa de teste controlada e siga o link no mesmo ambiente. Em seguida, confira no aplicativo a transição esperada. Não considere apenas o envio registrado pelo servidor como recebimento confirmado.
Uma execução aprovada deve mostrar os três resultados, de forma independente: a prova inválida foi recusada; a conta não ganhou estado verificado indevidamente; e o caminho tradicional de confirmação foi exercitado quando a regra do produto exige esse retorno. Essa separação também facilita localizar regressões: uma falha pode estar na validação criptográfica, na lógica de cadastro, no envio da mensagem ou no processamento do link.
Atualização e escolha do endereço de teste
Última atualização: 28 de outubro de 2026. As referências oficiais consultadas descrevem o recurso como proposta no Chrome Origin Trial, indicam a validação de declarações, vínculo de chave e assinatura do EVT e orientam o retorno ao fluxo padrão quando o token falta ou uma verificação falha. A documentação registra atualização em 5 de outubro de 2026; confirme a página oficial da API antes de atualizar seus critérios, pois o protocolo está em evolução.
Para testar apenas um cadastro descartável ou receber uma mensagem de confirmação no seu próprio ambiente, o MyTempBox pode ser uma opção prática: você abre uma caixa sem criar uma conta, usa o endereço sem expor seu e-mail principal e evita misturar mensagens de teste à caixa de trabalho. Isso não garante que todo sistema aceite um endereço temporário, nem substitui um endereço duradouro para contas que exigem recuperação futura ou comunicação contínua. Se esse cenário combina com seu teste, você pode começar pelo MyTempBox.
Já confirmou que esta é uma tarefa curta e que pode ser refeita?
Abra uma caixa de entrada temporária e mantenha um único endereço até concluí-la. Se a tarefa se tornar permanente, migre primeiro o e-mail e só então encerre esta janela de recebimento.
Criar uma caixa de entrada descartável