O que é cibersegurança?

Cibersegurança é o trabalho de manter sistemas digitais confiáveis quando pessoas, softwares e redes fazem coisas que você não esperava.

Essa definição é proposital ampla. Ela pode incluir fraude bancária, malware, phishing, infraestrutura em nuvem, defesa de redes, privacidade, resposta a incidentes e uma dezena de outras especialidades. Este manual não tenta cobrir tudo isso.

Este manual é sobre segurança de aplicações para desenvolvedores: a segurança do código que você escreve, revisa e coloca em produção.

JunoO que é cibersegurança? Cibersegurança é uma palavra grande, mas este manual mantém o foco no código. Nos importamos com o campo de formulário que alguém edita, o registro de pedido que alguém solicita, o token que prova quem a pessoa é, e a rota que é chamada vezes demais.

Isso já é suficiente para começar. Você não precisa aprender todas as funções de segurança de uma vez só.

JunoO que é cibersegurança? Cibersegurança cobre um terreno enorme. O recorte útil aqui é a segurança de aplicações: os pontos onde uma requisição, um usuário, um registro de banco de dados ou um token encontram o código que você coloca em produção.

Isso mantém o trabalho concreto. Se você consegue reproduzir o bug alterando uma rota, um corpo de requisição, um cookie, um token, um schema ou um caminho de middleware, o assunto pertence a este manual.

JunoO que é cibersegurança? O limite aqui é deliberado: segurança de aplicações, não a indústria de segurança como um todo. O teste é se a falha vem de código, configuração ou fluxo de dados que um desenvolvedor consegue raciocinar, alterar e testar com testes de regressão.

Isso ainda deixa bastante coisa para quebrar: injeção, identidade, autorização, disponibilidade, segredos e logs. Malware, defesa de redes e compliance podem cuidar dos seus próprios assuntos. Este aqui já tem arestas afiadas suficientes.

Isso significa que nos importamos com perguntas como estas:

• O que acontece se um usuário altera um campo oculto de formulário antes de enviá-lo?
• Um cliente pode ler o pedido de outro cliente?
• O que acontece se um token de login vazar?
• Uma rota pode ser chamada milhares de vezes até o aplicativo ficar lento?
• O servidor verifica os dados, ou ele só confia no navegador?

Por que essas perguntas?

Elas estão dentro do código-base, da API, da consulta ao banco de dados, do cookie de sessão e do schema de validação. Essa é a parte da cibersegurança do tamanho de um desenvolvedor que este manual ensina.

Como chegamos até aqui

A palavra é mais nova que o problema. Os computadores começaram como máquinas compartilhadas em laboratórios, depois foram para escritórios, casas, celulares e sistemas de pagamento. Quando o software passou a carregar dinheiro, identidade e registros privados, quebrar o software deixou de ser uma brincadeira e virou uma forma de roubar, espionar, atrapalhar ou se passar por outra pessoa.

A web intensificou essa mudança. Um navegador é uma porta de entrada amigável, mas ele envia texto que seu servidor precisa interpretar: URLs, headers, cookies, formulários, corpos JSON, uploads de arquivos.

Cada requisição é uma pequena história que o navegador conta ao seu servidor, e o servidor precisa decidir o quanto acreditar nela.

Por que desenvolvedores precisam disso

Os primeiros sites eram basicamente documentos. Você visitava uma página, lia, clicava em um link e seguia em frente. As aplicações web modernas são diferentes. Elas recebem pagamentos, armazenam dados pessoais, gerenciam identidade, chamam APIs, fazem upload de arquivos e tomam decisões em nome dos usuários.

Uma funcionalidade normal pode virar um bug de segurança quando confia na coisa errada. Uma caixa de busca pode virar um ponto de injeção. Uma página de perfil pode vazar os dados de outra pessoa. Um botão útil de exportação pode virar um problema de negação de serviço se uma única requisição pedir ao banco de dados uma quantidade excessiva de trabalho.

A boa notícia é que a maior parte disso pode ser aprendida. Você não precisa virar criptógrafo nem engenheiro de redes para escrever código de backend mais seguro. Você precisa de alguns hábitos:

• Perceber onde a entrada de dados chega ao sistema.
• Verificar decisões no servidor.
• Tratar identidade e permissões como perguntas separadas.
• Pensar no que pode dar errado antes de a funcionalidade ir para produção.
• Conhecer as classes comuns de bugs o suficiente para reconhecê-las.

Esse é o caminho que este manual segue.

JunoPor que desenvolvedores precisam disso Um bug de segurança costuma ser uma funcionalidade normal confiando na coisa errada. O navegador diz que este pedido é meu. A URL diz que este é o meu registro. A requisição diz que este preço é de três reais.

O servidor precisa se perguntar: "Eu sei disso por conta própria?" Essa única pergunta carrega boa parte do curso.

