Quando as Content Security Policies (CSP) foram lançadas, o escopo inicial foi pensado para mitigar Cross-Site Scripting (XSS) e injeções maliciosas no lado do cliente por meio de recursos carregados pelo cliente. Com o tempo, a CSP evoluiu e hoje conta com um total de 31 diretivas, com diferentes níveis de suporte entre os navegadores e 3 formatos distintos de relatório.
Esses cabeçalhos permitem que o proprietário de um site defina quais fontes são confiáveis para carregar JavaScript, fontes tipográficas, folhas de estilo ou iFrames. Também é possível definir conexões externas para exfiltração de dados. Uma CSP bem implementada pode prevenir comportamentos indesejados. Mas a CSP não é lá muito amigável e tem algumas falhas importantes — você pode ler sobre isso aqui.
Dito isso, uma extensão de navegador deveria ser capaz de remover esses cabeçalhos silenciosamente?
A lógica da especificação
"A política aplicada a um recurso não deve interferir no funcionamento de recursos do agente de usuário, como complementos, extensões ou bookmarklets. Esse tipo de recurso geralmente coloca a prioridade do usuário acima dos autores da página, conforme defendido em [HTML-DESIGN]."
Em termos simples: o seu navegador é o seu cliente. O seu cliente tem prioridade sobre a segurança da página que você visita. Isso faz sentido. Se não fosse assim, é provável que os navegadores fizessem isso de qualquer maneira. Hoje em dia, os navegadores podem simplesmente optar por não seguir as especificações. Uma especificação do W3C costuma ser vista como um objetivo final alcançado por meio de compromissos ao longo do caminho.
No entanto…
Todo mundo enxerga o problema aqui, certo?
Minha preocupação:
"Tudo bem, W3C, mas meu avô não saberia que, ao instalar uma extensão, está permitindo que ela remova recursos essenciais de segurança dos sites."
O problema vai além disso. Muitos navegadores atualizam extensões automaticamente, sem aprovação específica ou opt-in. Isso significa que uma extensão que funciona de um jeito hoje pode se comportar de forma completamente diferente amanhã, sem que você seja avisado.
Infelizmente, ao longo da minha carreira, percebi que as pessoas geralmente não pensam nos pais ou avós quando desenvolvem tecnologia. Algo ignorado inconscientemente, ou talvez outra coisa — um dia seremos velhos e nossos filhos poderão fazer o mesmo conosco. Por que somos assim?
Navegadores são máquinas de funcionalidades. Segurança é uma funcionalidade. Se preocupações sérias de segurança surgem, eventualmente algo é feito por pressão externa e comoção pública. Mas a prioridade continua sendo funcionalidades chamativas, e segurança simplesmente não é tratada como prioridade número 1.
Então, qual seria a solução?
Isso vai além do escopo do W3C, mas deveria fazer parte de um framework mais amplo de segurança de navegadores, incentivando uma postura autorregulada e consciente de segurança por parte das empresas que desenvolvem navegadores.
Fico me perguntando: por que não tornar isso um opt-in explícito?
Se uma extensão, na instalação ou na atualização, adicionar a funcionalidade de remover ou modificar cabeçalhos de segurança, o usuário deveria ser informado e precisaria aprovar esse comportamento.
Segurança no lado do cliente é um espaço de problemas interessante — o assunto acima é apenas um entre muitos que estão fundamentalmente mal implementados e representam riscos reais. Embora eu levante isso como uma questão no nível do W3C, trata-se, na prática, de um problema de segurança criado pelo próprio design dos navegadores.
Tem muito mais por vir. Proteja seus clientes, experimente o cside.
