BurnAfterRead: O Serviço Zero-Knowledge Onde o Servidor Não Vê a Chave
Descubra como o BurnAfterRead, um serviço de compartilhamento de dados efêmero e criptografado de ponta a ponta, garante que nem mesmo o servidor tenha acesso às chaves de descriptografia, utilizando uma arquitetura serverless e a Web Crypto API.
MundiX News·01 de julho de 2026·7 min de leitura·👁 1 views
A necessidade de compartilhar informações sensíveis, como senhas, chaves de API ou configurações, de forma segura e efêmera é uma tarefa comum no ambiente corporativo. Soluções existentes muitas vezes exigem confiança em código fechado, a manutenção de servidores próprios ou complexos processos de registro. Para atender a essa demanda com código aberto, criptografia realizada diretamente no navegador e a garantia de que o servidor nunca terá acesso ao conteúdo, surgiu o BurnAfterRead. Este serviço inovador utiliza Cloudflare Workers para oferecer compartilhamento de dados autodestrutivos e criptografados de ponta a ponta (E2E).
A arquitetura do BurnAfterRead é totalmente serverless, aproveitando ao máximo os serviços da Cloudflare. O sistema é composto por Cloudflare Workers para a API HTTP e distribuição de conteúdo estático, Cloudflare D1 (SQLite) para o armazenamento de metadados como ID, tempo de vida (TTL) e contador de visualizações, e Cloudflare R2 para o armazenamento dos dados criptografados. A coordenação atômica do acesso aos dados é gerenciada por Durable Objects, enquanto o frontend, construído em React, utiliza a Web Crypto API para realizar todo o processo de criptografia no navegador do usuário. Essa abordagem elimina a necessidade de servidores dedicados e bancos de dados tradicionais, distribuindo a carga para a borda da rede da Cloudflare.
A pedra angular do BurnAfterRead é o seu modelo zero-knowledge, onde o servidor jamais tem acesso à chave de descriptografia. O processo inicia com o navegador gerando uma chave AES-GCM de 256 bits. O conteúdo (texto ou arquivo) é então criptografado com essa chave e um vetor de inicialização (IV) aleatório de 12 bytes. Apenas o texto cifrado (ciphertext) é enviado ao servidor. A chave de descriptografia é incorporada à URL como um fragmento (URL fragment), na forma https://burnafterread.casablanque.com/d/AbCdEf#k=<chave-base64url>. Conforme especificado na RFC 9110, fragmentos de URL nunca são enviados ao servidor em requisições HTTP, garantindo que a chave permaneça inacessível para a infraestrutura do serviço. A criptografia AES-GCM foi escolhida não apenas pela confidencialidade, mas também pela autenticação que oferece, garantindo a integridade dos dados através de um auth tag de 16 bytes. Qualquer tentativa de adulteração dos dados cifrados será detectada durante a descriptografia.
Para garantir a atomicidade das operações, especialmente em cenários de acesso simultâneo, o serviço emprega Durable Objects. Um objeto chamado DropAccessCoordinator gerencia a lógica de consumo dos dados. Utilizando blockConcurrencyWhile, ele assegura que operações como verificação de TTL, decremento do contador de visualizações e recuperação dos dados do R2 sejam executadas de forma serializada e atômica para um determinado 'drop'. Isso previne condições de corrida onde múltiplos acessos simultâneos poderiam violar a garantia de uso único. O modo 'Paranoid' eleva a segurança ao retornar sempre 'not_found', independentemente do status do 'drop', eliminando ataques de timing oracle. Adicionalmente, um endpoint de revogação permite ao remetente invalidar um 'drop' antes que ele seja acessado, utilizando um token secreto cujo hash é armazenado no D1. Para usuários que buscam o máximo de privacidade, um CLI (Command Line Interface) foi desenvolvido, permitindo o envio e recebimento de dados sem a exposição da chave no navegador, utilizando a biblioteca node:crypto para descriptografia.
A segurança é reforçada com headers de segurança robustos, incluindo uma Content-Security-Policy (CSP) estrita para prevenir ataques XSS e garantir que apenas scripts confiáveis sejam executados. A política Referrer-Policy: no-referrer adiciona uma camada extra de privacidade, impedindo que o URL da página com o 'drop' seja enviado em requisições subsequentes. O controle de taxa (rate limiting) é implementado através de outro Durable Object, simulando uma janela deslizante para limitar requisições por IP. Uma página de demonstração interativa na seção /security permite aos usuários testar a criptografia, a integridade do AES-GCM e entender como descriptografar os dados manualmente via Node.js, com links diretos para o código-fonte. O projeto, que está em constante desenvolvimento, planeja futuras funcionalidades como notificações de abertura, proteção por senha adicional e API keys para integrações.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
A necessidade de compartilhar informações sensíveis, como senhas, chaves de API ou configurações, de forma segura e efêmera é uma tarefa comum no ambiente corporativo. Soluções existentes muitas vezes exigem confiança em código fechado, a manutenção de servidores próprios ou complexos processos de registro. Para atender a essa demanda com código aberto, criptografia realizada diretamente no navegador e a garantia de que o servidor nunca terá acesso ao conteúdo, surgiu o BurnAfterRead. Este serviço inovador utiliza Cloudflare Workers para oferecer compartilhamento de dados autodestrutivos e criptografados de ponta a ponta (E2E).
A arquitetura do BurnAfterRead é totalmente serverless, aproveitando ao máximo os serviços da Cloudflare. O sistema é composto por Cloudflare Workers para a API HTTP e distribuição de conteúdo estático, Cloudflare D1 (SQLite) para o armazenamento de metadados como ID, tempo de vida (TTL) e contador de visualizações, e Cloudflare R2 para o armazenamento dos dados criptografados. A coordenação atômica do acesso aos dados é gerenciada por Durable Objects, enquanto o frontend, construído em React, utiliza a Web Crypto API para realizar todo o processo de criptografia no navegador do usuário. Essa abordagem elimina a necessidade de servidores dedicados e bancos de dados tradicionais, distribuindo a carga para a borda da rede da Cloudflare.
A pedra angular do BurnAfterRead é o seu modelo zero-knowledge, onde o servidor jamais tem acesso à chave de descriptografia. O processo inicia com o navegador gerando uma chave AES-GCM de 256 bits. O conteúdo (texto ou arquivo) é então criptografado com essa chave e um vetor de inicialização (IV) aleatório de 12 bytes. Apenas o texto cifrado (ciphertext) é enviado ao servidor. A chave de descriptografia é incorporada à URL como um fragmento (URL fragment), na forma https://burnafterread.casablanque.com/d/AbCdEf#k=<chave-base64url>. Conforme especificado na RFC 9110, fragmentos de URL nunca são enviados ao servidor em requisições HTTP, garantindo que a chave permaneça inacessível para a infraestrutura do serviço. A criptografia AES-GCM foi escolhida não apenas pela confidencialidade, mas também pela autenticação que oferece, garantindo a integridade dos dados através de um auth tag de 16 bytes. Qualquer tentativa de adulteração dos dados cifrados será detectada durante a descriptografia.
Para garantir a atomicidade das operações, especialmente em cenários de acesso simultâneo, o serviço emprega Durable Objects. Um objeto chamado DropAccessCoordinator gerencia a lógica de consumo dos dados. Utilizando blockConcurrencyWhile, ele assegura que operações como verificação de TTL, decremento do contador de visualizações e recuperação dos dados do R2 sejam executadas de forma serializada e atômica para um determinado 'drop'. Isso previne condições de corrida onde múltiplos acessos simultâneos poderiam violar a garantia de uso único. O modo 'Paranoid' eleva a segurança ao retornar sempre 'not_found', independentemente do status do 'drop', eliminando ataques de timing oracle. Adicionalmente, um endpoint de revogação permite ao remetente invalidar um 'drop' antes que ele seja acessado, utilizando um token secreto cujo hash é armazenado no D1. Para usuários que buscam o máximo de privacidade, um CLI (Command Line Interface) foi desenvolvido, permitindo o envio e recebimento de dados sem a exposição da chave no navegador, utilizando a biblioteca node:crypto para descriptografia.
A segurança é reforçada com headers de segurança robustos, incluindo uma Content-Security-Policy (CSP) estrita para prevenir ataques XSS e garantir que apenas scripts confiáveis sejam executados. A política Referrer-Policy: no-referrer adiciona uma camada extra de privacidade, impedindo que o URL da página com o 'drop' seja enviado em requisições subsequentes. O controle de taxa (rate limiting) é implementado através de outro Durable Object, simulando uma janela deslizante para limitar requisições por IP. Uma página de demonstração interativa na seção /security permite aos usuários testar a criptografia, a integridade do AES-GCM e entender como descriptografar os dados manualmente via Node.js, com links diretos para o código-fonte. O projeto, que está em constante desenvolvimento, planeja futuras funcionalidades como notificações de abertura, proteção por senha adicional e API keys para integrações.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.