JunoPor que desenvolvedores precisam disso As aplicações modernas são fronteiras de segurança porque tomam decisões: quem pode ver um registro, qual ação é permitida, se a entrada é válida, e quanto trabalho uma requisição pode pedir.

Regra prática: encontre a decisão, depois encontre os dados que ela usou. Se os dados vieram do navegador, de um token, de outro serviço ou de um registro antigo do banco de dados, faça o servidor comprovar isso antes de confiar.

JunoPor que desenvolvedores precisam disso A maioria dos bugs de segurança de aplicações são bugs comuns de fluxo de controle, com a diferença de que há um chamador hostil na sala. A ramificação foi executada, a consulta retornou, o middleware passou, e ainda assim o invariante falhou porque o valor decisivo veio do lado errado da fronteira.

A versão pronta para produção é sem graça e útil: coloque o controle onde o invariante é imposto, teste o caminho ruim e deixe evidências para a próxima pessoa que se perguntar por que aquela verificação existe.

O caminho a partir daqui

O caminho começa com uma ideia simples: código seguro começa em como pensamos.

É por isso que a primeira seção começa com STRIDE e OWASP. O STRIDE ajuda você a perguntar o que pode dar errado enquanto uma aplicação ainda está sendo projetada. O OWASP dá nomes aos bugs que aparecem quando aplicações reais já estão rodando no mundo.

Primeiro construímos a mentalidade, depois passamos para o trabalho concreto do desenvolvedor: entrada de dados insegura, XSS, injeção SQL, validação, autenticação, tokens, OAuth, limitação de taxa e throttling.

JunoO caminho a partir daqui Os primeiros capítulos são sobre aprender as perguntas. O que pode dar errado? De quem é essa requisição? O que esse usuário tem permissão de tocar? O que acontece se a entrada for hostil?

Depois disso, os capítulos transformam essas perguntas em código.

JunoO caminho a partir daqui A ordem importa. O STRIDE te dá perguntas para o momento de design, o OWASP te dá nomes para bugs já em produção, e então a triagem transforma um achado em impacto, prioridade e próxima ação.

Depois disso, a trilha aplica o mesmo ciclo à entrada de dados, à identidade e ao tráfego. A correção fica mais fácil de lembrar quando permanece associada ao bug que ela previne.

JunoO caminho a partir daqui O caminho é um ciclo funcional: prever falhas antes da construção, reconhecer as que chegam à produção, decidir quais importam primeiro e então realimentar a lição no próximo design.

Os capítulos seguintes são instâncias concretas desse ciclo: interpretadores, sistemas de identidade, permissões, volume de requisições e evidências operacionais. Mesmo café, novo modo de falha.

## O que este manual não é

Isso não é um levantamento completo de cibersegurança. Não estamos cobrindo análise de malware, ferramentas de teste de invasão, defesa de redes, frameworks de compliance ou operações de segurança.

Esses temas importam. Eles ficam fora do trabalho que este manual se propõe a fazer.

O trabalho aqui é mais restrito e mais prático: ajudar você a construir aplicações de backend mais difíceis de usar de forma indevida, mais fáceis de entender e mais seguras para colocar diante de usuários reais.

JunoO que este manual não é Deixar temas de fora faz parte do que torna o manual útil. Vamos ficar com o código que você pode abrir, ler e alterar.

Isso significa rotas, schemas, cookies, tokens, consultas e middleware. Muita coisa para aprender, sem fingir que um único manual consegue ensinar todos os campos da segurança.

JunoO que este manual não é O escopo é segurança de aplicações para desenvolvedores de backend. Isso mantém cada capítulo perto de uma rota, schema, cookie, token, consulta, função de middleware ou configuração de deploy que você pode inspecionar.

Quando um tema exige um SOC, uma captura de pacotes, um programa de compliance ou um laboratório de malware, ele fica fora desta trilha. Útil, mas não é o trabalho que este manual se propõe a fazer.

JunoO que este manual não é O escopo mais restrito é o que dá substância ao manual. Um levantamento amplo nomearia todos os campos de segurança e não ensinaria nenhum deles bem, e é assim que você acaba com um checklist do qual ninguém se responsabiliza.

Esta trilha acompanha os sistemas que um desenvolvedor de backend pode alterar, revisar e testar: tratamento de requisições, identidade, autorização, validação, throttling, armazenamento e higiene operacional.

Para onde isso vai a partir daqui

A palavra foi restringida: segurança de aplicações, o código que você escreve, revisa e coloca em produção. O escopo está definido, e as perguntas que valem a pena fazer estão sobre a mesa.

O que falta é o hábito de fazê-las. Como pensar sobre segurança é onde isso começa, com fronteiras de confiança e o reflexo de olhar para o seu próprio código do jeito que alguém mal-intencionado olharia.