Cenário (horizonte): "harvest now, decrypt later" (guardar tráfego cifrado para quebrar no futuro) e ataques automatizados por IA. Prontidão: TLS 1.3, planejar migração para cripto pós-quântica quando disponível nos provedores; tratar conteúdo gerado por IA como não confiável (Ex. 33); rate limit contra automação.

Ação (P3/horizonte): acompanhar suporte PQC de Cloudflare/navegadores; manter TLS forte; defesas anti-bot.

BLOCO N — Fraudes fintech & marketplace (Ex. 71–80)

Natureza: falhas de lógica de negócio (não de código). São preventivas enquanto o produto não tem pagamentos/marketplace — vire "requisito de design seguro". Padrão: entender o abuso → definir o controle → testar quando existir o fluxo.

Como estudar este bloco agora (sem os fluxos prontos):

1. Para cada linha, escreva em 3 frases como você abusaria (mentalidade atacante).
2. Escreva o controle que impede (mentalidade defensora) — vira requisito no design.
3. Guarde num REQUISITOS_SEGUROS_FINTECH.md. Quando implementar pagamentos, cada requisito vira um teste (formato dos Ex. 1–36).

Regra de ouro fintech: o valor e o estado do dinheiro são sempre decididos no servidor, dentro de uma transação, e conferidos contra o PSP — nunca confiados no cliente/comprovante. (É o 0.2/0.10 aplicado a dinheiro.)

BLOCO O — Categorias de software SaaS (Ex. 81–86)

Natureza: falhas típicas quando o produto vira SaaS multiusuário. Preventivas hoje; viram teste quando o módulo existir. Cada uma tem um teste-âncora reutilizável.

Teste-âncora universal de multi-tenant (o mais importante do bloco):

# Com token do tenant A, tentar acessar recurso do tenant B — DEVE dar 403/404:
curl -s -o /dev/null -w "cross-tenant → %{http_code}\n" \
  "$BASE/api/recurso/ID_DO_TENANT_B" -H "Authorization: Bearer $TOKEN_TENANT_A"

• VULNERÁVEL: 200 (leu dado de outro cliente) → falha crítica de isolamento (BOLA/IDOR).
• SEGURO: 403/404 sempre; toda query filtra por tenant_id do token.

Ação (P0 quando for SaaS): isolamento por tenant em todas as queries; testes automatizados de cross-tenant a cada deploy.

🧹 Limpeza geral deste guia

-- Remova quaisquer dados de teste criados nos exercícios acima:
delete from leads where car_title like 'pentest%';
delete from feed_events where session_id like 'pentest%';

# Arquivos locais de teste:
rm -f pentest_shell.php.jpg; rm -rf saida/
# Feche wscat/scanners abertos (Ctrl+C). Dropar DBs temporários de restore.

🔄 Rotina (igual aos Ex. 1–36)

recon → executar → registrar achado → corrigir (P0→P3) → re-testar o probe → item só sai do placar quando o probe passa. Atualize o INVENTARIO-SUPERFICIE.md e as métricas.

📌 Nota de completude e honestidade

• Ex. 37–60 (Blocos I–K): executáveis com comandos reais — prontos para rodar em ambiente autorizado/lab.
• Ex. 61–65 (Bloco L): blue team, com verificações concretas + entregável defensivo.
• Ex. 66–70 (Bloco M): tabletop/checklist de prontidão (são cenários organizacionais, não payloads).
• Ex. 71–86 (Blocos N–O): preventivos — viram testes no formato dos Ex. 1–36 quando os fluxos existirem (pagamentos, SaaS multi-tenant). Por isso são tabela de "abuso → controle" + teste-âncora, não passo a passo de algo que ainda não está no ar.

Isso é intencional e correto: não faz sentido escrever curl contra um endpoint de saque que não existe. O valor aqui é você aprender o controle antes de construir o fluxo — segurança por design. Quando implementar, promova cada linha a um exercício completo.

Fim do Guia Multi-Stack. Volte ao CURRICULO_TRILHA.md (Níveis 5–8) para o encaixe na jornada e ao AVALIACOES_QUIZZES.md (Quiz 5/6) para verificar a compreensão.