Segurança¶
Este projeto é uma ponte de automação para navegadores. Considere-o como uma infraestrutura de execução de código confiável.
Segurança Gerenciada CDP¶
O CDP gerenciado está desativado por padrão. Ele fornece controle arbitrário do Chromium DevTools, não é uma ferramenta de navegador reduzida API. Ative-a apenas para clientes confiáveis. A capacidade em cloakbrowser_bridge_info.cdp.discoveryUrl é uma credencial de portador: não a registre, armazená-lo em tickets, ou compartilhá-lo entre sessões. Ele gira após a substituição do navegador e um velho URL nunca é movido para a geração de substituição.
Um bind CDP não-loopback requer tanto --cdp-allow-remote quanto um anunciado concreto host. Adicione controles de acesso à rede ao redor da porta publicada. Selecionando --cdp-advertised-scheme https não fornece TLS. O ouvinte gerenciado e Chromium hop permanece em texto simples; um terminador TLS de mesma porta de propriedade do operador deve preservar a autoridade anunciada Host e Origin e mantém o roteamento um-para-um para o sessão de posse.
Os logs de tempo de execução nunca incluem caminhos de capacidade, IDs de destino, cargas CDP, dados do navegador, cookies, valores crus Host ou Origin, ou caminhos de perfil. Verificações de segurança rejeitadas são relatado apenas como um aviso cdp_security_rejections com escopo de sessão com 60 segundos contagens de saturação para capability, host e origin; a limpeza libera qualquer restante contagens. Verificações bem-sucedidas não criam registros de auditoria por solicitação.
Limites Fixos¶
Os limites se aplicam independentemente a cada sessão CDP habilitada para MCP:
| Fronteira | Limite |
|---|---|
| Conexões WebSocket ativas e proxy, incluindo handshakes em andamento | 8 |
| Solicitações concorrentes de pré-atualização HTTP | 16 |
| Cabeçalhos da solicitação | 16 KiB |
| Corpo da requisição nas rotas suportadas | Não permitido |
| Resposta em buffer Chromium HTTP | 4 MiB |
| Mensagem WebSocket de entrada ou saída | 16 MiB |
| Dados WebSocket não enviados enfileirados por direção | 16 MiB |
| Cabeçalhos de solicitação, resposta upstream HTTP, ou handshake WebSocket | 10 segundos |
| Encerramento elegante do proxy antes do fechamento forçado | 5 segundos |
| Corpo de resposta de erro local | 8 KiB |
Erros HTTP¶
Falhas locais usam JSON {"error":{"code":"...","message":"..."}} com Cache-Control: no-store, Content-Type: application/json; charset=utf-8, e um exato Content-Length. Falhas de método também incluem Allow. Os mapeamentos estáveis são:
| Status | Código |
|---|---|
400 | bad_request |
403 | forbidden |
404 | not_found |
405 | method_not_allowed |
408 | request_timeout |
413 | payload_too_large |
431 | headers_too_large |
500 | internal_error |
502 | bad_gateway |
503 | unavailable |
504 | gateway_timeout |
Chromium 400..499 | upstream_error, preservando o status |
Chromium redirecionamentos, erros de servidor, respostas malformadas e falhas de transporte são normalizado em vez de expor corpos de resposta Chromium. Uma rejeição gerada por ponte antes que o despacho a montante tenha nenhum efeito colateral Chromium. Uma solicitação de descoberta somente leitura pode será tentado novamente após corrigir a condição. Para falhas ambíguas que alteram o estado, releia /json/list e reconcilie o estado do aplicativo; não assuma Retry-After ou idempotência automática.
WebSocket Fecha¶
Fechamentos gerados localmente usam pares redigidos fixos. Fechamentos válidos de pares são retransmitidos.
| Código | Razão | Usar |
|---|---|---|
1001 | going_away | Encerramento de sessão, geração ou proxy |
1002 | protocol_error | Entrada de protocolo WebSocket malformada |
1009 | message_too_big | Mensagem excede o limite configurado |
1011 | internal_error | Desconexão inesperada a montante ou falha de retransmissão |
1013 | try_again_later | Limite de fila não enviada por direção excedido |
Limite de confiança¶
O servidor externo oferece suporte a stdio e Streamable HTTP. Ele inicia o Playwright MCP (upstream) como um processo filho e encaminha as chamadas da ferramenta. A automação do navegador, a saída de arquivos, o acesso à rede e o comportamento de avaliação não segura são controlados pelo Playwright MCP (upstream).
Não exponha o servidor stdio por meio de um wrapper de rede não autenticado. Qualquer cliente capaz de chamar ferramentas pode controlar o navegador, ler dados da página acessíveis ao navegador e solicitar artefatos.
O Streamable HTTP se vincula ao 127.0.0.1 via HTTP por padrão para clientes locais. Se você o vincular ao 0.0.0.0 ou publicá-lo fora do loopback, exigirá CLOAK_PLAYWRIGHT_MCP_HTTP_AUTH_TOKEN ou autenticação de proxy reverso equivalente, use HTTPS direto com CLOAK_PLAYWRIGHT_MCP_HTTP_PROTOCOL=https e arquivos TLS ou termine a conexão TLS em uma borda de rede confiável e restrinja o acesso a clientes confiáveis.
Ferramentas perigosas¶
O Upstream Playwright MCP inclui ferramentas como browser_evaluate e browser_run_code_unsafe. Elas podem executar JavaScript no navegador ou no contexto do servidor do Playwright. Conecte este servidor apenas a clientes do MCP em que você confia.
As ferramentas webmcp_* são definidas pela página atual. Trate nome, descrição, schema, annotations e output como dados não confiáveis; a ponte os encaminha sem alterações. Use PLAYWRIGHT_MCP_WEBMCP=false quando a coleta não for necessária.
Token do Playwright Extension¶
Forneça PLAYWRIGHT_MCP_EXTENSION_TOKEN somente pelo ambiente do processo ou por um gerenciador de segredos. A ponte não aceita o token em metadata HTTP nem o grava em config, bridge metadata, logs, erros ou diagnostic snapshots. Proteja o persistent profile e não reutilize um userDataDir ativo entre sessões.
Configuração¶
Utilize opções de nível superior para controles de acesso e medidas de proteção:
PLAYWRIGHT_MCP_ALLOWED_ORIGINSPLAYWRIGHT_MCP_BLOCKED_ORIGINSPLAYWRIGHT_MCP_ALLOW_UNRESTRICTED_FILE_ACCESSPLAYWRIGHT_MCP_SECRETS_FILE
Essas são medidas de segurança de conveniência, não um substituto para o isolamento de processos, contêineres, redes e sistemas de arquivos.
Sempre que possível, utilize listas de permissão para destinos confiáveis. Trate o acesso irrestrito a arquivos e os arquivos de segredos como recursos confidenciais e mantenha-os fora dos perfis compartilhados de clientes MCP.
Modo Sandbox¶
A imagem do Docker é configurada por padrão como CLOAK_PLAYWRIGHT_MCP_NO_SANDBOX=true, pois o sandboxing do navegador frequentemente não está disponível em ambientes de execução de CI e MCP em contêineres. Trata-se de uma escolha de compatibilidade. Se o seu host e o ambiente de execução do contêiner suportarem o sandboxing do Chromium, defina:
Ao executar o programa sem a sandbox do Chromium, use o Docker ou outro mecanismo de isolamento de processos e evite montar diretórios amplos do host.
Artefatos e segredos¶
Capturas de tela, instantâneos, downloads, registros de rede, registros de console e rastreamentos podem conter credenciais ou conteúdo privado de páginas. Monte apenas o diretório de artefatos de que você precisa, limpe-o após o uso e evite compartilhar pacotes de artefatos publicamente.
Se o seu cliente MCP inserir credenciais nas sessões do navegador, dê preferência a credenciais de curta duração, restritas ao site de destino. Não inclua tokens de longa duração em capturas de tela, respostas de rede ou perfis persistentes do navegador.
Docker¶
O Docker é recomendado para isolamento e dependências reprodutíveis do navegador. Monte apenas o diretório de artefatos necessário; a imagem já inclui o Tini, que coleta corretamente os processos filhos do navegador. Em um contêiner reforçado e somente leitura, mantenha /data montado e forneça montagens temporárias graváveis em /tmp e /tmp/.X11-unix caso sejam possíveis sessões com interface gráfica.
Ao publicar um Streamable HTTP a partir do Docker, dê preferência a -p 127.0.0.1:3000:3000. A publicação direta em uma interface pública concede a qualquer navegador cliente acessível a capacidade de automação, a menos que você adicione autenticação e controles de rede.
A imagem do Docker é verificada com o Trivy na integração contínua (CI) e antes da publicação da versão. O verificador analisa vulnerabilidades de alto risco e críticas no sistema operacional e nas bibliotecas e, quando ativado, envia os resultados SARIF para a verificação de código do GitHub.
Verificações da cadeia de suprimentos¶
O repositório utiliza verificações gratuitas, nativas do GitHub e de código aberto:
- CodeQL para análise estática de JavaScript e TypeScript.
- Dependency Review para alterações de dependências em pull requests.
npm audit --omit=dev --audit-level=highpara dependências do npm em tempo de execução.- OpenSSF Scorecard para sinais da cadeia de suprimentos do repositório.
- zizmor para verificação de segurança no GitHub Actions.
- Trivy para varredura de vulnerabilidades em imagens do Docker.
Essas verificações não substituem a análise manual do comportamento da automação do navegador nem das alterações de versão.
Relatórios¶
Relate vulnerabilidades usando SECURITY.md.