Usos autorizados de navegadores multiperfil em QA, agências e segurança

Regra essencial: separe trabalho que já é permitido

Um perfil do navegador pode manter cookies, armazenamento, histórico, extensões, permissões e configurações separados de outro contexto de trabalho. Essa separação é útil quando a atividade subjacente é autorizada. Não concede direitos sobre uma conta, um serviço, uma rede, uma pessoa ou um conjunto de dados.

Antes de criar um perfil, torne explícita a cadeia de autorização:

Pergunta	Provas a conservar
Quem é proprietário do sistema ou da conta?	Organização identificada e contato responsável
Quem autorizou o trabalho?	Contrato, declaração de trabalhos, pedido, plano de testes ou regras de execução do teste
Que recursos e contas estão abrangidos?	Ambientes, origens, IDs de contas, IDs de perfis e exclusões exatos
Que ações são permitidas?	Ler, publicar, testar, repor, convidar, exportar, automatizar ou outras operações indicadas
Que dados podem ser usados?	Classificações de dados sintéticos, de teste, fornecidos pelo cliente, pessoais, confidenciais e de retenção
Quando se aplica a autorização?	Início, validade, janela de manutenção e caminho de revogação
O que exige aprovação?	Ações externamente visíveis, destrutivas, em massa, que alterem acessos ou gerem custos
Quando deve o trabalho parar?	Incerteza de escopo, dados inesperados, impacto no serviço, acesso revogado ou resultado desconhecido

O acesso técnico não prova a autorização. Uma sessão guardada pode continuar a funcionar depois de um membro sair da equipe ou de um cliente terminar a colaboração. O operador tem de parar quando a autoridade é retirada, mesmo que o navegador ainda consiga abrir a conta.

Um padrão operacional compartilhado

As mesmas cinco etapas tornam responsáveis diferentes fluxos multiperfil.

1. Autorizar

Identifique o proprietário do sistema, o cliente quando aplicável, os operadores, a finalidade permitida, os recursos, as contas, as ações, as datas, o tratamento dos dados, as aprovações e as condições de parada. Um cliente pode autorizar trabalho nos recursos que controla; não pode conceder direitos que não possui sobre outro serviço.

2. Preparar

Crie um perfil para o ambiente, cliente, função ou caso de teste específico. Aplique apenas as extensões, o proxy, a configuração regional, as permissões e as credenciais necessárias. Prefira a delegação suportada pelo serviço e contas individuais ao compartilhamento de senhas ou à cópia de material de sessão.

3. Executar

Use um operador ou carga de trabalho responsável de cada vez para estado mutável. Imponha limites de escopo, destino, simultaneidade, ritmo e custos. Pré-visualize alterações de alto impacto e vincule a aprovação ao destino e à ação exatos.

4. Registrar

Registre o interveniente, a carga de trabalho delegada, a referência do perfil, a ação, a aprovação, a hora, o destino, o resultado e as versões relevantes. As orientações da OWASP sobre registros recomendam capturar quando, onde, quem e o quê, protegendo os registros e excluindo segredos técnicos. Mantenha cookies em bruto, senhas, tokens, credenciais de proxy, conteúdo das páginas e dados pessoais desnecessários fora dos registros atuais.

5. Recuperar e encerrar

Pare o perfil corretamente, verifique o estado esperado, conserve apenas as provas aprovadas, revogue o acesso temporário e devolva o perfil ao respectivo proprietário. Se a execução terminar num estado desconhecido, investigue antes de tentar novamente. Restaure uma cópia em bom estado conhecida ou coloque em quarentena o estado danificado, em vez de continuar silenciosamente.

Equipes de QA e localização

Limites de perfil úteis

As equipes de QA podem usar perfis separados para:

• estados anônimo, com sessão iniciada e recém-registrado;
• funções de administrador, editor, apoio e usuário comum;
• desenvolvimento, pré-produção e testes rápidos de produção expressamente aprovados;
• combinações de configuração regional, idioma, fuso horário, esquema de cores e permissões;
• configurações com e sem extensões;
• um estado limpo de primeira execução e um estado persistente atualizado deliberadamente; e
• participantes em paralelo num cenário aprovado com vários usuários.

