Segurança — autenticação, injeção de SQL, variáveis de ambiente
A maioria dos problemas de segurança não vem de ataques sofisticados — vem de detalhes básicos deixados sem atenção.
Autenticação
Injeção de SQL
Variáveis de ambiente
00 — AUTENTICAÇÃO
Provar quem alguém é antes de deixar entrar
Autenticação é o processo de confirmar que alguém é quem diz ser — o exemplo mais comum é login com e-mail e senha, mas também existe autenticação via código enviado por e-mail, aplicativo de celular, ou provedores como Google. É diferente de autorização, que decide o que essa pessoa já autenticada pode fazer (por exemplo, se ela pode ou não acessar o painel de admin). Autenticação responde "quem é você"; autorização responde "o que você pode fazer".
Metáfora: autenticação é o segurança na porta checando seu documento pra confirmar que você é você mesmo. Autorização é a pulseira que diz se você pode entrar só na pista de dança ou também no camarote.
No seu projetoO Enf Pró Cards ainda não tem autenticação de aluno implementada — é justamente o tipo de decisão que entra na Fase 2 do projeto, junto com o gate de pagamento do Kiwify.
reconhecer 1 — autenticaçãopendente
Qual é a diferença entre autenticação e autorização?
ASão a mesma coisa com nomes diferentes
BAutenticação confirma quem a pessoa é; autorização decide o que ela pode fazer depois de confirmada
CAutorização acontece sempre antes da autenticação
01 — INJEÇÃO DE SQL
Quando um campo de texto vira um comando pro banco de dados
Injeção de SQL é um ataque onde alguém digita, num campo comum (como um campo de busca ou login), um trecho de comando SQL — a linguagem do banco de dados vista no Módulo 6 — tentando enganar o sistema pra executar esse comando em vez de tratá-lo como um texto qualquer. Um sistema vulnerável pode acabar apagando tabelas inteiras ou vazando dados de outros usuários a partir de um único campo de formulário mal protegido.
Metáfora: é como se alguém escrevesse, no campo "nome" de um formulário de papel, uma instrução pro funcionário que vai ler aquele formulário depois — e o funcionário, sem perceber a diferença, obedecesse a instrução em vez de só arquivar o nome.
Por que isso importaO ORM, visto no Módulo 6 (Drizzle no Enf Pró Cards, Prisma no SongPlay), já trata automaticamente qualquer entrada do usuário como texto puro antes de montar a consulta — é uma das razões práticas de usar um ORM em vez de montar comandos SQL na mão.
reconhecer 2 — injeção de SQLpendente
Por que usar um ORM reduz o risco de injeção de SQL?
APorque o ORM trata a entrada do usuário como texto puro, em vez de deixá-la virar parte do comando executado no banco
BPorque ORMs são sempre mais rápidos que SQL escrito à mão
CPorque ORMs eliminam a necessidade de banco de dados
02 — VARIÁVEIS DE AMBIENTE
Senhas e chaves de API não moram junto do código
Variáveis de ambiente são valores (como senhas, chaves de API ou endereços de banco de dados) guardados fora do código-fonte, geralmente num arquivo separado (como .env) que nunca é publicado junto com o resto do projeto. Isso evita que uma chave secreta apareça exposta se o código for compartilhado, publicado num repositório público, ou visto por qualquer pessoa que tenha acesso só aos arquivos do projeto.
Metáfora: é a diferença entre escrever a senha do cofre da empresa dentro do manual de instruções impresso (que qualquer funcionário lê) e guardá-la separada, só com quem realmente precisa acessar o cofre.
No seu projetoO bug real corrigido no Enf Pró Cards (documentado como incidente anterior) foi justamente o ecosystem.config.js do PM2 não repassando as variáveis de ambiente de e-mail — os emails nunca saíam porque a chave da Resend não chegava até o processo em produção.
reconhecer 3 — variáveis de ambientependente
Por que uma chave de API não deve ficar escrita direto no código-fonte?
APorque o código ficaria mais lento
BPorque qualquer pessoa com acesso aos arquivos do projeto (ou um repositório público) veria a chave exposta
CPorque o Next.js não permite variáveis dentro do código
desafio final do módulo 12: Um formulário de busca do seu site aceita qualquer texto digitado pelo usuário e usa esse texto direto numa consulta SQL montada manualmente, sem ORM. Qual é o risco, e o que evitaria esse problema?
desafio finalpendente
Escolha a alternativa mais coerente com os conceitos deste módulo.
AO formulário está vulnerável a injeção de SQL; usar um ORM (ou tratar a entrada como texto puro) evitaria que um comando digitado pelo usuário fosse executado no banco
BNão existe risco, porque campos de busca nunca são alvo de ataque
CO problema seria resolvido apenas guardando a senha do banco em variável de ambiente