GitHub

A pergunta "devo criar um aplicativo?" quase sempre vem acompanhada de planilhas de custo, ideias de tela e sonhos de crescimento. Raramente vem acompanhada de uma pergunta tão importante quanto: "estou preparado para guardar os dados das pessoas que vão usá-lo?".

Essa ausência não é maldade. É desconhecimento. Quem está começando enxerga segurança como algo que se resolve depois, quando o produto crescer. Mas segurança não é um recurso que se adiciona no fim, é uma fundação. E fundação você não acrescenta com o prédio já construído.

Este texto é para quem está no momento de decidir criar um aplicativo e quer entender, sem jargão, o que precisa estar na cabeça desde o primeiro dia. Não para virar especialista, mas para não tomar decisões que custam caro lá na frente.

Por que segurança importa antes mesmo do código

Todo aplicativo que faz algo útil guarda dados. Nome, e-mail, telefone, localização, histórico de uso, às vezes documento e dado de pagamento. No instante em que você coleta o primeiro dado de uma pessoa, você assumiu uma responsabilidade legal e ética.

No Brasil, isso tem nome: LGPD, a Lei Geral de Proteção de Dados. Ela não é uma sugestão. Ela define que você é responsável pelos dados que coleta, que precisa de uma base legal para coletá-los e que precisa protegê-los. Um aplicativo de iniciante e um de grande empresa estão sujeitos à mesma lei.

A consequência prática: você não decide se vai se preocupar com segurança. Você só decide se vai se preocupar antes ou depois do problema. E depois é sempre mais caro, em dinheiro, em reputação e, às vezes, em multa.

A tese: segurança é decisão de arquitetura, não de manutenção

A ideia central deste artigo é simples. Segurança não é uma camada que você passa por cima do produto pronto. É um conjunto de decisões que moldam como o produto é construído desde o começo.

Onde os dados ficam guardados. Como as senhas são tratadas. Quem pode ver o quê. Como o aplicativo conversa com o servidor. Cada uma dessas escolhas é tomada cedo, e refazê-las depois significa reescrever partes inteiras do sistema.

Por isso a melhor hora para um iniciante pensar em segurança não é quando ele já é avançado. É exatamente agora, no início, quando as decisões ainda são baratas de tomar.

Os fundamentos que ninguém deveria pular

Você não precisa dominar criptografia para começar com responsabilidade. Precisa respeitar um punhado de princípios que resolvem a maioria dos riscos iniciais.

Nunca guarde senha em texto puro

Senhas jamais devem ser guardadas como o usuário digitou. Elas passam por um processo chamado hash, que as transforma em algo irreversível. Mesmo que alguém roube o banco de dados, não consegue ler as senhas. Frameworks modernos já fazem isso por você, o erro do iniciante é desativar ou contornar essa proteção por pressa.

Coloque autenticação e autorização desde o início

Autenticação é confirmar quem a pessoa é. Autorização é definir o que ela pode fazer. Os dois são diferentes e os dois importam. Um erro comum é proteger a tela de login mas esquecer de verificar, em cada ação, se aquele usuário tem permissão para aquilo. O resultado é o clássico: trocar um número na URL e acessar os dados de outra pessoa.

Toda comunicação deve ser criptografada

Os dados que trafegam entre o aplicativo e o servidor precisam viajar protegidos, usando HTTPS. Sem isso, qualquer pessoa numa rede compartilhada, um Wi-Fi de café, por exemplo, pode interceptar o que está sendo enviado. Hoje isso é padrão e barato. Não há desculpa para não fazer.

Colete só o que você precisa

O dado mais seguro é o que você não guarda. Antes de pedir uma informação, pergunte: eu realmente preciso disso? Coletar tudo "porque pode ser útil um dia" aumenta o que você tem a proteger e o seu risco diante da LGPD. Minimização de dados é, ao mesmo tempo, boa prática de segurança e exigência legal.

Um exemplo concreto: o app que vazou sem ser hackeado

Imagine um pequeno aplicativo de agendamento criado por um empreendedor iniciante. Ele funciona bem, cresce, ganha usuários. Um dia, alguém descobre que, mudando o número de identificação na requisição, consegue ver os agendamentos de qualquer outro cliente, incluindo nome, telefone e endereço.

Não houve invasão sofisticada. Não houve hacker genial. Houve uma falha de autorização: o sistema confirmava quem você era, mas não verificava se aquele dado era seu. É uma das falhas mais comuns que existem, catalogada pela OWASP entre os principais riscos de aplicações.

A lição para o iniciante: a maioria dos vazamentos não vem de ataques de cinema. Vem de descuidos básicos que poderiam ter sido evitados com princípios simples aplicados desde o início.

Use o que já existe em vez de inventar

Há um instinto compreensível em quem começa: querer construir tudo do zero para entender como funciona. Em segurança, esse instinto é perigoso. Criptografia, gestão de senhas e autenticação são áreas onde até especialistas erram, e onde um erro sutil abre uma brecha enorme.

O caminho responsável para o iniciante é usar bibliotecas e serviços consolidados, mantidos por comunidades que já enfrentaram e corrigiram os problemas que você ainda nem imagina. Não escreva seu próprio algoritmo de senha. Não invente seu próprio esquema de login. Use o que foi testado por milhares de pessoas e é atualizado quando uma falha aparece.

Isso vale também para manter as dependências atualizadas. Boa parte dos ataques explora falhas já conhecidas e já corrigidas em versões mais novas, que a vítima simplesmente não instalou. Atualizar é uma das defesas mais baratas e mais negligenciadas que existem.

A reflexão que separa amador de profissional

Existe uma armadilha mental perigosa: "meu app é pequeno demais para ser alvo". É justamente o contrário. Aplicativos pequenos costumam ter as proteções mais fracas, o que os torna alvos fáceis para ataques automatizados que varrem a internet procurando falhas conhecidas. Ninguém precisa querer atacar você especificamente, basta um robô encontrar a porta aberta.

A maturidade aqui não é técnica, é de postura. É entender que, ao pedir os dados de alguém, você fez uma promessa de cuidado. Quebrar essa promessa, mesmo sem querer, tem consequências reais para pessoas reais.

E há um ponto de negócio que iniciantes subestimam: confiança é o ativo mais difícil de reconstruir. Um produto pode se recuperar de uma falha de funcionalidade. Recuperar-se de um vazamento que expôs os clientes é muito mais difícil.

Comece simples, mas comece certo

Você não precisa de uma fortaleza para lançar seu primeiro aplicativo. Precisa de fundamentos sólidos: senhas protegidas, comunicação criptografada, autorização verificada e coleta mínima de dados. Isso já coloca você à frente de uma quantidade enorme de produtos no mercado.

Segurança para iniciantes não é sobre saber tudo. É sobre não cometer os erros que se sabe como evitar. O resto se aprende com o tempo, desde que a fundação esteja certa.

Se você está prestes a criar um aplicativo e quer entender como embutir segurança desde o desenho, há outros artigos no blog sobre LGPD, autenticação e arquitetura segura que aprofundam cada um destes pontos. Se for um momento de decisão na sua organização, vale conversar antes de escrever a primeira linha.

Quando criar um aplicativo: segurança que iniciantes não podem ignorar