O Playwright utiliza contextos isolados do navegador para que os testes recebam cookies, armazenamento local e armazenamento de sessão separados, e suporta vários contextos em cenários com vários usuários. A respectiva documentação sobre contextos do navegador também explica por que razão o isolamento com estado limpo reduz a propagação de falhas. Este é um padrão de teste útil, mas um perfil persistente de produto e um contexto temporário de automação podem conservar estado diferente. Registre qual deles o teste utiliza efetivamente.

Testes regionais e de localização

Uma matriz de localização repetível pode variar a configuração regional declarada, o fuso horário, a janela de visualização, o método de introdução, a direção do texto e os dados de teste. O Playwright documenta a emulação da configuração regional, do fuso horário, da geolocalização, do esquema de cores e de outras configurações de contexto no respectivo guia de emulação. Trate a emulação como uma entrada controlada, não como prova de que o teste representa todos os dispositivos, redes, regiões jurídicas ou experiências reais dos usuários.

Use um proxy ou uma entrada de geolocalização apenas quando o proprietário da rede, o serviço de destino e o acordo de testes o permitirem. Alterar o caminho de rede não cria o direito a conteúdo limitado a uma região nem a contornar uma decisão de acesso do serviço.

As sugestões rápidas de internacionalização do W3C recomendam UTF-8, idioma declarado do documento, formatos de dados locais, navegação visível entre idiomas, direção apropriada do texto da direita para a esquerda e validação. Converta estes princípios em verificações observáveis, por exemplo:

• o idioma escolhido sobrevive à navegação e a uma nova autenticação;
• datas, horas, números, nomes, endereços, ordenação e plurais utilizam a configuração regional pretendida;
• o texto traduzido pode expandir-se sem ser truncado nem ocultar controles;
• o conteúdo multilingue e da direita para a esquerda preserva a ordem de leitura e de foco;
• os formulários aceitam e devolvem os conjuntos de caracteres pretendidos; e
• as conexões e as mensagens de erro permanecem compreensíveis sem depender de tradução automática.

Testes de acessibilidade

Mantenha separados os estados de acessibilidade quando isso melhorar a reprodutibilidade, mas não reduza a acessibilidade a uma preconfiguração do perfil. Teste o teclado, o foco, a ampliação, os leitores de tela, as preferências de contraste, o movimento reduzido, os erros e a autenticação acessível segundo as WCAG 2.2. A visão geral da avaliação do W3C afirma que as ferramentas ajudam, mas nenhuma consegue determinar, por si só, se um site é acessível; continua a ser necessária uma avaliação humana informada.

Manual de QA: verificação de uma versão regional

Autorização: o proprietário do produto aprova a origem de pré-produção, duas funções de teste, as configurações regionais suportadas, as datas dos testes e as contas sintéticas.

Perfis: um perfil limpo por par de função e configuração regional, acrescido de um perfil de atualização separado que conserva o estado da versão anterior.

Ações: autenticar através do caminho de teste suportado, executar verificações de navegação e formulários, inspecionar o comportamento do idioma e da acessibilidade, capturar artefatos de teste aprovados e parar corretamente cada perfil.

Provas: ID da compilação, versão do navegador, entradas de configuração regional e fuso horário, função, resultado do teste, detalhes ocultados dos erros e referências dos artefatos.

Condições de parada: origem de produção inesperada, dados reais de clientes, permissão fora da função atribuída, degradação do serviço ou pedido de exportação do estado de uma sessão ativa.

Agências e operações de clientes

Limites de perfil úteis

As agências podem separar o trabalho por cliente, entidade jurídica, marca, ambiente, serviço de destino e função do operador. Isto pode reduzir ações acidentais entre clientes e tornar as transferências mais claras. O limite mais forte combina a separação de perfis com as funções de organização, permissões e acesso delegado do próprio serviço de destino.

Um fluxo de agência deve ter:

• uma autorização atual do cliente e um responsável identificado no cliente;
• um usuário ou uma função delegada suportada pelo serviço para cada operador, quando disponível;
• um proprietário do perfil e um estado de transferência registrado;
• pastas, etiquetas, extensões, proxies e regras de retenção específicas do cliente;
• aprovação para publicação, alterações de acesso, ações em massa, eliminação e despesas;
• um registro de auditoria visível para o cliente ou titular da conta adequado;
• um processo rápido para revogação, perda do dispositivo, alterações de pessoal e termo do contrato; e
• um plano de exportação e eliminação acordado antes da integração.

Evite compartilhar credenciais em bruto como mecanismo de colaboração. Quando as ferramentas de teste ou automação guardarem estado autenticado, proteja-o como uma credencial. As orientações do Playwright sobre autenticação avisam que o estado guardado do navegador pode conter cookies e cabeçalhos capazes de representar a conta e não deve ser integrado em repositórios.

Manual de agência: transferência aprovada de conteúdo

Autorização: a declaração de trabalhos identifica o sistema de conteúdos controlado pelo cliente, a marca, os operadores, as operações de conteúdo permitidas, o responsável pela aprovação e a data de termo da colaboração.

Perfis: um espaço de trabalho do cliente com perfis separados de editor e publicador. Cada operador utiliza uma identidade individual no serviço; o perfil de publicador não é um cofre compartilhado de senhas.

Ações: o editor prepara um rascunho, o sistema registra uma pré-visualização e a revisão do conteúdo, o aprovador identificado do cliente aceita a revisão exata e o publicador envia-a uma vez.

Provas: interveniente, cliente, perfil, revisão do conteúdo, referência da aprovação, destino, resultado do envio e hora. Os valores do conteúdo só são conservados quando o acordo com o cliente e a política de dados o permitirem.

Recuperação: se a resposta se perder após o envio, verifique o sistema de destino antes de tentar novamente. Se a colaboração terminar, revogue o acesso, devolva os registros aprovados e elimine ou conserve os restantes dados dos perfis segundo o acordo.

Limites que continuam proibidos

O trabalho de clientes não justifica:

• criar contas, avaliações, interações ou identidades falsas;
• enviar spam ou mensagens não solicitadas em massa;
• acessar uma conta depois de o cliente ou o proprietário do serviço retirar a autorização;
• comprar, coletar, repetir ou compartilhar credenciais ou sessões roubadas;
• ocultar quem realizou uma ação perante uma investigação autorizada;
• contornar a aplicação das regras da plataforma para restaurar acesso proibido; ou
• operar fora dos direitos do cliente, da lei aplicável ou dos termos do serviço.

Se uma plataforma rejeitar uma ação, investigue a autorização e o processo de trabalho. Não trate um perfil, proxy ou caminho de automação como autorização para contornar a decisão.

Equipes de segurança e resposta a incidentes

O escopo escrito vem primeiro

As equipes de segurança precisam de mais do que um pedido geral para «testar o site». O NIST SP 800-115 fornece orientações para planejar e realizar testes técnicos de segurança, analisar resultados e desenvolver medidas de mitigação. O NIST define regras de execução do teste como restrições estabelecidas antes dos testes que dão à equipe autoridade para realizar atividades definidas.

As regras de execução do teste devem identificar:

• anfitriões, aplicativos, APIs, inquilinos e contas exatos abrangidos;
• serviços de terceiros e dependências de produção expressamente excluídos;
• técnicas e ferramentas permitidas;
• redes ou dispositivos de origem dos testes, quando relevante;
• limites de calendário, ritmo, simultaneidade e impacto no serviço;
• contas de teste, funções e dados aprovados;
• ações proibidas, como persistência, engenharia social, alterações destrutivas ou negação de serviço;
• tratamento, criptografia, acesso, retenção e destruição das provas;
• contatos de incidentes e de emergência;
• condições de parada imediata; e
• expectativas de relatórios, correções, novos testes e divulgação.

Se a demonstração exigir acesso ou impacto além de destas regras, pare e obtenha autorização escrita antes de continuar.

Limites de perfil úteis

Numa avaliação autorizada, os perfis separados podem isolar:

• o cliente A do cliente B;
• as identidades dos responsáveis pelos testes da navegação pessoal comum;
• cada função ou inquilino de teste;
• a validação passiva dos testes ativos aprovados;
• uma linha de base limpa de um estado de teste alterado;
• as provas de resposta a incidentes do trabalho operacional em curso; e
• o estado de um novo teste do resultado original.

Use os perfis para proteger o escopo e as provas, não para ocultar a origem ou a finalidade dos testes. Não alterne entre perfis, redes ou identidades para contornar limites de ritmo, bloqueios ou outros controles, salvo se o proprietário do sistema tiver incluído expressamente esse comportamento nas regras de execução do teste.

Manual de segurança: regressão autorizada do controle de acesso

Autorização: o proprietário do sistema indica o aplicativo de pré-produção, dois inquilinos de teste, funções normais e de administrador, pedidos permitidos, limite de ritmo, janela e contato de emergência. A produção e a infraestrutura de identidade de terceiros estão excluídas.

Perfis: um perfil limpo para cada função e inquilino aprovados. Cada um contém dados sintéticos de teste e uma identidade de teste emitida pelo serviço.

Ações: verifique que cada função consegue acessar os recursos esperados e, depois, execute os casos negativos aprovados que confirmam que as restantes funções e inquilinos recebem uma recusa. Use o número mínimo de pedidos necessário para reproduzir um resultado.

Provas: versões do aplicativo e do navegador, caso de teste, interveniente, referências do inquilino e da função, IDs de correlação dos pedidos, provas ocultadas da resposta, hora e resultado. Não conserve registros não relacionados encontrados durante os testes.

Condições de parada: aparecem dados pessoais ou de produção, o serviço fica instável, um teste sai do inquilino indicado, são expostas credenciais fora do conjunto de teste ou o proprietário retira a autorização.

Recuperação: pare os pedidos ativos, notifique o contato indicado, conserve as provas mínimas e protegidas, revogue as credenciais de teste, restaure o estado de teste e documente se é seguro repetir o teste.

A autorização tem várias camadas

Use esta tabela de decisão quando a autorização não for clara:

Situação	Decisão
A empresa é proprietária do sistema de pré-produção, o plano de testes identifica a conta e as ações e o operador possui a função atribuída	Prosseguir dentro dos limites documentados
Um cliente pede a uma agência que gerencia uma conta através das funções suportadas pelo serviço e o contrato abrange o trabalho	Prosseguir com acesso nominal, aprovação, auditoria e controles de saída
Um cliente pede acesso a uma conta de terceiros que não possui nem controla	Parar; o cliente não pode conceder essa autorização
Um contato de segurança manifesta incentivo geral, mas não fornece uma lista de recursos nem um escopo de testes	Parar; obter regras de execução do teste por escrito
Uma sessão válida permanece depois de uma pessoa sair da equipe	Parar e revogá-la; o acesso técnico sobreviveu à autorização
Um teste encontra credenciais reais ou dados pessoais fora do conjunto aprovado	Parar, minimizar o acesso, proteger as provas e notificar o contato indicado
Uma plataforma bloqueia uma ação e a resposta proposta é mudar de perfis ou proxies	Parar; não usar o isolamento para contornar a aplicação das regras
Um fluxo cria interações falsas, spam, fraude, phishing, roubo de credenciais ou acesso não autorizado	Proibido

O que a separação de perfis não consegue estabelecer

Um limite de perfil pode reduzir a mistura acidental de estado. Não consegue, por si só, provar que:

• o operador está autorizado;
• a identidade da conta é genuína;
• o navegador representa um dispositivo físico separado;
• uma configuração regional simulada representa um residente ou um direito regional legítimo;
• um proxy autoriza o acesso a partir da localização aparente;
• as extensões ou o endpoint são confiáveis;
• um site aceitará a sessão; ou
• um teste de segurança está dentro do escopo.

Trate o perfil como um controle dentro de um sistema mais amplo de identidade, autorização, tratamento de dados, auditoria, recuperação, contratos e revisão humana. Quando qualquer destas camadas deixar de ser clara, uma operação segura significa parar e resolver a ambiguidade antes de continuar.