GitHub

Quem está começando a desenvolver para a web costuma imaginar segurança como algo que se adiciona no fim: um antivírus, um firewall, um plugin. É uma imagem confortável e completamente errada. Segurança não é uma peça que se encaixa no produto pronto, é uma propriedade da forma como o produto foi construído.

A diferença é fundamental. Uma aplicação web é como uma casa. Você não torna uma casa segura instalando uma fechadura cara na porta da frente se as paredes são de papelão e as janelas não fecham. Segurança vem da estrutura, não de um acessório colado por cima.

Este artigo explica, sem assumir conhecimento prévio, como a arquitetura de uma aplicação web determina sua segurança. É para iniciantes que querem entender os fundamentos certos desde o começo, antes de pegar vícios que custam caro para desfazer depois.

A anatomia de uma aplicação web

Para falar de segurança, primeiro é preciso entender as partes. Uma aplicação web tem, simplificadamente, três camadas, e cada uma tem seu papel na segurança.

O cliente é o que roda no navegador do usuário: as telas, os botões, o que a pessoa vê e toca. O servidor é onde a lógica de verdade acontece, longe dos olhos do usuário. E o banco de dados é onde as informações ficam guardadas.

Entre essas camadas, os dados viajam pela rede. Essa estrutura simples já contém a lição de segurança mais importante para iniciantes, e é por ela que vamos começar.

A regra de ouro: nunca confie no cliente

Se você guardar apenas um princípio deste artigo, guarde este: tudo o que roda no navegador do usuário está sob o controle do usuário, e portanto pode ser manipulado. O cliente é território inimigo.

Iniciantes cometem o erro de colocar verificações de segurança no cliente. Validam o formulário no navegador, escondem um botão de quem não tem permissão, conferem se o valor é válido na tela. Tudo isso é bom para a experiência do usuário, e absolutamente inútil como segurança. Um atacante simplesmente ignora a tela e fala direto com o servidor, enviando o que quiser.

A consequência arquitetural é clara: toda decisão de segurança precisa ser tomada no servidor. Validação de dados, verificação de permissão, regras de negócio, tudo isso vive no servidor, onde o usuário não alcança. O cliente sugere; o servidor decide. Essa separação é a espinha dorsal da segurança web.

Os dois pilares: quem você é e o que você pode

Praticamente toda segurança de aplicação se apoia em dois conceitos que iniciantes costumam confundir.

Autenticação é provar quem você é. É o login: usuário e senha, talvez um segundo fator. Responde à pergunta "você é mesmo quem diz ser?".

Autorização é definir o que você pode fazer depois de identificado. Responde à pergunta "você tem permissão para isto?".

A confusão entre os dois gera uma das falhas mais comuns que existe. Um sistema confirma o login (autenticação) mas esquece de verificar, em cada ação, se aquele usuário tem direito àquele dado (autorização). O resultado é o ataque clássico de trocar um número na URL e acessar informações de outra pessoa, uma falha que está no topo das listas da OWASP há anos.

Na arquitetura, isso significa duas verificações distintas. Confirmar a identidade na entrada não basta. É preciso verificar a permissão a cada acesso a um recurso. Esquecer a segunda é como conferir o crachá de quem entra no prédio mas deixar todas as salas destrancadas.

Protegendo os dados em trânsito e em repouso

Os dados de uma aplicação existem em dois estados, e ambos precisam de proteção.

Em trânsito é quando os dados viajam entre o cliente e o servidor pela rede. Aqui, a proteção é a criptografia da comunicação, via HTTPS. Sem isso, qualquer pessoa numa rede compartilhada, um Wi-Fi público, por exemplo, pode interceptar e ler o que trafega, incluindo senhas. HTTPS hoje é padrão básico e não negociável.

Em repouso é quando os dados estão guardados no banco. A proteção mais crítica para iniciantes entenderem é o tratamento de senhas: elas jamais devem ser guardadas como o usuário digitou. Passam por um processo chamado hash, que as transforma em algo irreversível. Assim, mesmo que o banco vaze, as senhas não são legíveis. Guardar senha em texto puro é, talvez, o pecado mortal mais comum de iniciantes.

As ameaças clássicas que a arquitetura previne

Algumas categorias de ataque são tão comuns que todo iniciante deveria conhecê-las pelo nome. Elas aparecem na lista da OWASP, a referência mundial de riscos de aplicações web.

Injeção acontece quando dados enviados pelo usuário são interpretados como comandos pelo sistema. O caso clássico é a injeção de SQL, em que um campo de formulário é usado para enganar o banco de dados. A defesa arquitetural é nunca misturar dados do usuário com comandos diretamente, sempre tratando a entrada como dado, nunca como instrução.

Cross-site scripting (XSS) ocorre quando código malicioso enviado por um usuário acaba executando no navegador de outro. A defesa é tratar e escapar tudo o que vem de fora antes de exibir na tela.

O padrão comum a essas ameaças é o mesmo princípio de antes: dados vindos de fora não são confiáveis e precisam ser validados e tratados no servidor antes de qualquer uso. A arquitetura segura é, em boa medida, a arquitetura que desconfia sistematicamente da entrada.

A reflexão para quem está começando

A armadilha mental mais perigosa do iniciante é "meu projeto é pequeno demais para ser atacado". É exatamente o contrário. A maioria dos ataques não escolhe alvos, são robôs automatizados varrendo a internet em busca de falhas conhecidas. Um projeto pequeno e mal protegido é justamente o alvo mais fácil para essas varreduras. Ninguém precisa querer atacar você; basta uma porta aberta encontrada por acaso.

Há também a dimensão legal que iniciantes ignoram. No Brasil, a LGPD responsabiliza quem coleta dados de pessoas por protegê-los, independentemente do tamanho do projeto. Construir com segurança desde o início não é só boa prática técnica, é responsabilidade legal e ética com as pessoas que confiaram seus dados a você.

Você não precisa dominar tudo para começar certo. Os fundamentos arquiteturais, nunca confiar no cliente, separar autenticação de autorização, criptografar a comunicação, proteger senhas, validar toda entrada, já colocam um iniciante à frente de uma quantidade enorme de aplicações no mercado. Segurança, no início, é menos sobre técnicas avançadas e mais sobre não cometer os erros básicos que se sabe como evitar.

Aprender a desenhar com segurança desde o primeiro projeto é um investimento que se paga muitas vezes. Refazer um sistema construído sem esses fundamentos é caro e doloroso; construí-lo certo desde o começo é apenas uma questão de hábito.

Se você está começando a desenvolver para a web e quer construir com a fundação certa, há outros artigos no blog sobre autenticação, OWASP, LGPD e arquitetura segura que aprofundam cada um destes pontos. Se for um momento de aprendizado ou de decisão na sua organização, vale conversar.