Segurança Web: compreender as proteções essenciais de um site

A segurança Web não é uma única opção que se ativa uma vez para sempre. Assenta em várias camadas, cada uma destinada a reduzir uma família de riscos: transporte cifrado, controlo dos recursos carregados, limitação das capacidades do navegador, autenticação e verificação de integridade.

Pensar em camadas

HTTPS protege o transporte entre o navegador e o servidor, mas não corrige uma aplicação vulnerável. Uma CSP pode limitar o impacto de algumas injeções, mas não substitui escaping e validação. Uma palavra-passe robusta não compensa uma má gestão de sessão.

Uma defesa coerente combina, por isso:

• HTTPS para cifrar os dados em trânsito;
• cabeçalhos HTTP de segurança para dar regras explícitas ao navegador;
• CSP para controlar as origens autorizadas de scripts, estilos, imagens e ligações;
• SRI para verificar a integridade esperada de recursos externos;
• autenticação e sessões para controlar o acesso;
• hashes para comparar integridade e impressões digitais sem os confundir com cifragem.

Segurança e privacidade não são sinónimos

Um site pode estar bem protegido contra muitos ataques e ainda assim recolher muitos dados. No sentido inverso, uma aplicação Local First pode limitar transferências de ficheiros e continuar a precisar das boas práticas Web clássicas.

A segurança procura impedir ações não autorizadas; a privacidade procura também limitar a exposição e utilização dos dados. Os dois objetivos complementam-se, mas não se substituem.

Começar por um modelo de ameaça simples

Antes de escolher uma proteção, pergunte o que pretende impedir. Um site institucional, uma aplicação com contas e um back-office não apresentam os mesmos riscos. Identifique dados sensíveis, ações que exigem autenticação, recursos de terceiros, páginas integráveis em iframes e APIs acessíveis pelo navegador.

Esta análise evita instalar mecanismos sem compreender o seu papel e evita também assumir que um site “pequeno” não tem nada para proteger.

HTTPS é a base, não toda a segurança

HTTPS cifra as trocas e permite ao navegador verificar a identidade do servidor através do certificado. Contudo, não corrige XSS, autorizações mal concebidas, palavras-passe comprometidas ou dependências JavaScript perigosas.

Quando HTTPS está corretamente implementado em todo o domínio, HSTS pode pedir ao navegador que privilegie de forma persistente a ligação segura.

Reduzir a superfície de ataque

Remova dependências que já não utiliza, limite permissões dadas a iframes e APIs do navegador, não coloque segredos no código cliente e mantenha os componentes atualizados.

Cada script de terceiros executado numa página aumenta aquilo de que depende. CSP ajuda a controlar as origens permitidas e SRI pode validar o conteúdo esperado de determinados recursos estáticos.

Autenticação, autorização e sessão

São assuntos diferentes. A autenticação responde a “quem é?”, a autorização a “tem permissão?”, e a sessão define como essa identidade é mantida entre pedidos.

Um JWT pode participar nesta arquitetura, mas não substitui os controlos de autorização. Da mesma forma, uma palavra-passe forte não protege uma rota do servidor que se esquece de verificar permissões.

Testar as proteções como comportamentos

A segurança não se valida apenas lendo configurações. Verifique os cabeçalhos realmente recebidos, erros CSP, carregamentos externos, rotas acessíveis sem autenticação e o comportamento depois de uma sessão expirar.

Uma proteção declarada mas nunca aplicada é apenas decorativa. Documentar decisões importantes - por exemplo, porque uma origem é permitida numa CSP - facilita futuras alterações e evita que as exceções se acumulem sem controlo.

Para compreender a relação entre fluxos de autorização, tokens e chaves públicas, continue com OAuth 2.0, PKCE, JWT, JWK e JWKS. Para escolher entre confidencialidade, integridade e autenticação, consulte Criptografia, hashing e HMAC.