Guia prático de cybersecurity para aplicações

Autenticação, tokens, JWT, cookies, APIs, frontend, backend, banco de dados, integrações e DevSecOps

Atualizado em 1º de agosto de 2026
Idioma: português do Brasil
Público: gestores, donos de produto, analistas, arquitetos, desenvolvedores, QA, DevOps/SRE e pessoas que contratam software.

Objetivo: permitir que uma pessoa ainda iniciante entenda o que acontece, saiba quais perguntas fazer e consiga transformar “faça de forma segura” em requisitos verificáveis.

Aviso: segurança depende do risco, dos dados, da arquitetura e das obrigações da organização. Este guia fornece uma base técnica; ele não substitui análise de risco, teste independente, resposta a incidentes nem aconselhamento jurídico.

Como usar este guia

Se você está aprendendo, leia as partes 1 a 9 na ordem. Se está contratando ou acompanhando um projeto, comece pelas partes 18 a 21. Se está implementando, use os checklists de cada camada e transforme os critérios de aceite em testes automatizados.

Os exemplos de código mostram padrões, não uma biblioteca universal. Em produção:

use bibliotecas de segurança maduras e mantidas;
leia a documentação da versão realmente instalada;
não implemente criptografia, validação de JWT ou OAuth “na mão”;
teste casos válidos, inválidos, expirados, adulterados e sem permissão;
registre decisões e exceções de segurança.

Referências-base deste material

As principais bases são o OWASP Top 10:2025, o OWASP API Security Top 10:2023, o OWASP ASVS 5.0.0, o NIST SSDF 1.1, o NIST SP 800-63B-4 e as RFCs oficiais citadas em cada assunto.

Sumário

O mapa mental da segurança
Quem é responsável por cada configuração
HTTP, requisição, resposta e JSON
Autenticação, autorização e sessão
Hash de senha
Tokens: o que são, quem gera e como funcionam
JWT sem mistério
Expiração, renovação, logout e revogação
Cookies: HttpOnly, Secure, SameSite e afins
OAuth, OpenID Connect, SSO e autenticação corporativa
Chamadas, paginação, cotas e rate limit
Segurança de APIs
Segurança do backend
Segurança do frontend e de aplicativos clientes
Segurança do banco de dados e do Supabase
Integrações, webhooks, arquivos, filas e ERP
Criptografia, chaves e segredos
DevSecOps e cadeia de suprimentos
Código produzido com IA e “vibe coding”
Falhas comuns e como evitá-las
Checklist mestre e critérios de aceite
O que solicitar ao desenvolvedor ou fornecedor
Como acompanhar status sem aceitar respostas vagas
Resposta a incidentes e vulnerabilidades
Glossário
Fontes oficiais e normas

1. O mapa mental da segurança

Uma aplicação típica tem várias camadas:

Pessoa
  ↓
Frontend web ou aplicativo móvel
  ↓ HTTPS
API / Backend
  ├─ Sistema de identidade (login, MFA, tokens)
  ├─ Banco de dados
  ├─ Armazenamento de arquivos
  ├─ ERP e serviços de terceiros
  └─ Logs, monitoramento e alertas
       ↓
Pipeline de desenvolvimento e implantação

Um invasor procura o ponto em que uma camada confia demais na anterior. Exemplos:

o backend acredita no perfil admin enviado pelo frontend;
a API autentica o usuário, mas não verifica se a ordem consultada pertence a ele;
o banco aceita consultas montadas pela concatenação de texto;
o navegador guarda um token onde qualquer JavaScript da página pode lê-lo;
a pipeline instala uma dependência sem verificar origem ou integridade;
uma chave administrativa do Supabase é colocada no frontend;
um desenvolvedor aceita código gerado por IA sem revisar pacotes, permissões ou testes.

1.1 Os objetivos: confidencialidade, integridade e disponibilidade

Confidencialidade: somente quem tem direito lê os dados.
Integridade: dados e ações não são alterados indevidamente.
Disponibilidade: o sistema continua funcionando quando necessário.

Outros objetivos importantes:

autenticidade: saber quem realizou a ação;
rastreabilidade: reconstruir o que ocorreu;
privacidade: coletar e usar somente os dados necessários;
resiliência: detectar, conter, recuperar e aprender com incidentes.

1.2 Segurança não é um produto isolado

Firewall, WAF, antivírus e scanner ajudam, mas não corrigem uma regra de negócio errada. Se a API permite que o usuário 10 troque /ordens/10 por /ordens/11 e veja a ordem de outra empresa, o problema é de autorização em nível de objeto. O controle precisa existir no backend e ser testado com identidades diferentes.

1.3 Três princípios que aparecem em todo o guia

Negar por padrão. Se não existe regra explícita permitindo, negar.
Menor privilégio. Cada usuário, serviço, chave e banco recebe somente o necessário.
Defesa em profundidade. Não depender de um único controle; combinar prevenção, detecção e recuperação.

O OWASP Authorization Cheat Sheet recomenda menor privilégio, negação por padrão e verificação de permissão em toda requisição.

2. Quem é responsável por cada configuração

Segurança é compartilhada. “O desenvolvedor cuida” é insuficiente porque muitas decisões pertencem ao negócio, à identidade corporativa, à infraestrutura ou ao banco.

Assunto	Decide	Implementa/configura	Verifica	Evidência esperada
Dados e impacto	Dono do negócio, privacidade, segurança	Produto e arquitetura	Auditoria/risco	classificação, retenção e fluxos de dados
Perfis e permissões	Dono do processo	Backend/IAM	QA/AppSec + usuários-chave	matriz de acesso e testes negativos
Login e MFA	Negócio + segurança/IAM	IAM e backend	AppSec/QA	fluxos documentados e testes de recuperação
Hash de senha	Arquitetura/segurança	Backend ou provedor de identidade	AppSec	algoritmo, parâmetros, migração e teste
Emissão de token	Arquitetura/IAM	servidor de autorização/IdP	AppSec	configuração do emissor, chaves e claims
Cookie de sessão	Arquitetura	backend/framework; às vezes proxy	QA/AppSec no navegador	`Set-Cookie` e testes de CSRF/XSS
HTTPS/TLS/HSTS	Infraestrutura/SRE	proxy, load balancer, CDN ou servidor	scanner e monitoramento	configuração TLS e renovação de certificado
CORS	Arquitetura/API	backend/API gateway	QA/AppSec	lista de origens permitidas e testes
Banco e RLS	Arquitetura/dono dos dados	DBA/backend/plataforma	QA/AppSec/DBA	grants, políticas e testes entre usuários/tenants
Segredos e chaves	Segurança/plataforma	DevOps/SRE/IAM	auditoria/AppSec	inventário, cofre, rotação e logs
Pipeline	Engenharia/plataforma	DevOps e times	AppSec	revisão, scanners, SBOM e artefatos assinados
Logs e alertas	Segurança + operações + negócio	Backend/SRE/SOC	exercícios de detecção	eventos, painéis, alertas e runbooks
Backup e recuperação	Negócio define RPO/RTO	DBA/SRE	auditoria e teste de restauração	relatório do restore testado

2.1 Resposta direta: quem configura hash, tokens e cookies?

Hash de senha: o backend ou o provedor de identidade. O banco armazena o resultado, mas não deve decidir sozinho o algoritmo. Arquitetura/AppSec define a política e verifica.
Token: o servidor de autorização, provedor de identidade ou backend confiável. O frontend solicita/recebe, mas não cria um token que a API deva aceitar como prova.
Cookie: normalmente o backend envia o cabeçalho Set-Cookie; o navegador aplica HttpOnly, Secure e SameSite. Infraestrutura garante HTTPS e não deve remover ou sobrescrever os atributos.
Autorização: o backend/API e, como defesa adicional, o banco. Esconder botões no frontend melhora a interface, mas não protege o recurso.

Critérios de aceite desta parte

Existe um responsável nomeado para cada domínio da tabela.
Decisões de segurança não dependem apenas de uma pessoa ou de conhecimento verbal.
Há separação entre quem implementa e quem valida controles críticos.
Toda exceção tem justificativa, prazo, responsável e risco aceito formalmente.

3. HTTP, requisição, resposta e JSON

3.1 O que é HTTP?

HTTP é o protocolo que define como um cliente pede um recurso e como um servidor responde. A semântica atual está padronizada na RFC 9110.

Uma requisição contém, de forma simplificada:

POST /api/v1/ordens HTTP/1.1
Host: manutencao.exemplo.com
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: 78f6cabc-...

{
  "equipamentoId": "eq_123",
  "descricao": "Ruído anormal"
}

A resposta pode ser:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/ordens/os_456
Cache-Control: no-store

{
  "id": "os_456",
  "status": "aberta"
}

3.2 Para que serve cada parte?

Método: intenção (GET, POST, PUT, PATCH, DELETE).
URL/endpoint: recurso desejado.
Headers: metadados como autenticação, tipo do conteúdo e rastreamento.
Body: dados enviados; frequentemente JSON.
Status HTTP: resultado geral.
Body da resposta: dados ou detalhes do erro.

3.3 Por que JSON e não Java?

Java é uma linguagem de programação. JSON é um formato de dados independente de linguagem. Um backend escrito em Java, um aplicativo em Dart e uma automação em Python podem trocar o mesmo JSON.

JSON não executa lógica por si só:

{
  "id": "os_456",
  "prioridade": "alta",
  "responsavel": null
}

Mesmo assim, JSON recebido é entrada não confiável. O backend deve limitar tamanho, profundidade, campos, tipos e valores; deve rejeitar campos desconhecidos quando isso for apropriado.

3.4 Status não substitui detalhes seguros

Use o status correto e um corpo de erro previsível. A RFC 9457 define “Problem Details for HTTP APIs”.

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type": "https://api.exemplo.com/problemas/status-invalido",
  "title": "Status inválido",
  "status": 422,
  "detail": "A ordem concluída não pode voltar para aberta.",
  "instance": "/api/v1/ordens/os_456",
  "requestId": "req_01J..."
}

O cliente recebe uma mensagem útil; detalhes internos, consulta SQL, stack trace, caminho de arquivo e segredo ficam fora da resposta.

3.5 HTTPS e TLS

HTTPS é HTTP protegido por TLS. TLS fornece confidencialidade e integridade em trânsito e autentica o servidor por certificado. Não protege dados depois que chegaram ao navegador, backend ou banco.

Para sistemas novos, habilite TLS 1.3 e mantenha TLS 1.2 somente quando necessário e bem configurado. TLS 1.0/1.1 e SSL não devem ser negociados. A referência técnica é a RFC 9325; para web, use HSTS conforme a RFC 6797.

Critérios de aceite desta parte

Todo tráfego autenticado e sensível usa HTTPS, inclusive comunicação interna relevante.
HTTP é desabilitado para APIs ou redirecionado com política HSTS adequada para web.
A API limita tamanho e complexidade de body, query e upload.
Erros têm formato documentado e não expõem detalhes internos.
Respostas sensíveis usam Cache-Control: no-store quando aplicável.

4. Autenticação, autorização e sessão

4.1 A diferença fundamental

Autenticação (AuthN): prova quem é a entidade.
Autorização (AuthZ): decide o que essa entidade pode fazer agora, neste recurso.
Sessão: mantém a continuidade entre várias requisições HTTP.

Exemplo:

Cleiton informa credencial + MFA
        ↓ autenticação
Sistema identifica user_123
        ↓ sessão/token
user_123 tenta PATCH /ordens/os_456/concluir
        ↓ autorização
Regra verifica: pertence à empresa? tem função? estado permite?
        ↓
Permite ou retorna 403

Estar autenticado não concede acesso geral. A API precisa verificar:

ação ou função (concluir_ordem);
objeto específico (os_456);
propriedade alterada (status, não aprovadoPor);
tenant/empresa/unidade;
contexto, como MFA recente para ação crítica;
regra de negócio e segregação de funções.

4.2 RBAC, ABAC e ReBAC

RBAC: baseado em papel, por exemplo eletricista, supervisor, admin.
ABAC: usa atributos do usuário, recurso e contexto; por exemplo unidade, horário e nível de risco.
ReBAC: usa relacionamento; por exemplo “é responsável por esta ordem”.

RBAC é um começo, mas role=admin não resolve autorização horizontal. Para cada objeto, verifique propriedade, tenant ou relacionamento.

4.3 Exemplo inseguro e seguro

Inseguro: busca a ordem apenas pelo ID.

SELECT * FROM ordens WHERE id = $1;

Mais seguro: restringe pela organização obtida da identidade validada.

SELECT id, status, equipamento_id
FROM ordens
WHERE id = $1
  AND tenant_id = $2;

O $2 deve vir do contexto de autenticação validado pelo servidor, não de um header livre como X-Tenant-Id enviado pelo cliente.

4.4 Teste que realmente encontra a falha

Crie usuário A e usuário B em tenants diferentes.
A cria uma ordem e recebe os_A.
B tenta ler, alterar e excluir os_A.
Todas as tentativas devem falhar sem vazar conteúdo.
Repita para endpoints irmãos, arquivos, exportações, WebSocket e funções administrativas.

Critérios de aceite desta parte

Existe matriz de sujeitos × ações × recursos × condições.
Toda requisição e todo objeto têm autorização no servidor.
Novos endpoints negam por padrão.
Há testes horizontais entre dois usuários e verticais entre usuário comum e administrador.
A interface não é tratada como controle de segurança.
Falhas de autorização são registradas sem expor dados sensíveis.

5. Hash de senha

5.1 O que é

Hash de senha é uma transformação unidirecional, lenta e configurável usada para verificar uma senha sem armazená-la em texto puro.

No cadastro:

senha digitada
  + salt aleatório único
  + algoritmo de senha e custo
        ↓
hash armazenado

No login, o sistema repete o processo com a senha informada e compara o resultado com segurança. Ele não “descriptografa” a senha.

5.2 Hash não é criptografia e Base64 não é segurança

Hash de senha: não deve ser reversível.
Criptografia: é reversível com uma chave; serve para dados que precisam ser recuperados.
Base64: apenas codifica bytes para texto; qualquer pessoa pode decodificar.

Senha não deve ser armazenada com AES “para poder recuperar” e nunca em texto puro.

5.3 Salt e pepper

Salt: valor aleatório diferente para cada senha, armazenado junto do hash. Evita que senhas iguais produzam o mesmo resultado e dificulta tabelas pré-calculadas.

Pepper: segredo adicional compartilhado, opcional, mantido fora do banco, de preferência em cofre/HSM. Pode reduzir o impacto de um vazamento somente do banco, mas cria responsabilidade de rotação e recuperação. Não substitui salt nem algoritmo adequado.

5.4 Algoritmos adequados

Use uma função específica para senha, lenta e resistente a ataques com hardware paralelo:

Argon2id: preferência geral quando disponível.
scrypt: alternativa resistente a memória.
bcrypt: adequado para sistemas existentes, observando limite de entrada e migração.
PBKDF2: opção comum em ambientes com requisitos específicos de conformidade.

Não use MD5, SHA-1, SHA-256 ou SHA-512 puros para guardar senhas. Eles são rápidos demais.

Em 1º de agosto de 2026, o OWASP Password Storage Cheat Sheet indica Argon2id e publica parâmetros mínimos. Trate esses valores como ponto de partida datado, faça benchmark no hardware real e revise periodicamente.

5.5 Exemplo conceitual seguro

// Pseudocódigo: use a biblioteca oficial/madura do seu ambiente.
const senhaHash = await passwordHasher.hash(senhaRecebida, {
  algorithm: "argon2id",
  parameters: CONFIGURACAO_VERSIONADA_E_TESTADA
});

await usuarios.insert({
  emailNormalizado,
  senhaHash,
  algoritmoVersao: "argon2id-politica-2026-01"
});

Na verificação:

const valido = await passwordHasher.verify(usuario.senhaHash, senhaRecebida);

if (!valido) {
  return erroGenericoDeLogin();
}

if (passwordHasher.needsRehash(usuario.senhaHash, CONFIGURACAO_ATUAL)) {
  const novoHash = await passwordHasher.hash(senhaRecebida, CONFIGURACAO_ATUAL);
  await usuarios.updateHash(usuario.id, novoHash);
}

O rehash no próximo login bem-sucedido permite aumentar o custo ou trocar o algoritmo sem conhecer a senha original.

5.6 Regras modernas de senha

O NIST SP 800-63B-4 recomenda, no contexto coberto pela norma:

mínimo de 15 caracteres para senha como fator único;
mínimo de 8 quando usada como parte de MFA;
bloqueio de senhas comuns, esperadas ou comprometidas;
permitir gerenciadores e colagem;
não impor trocas periódicas arbitrárias;
não impor regras artificiais como “uma maiúscula, um símbolo e um número” no lugar de comprimento e bloqueio de senhas comprometidas.

Adapte ao risco e à regulamentação, mas não reduza a segurança com truncamento silencioso ou limites curtos.

5.7 Quem configura e quem protege

Backend/IdP: algoritmo, custo, salt, comparação e migração.
Segurança/arquitetura: política e revisão periódica.
Banco: acesso mínimo e proteção do hash; hash ainda é dado sensível.
DevOps: pepper/cofre, recursos e alertas.
QA/AppSec: teste de enumeração, rate limit, reset e rehash.

5.8 Falhas comuns

salvar senha ou logá-la;
usar hash rápido;
salt fixo ou ausente;
custo tão baixo que facilita quebra, ou tão alto que causa negação de serviço;
truncar senha;
mensagem diferente para “usuário não existe” e “senha errada”;
endpoint de reset mais fraco que o login;
fazer lockout rígido que permite a um atacante bloquear todas as contas;
enviar senha por e-mail;
deixar conta administrativa usar o mesmo login público sem controles adicionais.

Critérios de aceite desta parte

Nenhuma senha existe em texto puro, log, telemetria, backup de teste ou mensagem.
O algoritmo é específico para senha e a política tem versão.
Cada hash tem salt único; pepper, se usado, fica fora do banco.
O custo foi medido no ambiente real e há proteção contra abuso do endpoint.
Existe migração por rehash e procedimento de emergência.
Login, cadastro e recuperação usam mensagens que não enumeram contas.
Senhas comprometidas são bloqueadas e MFA/passkeys são oferecidos conforme o risco.

6. Tokens: o que são, quem gera e como funcionam

Um token é uma credencial emitida por uma parte confiável para representar uma sessão, uma identidade ou uma autorização. Ele não é uma unidade universal de cobrança.

Há dois usos da palavra que não devem ser confundidos:

token de segurança: credencial apresentada a uma API;
token de IA: fragmento de texto usado por modelos de linguagem para medição e cobrança.

6.1 Quem gera o token?

O emissor confiável — um provedor de identidade, servidor de autorização ou backend — gera e registra/assina o token. O aplicativo cliente inicia o fluxo e recebe a credencial, mas não pode inventar uma credencial que a API aceite.

Usuário → Aplicativo → Servidor de identidade
                          │ valida senha/MFA/passkey
                          │ emite credenciais
Aplicativo ← access token ┘
    │
    └─ Authorization: Bearer <access_token> → API
                                                │ valida token e permissão
                                                └─ consulta banco/ERP

As responsabilidades são diferentes:

emissor: autentica, define validade, audiência, escopos e chaves;
cliente: protege a credencial, solicita apenas o necessário e trata expiração;
API: valida a credencial inteira e autoriza a operação;
dono do negócio: define quem pode fazer o quê;
AppSec/QA: testa roubo, repetição, expiração, revogação e troca de identidade.

6.2 Token opaco e token autocontido

Token opaco: é uma sequência aleatória sem significado para o cliente. A API ou gateway consulta o servidor de autorização/introspecção ou uma sessão no servidor.

xB7n5...u9Q   → servidor consulta → usuário 42, escopo ordens:ler

Vantagens: revogação e mudança de permissões mais diretas. Custos: consulta ou cache adicional e alta disponibilidade do estado.

Token autocontido: carrega declarações protegidas, como um JWT assinado. A API pode validá-lo localmente. Vantagens: validação distribuída. Custos: revogação imediata e alteração de permissões exigem projeto cuidadoso.

Não escolha JWT apenas por popularidade. Sessões opacas, cookies de sessão e BFF (Backend for Frontend) frequentemente são mais simples para aplicações web.

6.3 Como gerar um token opaco

Use um gerador criptograficamente seguro, com entropia suficiente. Nunca use data/hora, contador, e-mail, Math.random() ou identificadores previsíveis.

import { randomBytes, createHash } from "node:crypto";

const tokenEntregueAoCliente = randomBytes(32).toString("base64url");
const digestArmazenado = createHash("sha256")
  .update(tokenEntregueAoCliente)
  .digest("hex");

await sessoes.insert({
  digest: digestArmazenado,
  usuarioId,
  expiraEm,
  revogadoEm: null
});

Para tokens opacos de uso único, guardar apenas um digest reduz o impacto de vazamento do banco. A validação calcula novamente o digest e faz comparação segura. A política deve também impedir reutilização e expirar o registro.

6.4 O ciclo de vida

Todo token precisa de regras para:

emissão: após autenticação/autorização adequada;
entrega: somente por canal seguro e ao destinatário correto;
armazenamento: adequado ao tipo de cliente;
uso: somente na audiência e escopo previstos;
renovação: limitada, monitorada e protegida contra repetição;
revogação: logout, desligamento, troca de senha, incidente ou mudança crítica;
expiração e descarte: remoção do cliente e do estado no servidor;
auditoria: emissão, falha, renovação, revogação e anomalias, sem registrar o valor do token.

Critérios de aceite desta parte

O emissor, o consumidor, a audiência, os escopos e a validade estão documentados.
Tokens não são gerados no cliente nem por geradores previsíveis.
A escolha entre sessão opaca e JWT tem justificativa arquitetural.
Tokens e códigos de recuperação nunca aparecem em URL, log, analytics ou mensagem de erro.
Existe procedimento de revogação e resposta a vazamento.
Testes cobrem token ausente, adulterado, expirado, revogado, repetido e destinado a outra API.

7. JWT sem mistério

JWT significa JSON Web Token, formato definido na RFC 7519. Um JWT assinado costuma ter três partes codificadas:

header.payload.signature

header: tipo e algoritmo;
payload: declarações (claims);
signature: permite verificar integridade e autenticidade conforme o algoritmo.

Um JWT assinado normalmente não é criptografado. Quem o obtém pode decodificar o conteúdo. Não coloque senha, segredo, CPF ou dado desnecessário no payload.

7.1 Claims importantes

Claim	Significado	Validação esperada
`iss`	emissor	igual ao emissor previamente confiado
`sub`	sujeito	identificador estável do usuário/cliente
`aud`	audiência	inclui exatamente a API atual
`exp`	expiração	ainda não venceu, com tolerância de relógio pequena
`nbf`	não usar antes de	instante já foi alcançado
`iat`	emissão	plausível e compatível com a política
`jti`	identificador do token	útil para rastreio/revogação, sem ser segredo
`scope`/`scp`	ações delegadas	contém a permissão necessária, sem substituir regra de objeto
`typ`	tipo explícito	tipo aceito para este endpoint/contexto

Claims privadas como role, tenant_id ou permissions exigem contrato, namespace e estratégia para alterações. A API ainda deve verificar o objeto: ter role=eletricista não prova que a OS 456 pertence ao shopping daquele usuário.

7.2 Validação correta

Use biblioteca madura e fixe as expectativas na configuração do servidor:

const claims = await jwtVerifier.verify(token, {
  issuer: "https://id.exemplo.com/",
  audience: "api-manutencao",
  algorithms: ["RS256"],
  typ: "at+jwt",
  clockToleranceSeconds: 30
});

if (!claims.scope?.includes("ordens:ler")) {
  throw forbidden();
}

const ordem = await ordens.buscarAutorizada({
  id: ordemId,
  usuarioId: claims.sub,
  tenantId: claims.tenant_id
});

O nome das opções varia por biblioteca. O padrão é o importante: validar assinatura e algoritmo permitido, emissor, audiência, validade, tipo e claims requeridas antes de qualquer uso.

7.3 Falhas clássicas e controles

Falha	Risco	Controle
aceitar `alg: none`	token sem assinatura	lista fixa de algoritmos permitidos
confiar no `alg` do próprio token	confusão de algoritmo/chave	política local e biblioteca atualizada
chave HMAC fraca	assinatura forjada por força bruta	segredo aleatório forte ou chaves assimétricas gerenciadas
não validar `aud`	token de outra API aceito	audiência explícita por API
não validar `iss`	emissor falso aceito	lista fechada de emissores confiáveis
misturar ID token e access token	substituição entre contextos	tipos e regras mutuamente exclusivas
aceitar qualquer `kid`/URL de chave	SSRF ou chave do atacante	JWKS/endpoints pré-configurados e cacheados
validade longa	janela maior após roubo	access token curto e renovação protegida
dados secretos no payload	exposição por leitura/log	minimização; use JWE só quando o caso realmente exigir
logar o JWT inteiro	vazamento secundário	registrar hash parcial/`jti`, nunca a credencial

A RFC 8725 — JWT Best Current Practices exige validação de todas as operações criptográficas, algoritmos explícitos, chaves fortes, validação de emissor/audiência e regras exclusivas para tipos diferentes de JWT.

7.4 Chaves e rotação

mantenha chaves privadas em KMS/HSM/cofre, nunca no repositório;
publique apenas chaves públicas necessárias em JWKS por HTTPS;
use kid controlado para selecionar uma chave conhecida;
planeje sobreposição: a chave nova assina enquanto a antiga ainda valida tokens não expirados;
remova a antiga depois da janela e preserve procedimento emergencial;
monitore falha de assinatura, emissor desconhecido, audiência errada e uso anômalo.

Critérios de aceite desta parte

A aplicação usa biblioteca mantida e não implementa JWT manualmente.
Algoritmos, emissor, audiência e tipo são permitidos por configuração local fechada.
exp, nbf, assinatura e claims obrigatórias são validados.
ID token, access token e outros JWTs não são intercambiáveis.
O payload não contém segredo ou dado pessoal desnecessário.
Rotação normal e emergencial de chaves foi ensaiada.
Testes incluem assinatura inválida, alg não permitido, kid desconhecido, iss/aud errados e token de outro contexto.

8. Expiração, renovação, logout e revogação

8.1 O que acontece quando o token vence?

A API rejeita o access token, normalmente com 401 Unauthorized. O cliente pode tentar uma renovação autorizada. Se ela não existir, falhar ou ultrapassar os limites da sessão, o usuário volta ao login.

Chamada com access token
        │
        ├─ válido → API processa
        │
        └─ expirado → 401
                       │
                       ├─ refresh permitido → novo access token → repetir uma vez
                       └─ refresh negado → limpar credenciais → pedir login

Não faça cada chamada falhar e renovar em paralelo. O cliente deve coordenar uma única renovação, enfileirar requisições seguras e evitar repetição infinita.

8.2 A sessão é renovada enquanto o usuário está ativo?

Isso é uma política, não uma consequência automática do JWT. Uma solução madura combina:

tempo ocioso: encerra após período sem atividade relevante;
tempo absoluto: força nova autenticação mesmo com atividade contínua;
access token curto: limita uso imediato de token roubado;
refresh token: renova dentro da sessão autorizada;
reautenticação: exigida para ação sensível, mudança de senha, dispositivo novo ou risco elevado.

Atividade não deve permitir renovação eterna. Defina explicitamente duração, tolerância, lembrança de dispositivo, múltiplos dispositivos e eventos que derrubam sessões. O NIST SP 800-63B-4 — Session Management é uma referência para políticas baseadas em nível de garantia.

8.3 Refresh token com rotação

Em clientes públicos, quando refresh tokens são usados, o OAuth 2.0 Security BCP — RFC 9700 orienta usar rotação ou tokens vinculados ao emissor (sender-constrained).

R1 usado → servidor invalida R1 e emite R2
R2 usado → servidor invalida R2 e emite R3
R1 reaparece → possível roubo → revogar a família e exigir login

Registre apenas identificadores/digests necessários. Limite por cliente, dispositivo, audiência e escopo. Não entregue refresh token a uma API que só precisa do access token.

8.4 Logout não é só apagar a tela

Um logout completo pode exigir:

revogar a sessão/refresh token no servidor;
invalidar a família de renovação;
remover o cookie com os mesmos Path/Domain e validade expirada;
limpar estado sensível no cliente;
opcionalmente negar access tokens pelo jti até expirarem, conforme risco;
registrar o evento sem registrar a credencial.

JWTs autônomos já emitidos não desaparecem por mágica. As opções são validade curta, lista de revogação, introspecção, versão de sessão/permissão ou arquitetura com estado. Cada uma tem custo operacional.

Critérios de aceite desta parte

A política define validade ociosa, absoluta, do access token e do refresh token.
Renovação é protegida contra repetição e não cria sessão infinita.
Eventos de revogação incluem logout, desligamento, senha/MFA alterados e incidente.
O cliente lida com concorrência, repete no máximo quando seguro e não entra em loop de 401.
Operações sensíveis exigem autenticação recente ou fator adicional conforme risco.
Há testes automatizados do relógio, expiração, rotação, reutilização e revogação.

9. Cookies: HttpOnly, Secure, SameSite e afins

Cookie é um pequeno dado que o servidor pede ao navegador para armazenar e reenviar segundo regras de escopo. Para sessão web, o backend costuma responder:

Set-Cookie: __Host-session=VALOR_OPACO; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

O navegador aplica os atributos:

Atributo	O que faz	O que não faz
`HttpOnly`	impede leitura por JavaScript, como `document.cookie`	não impede que XSS execute ações usando a sessão
`Secure`	envia o cookie somente por conexão segura, salvo detalhes locais definidos pelo navegador	não corrige TLS/proxy mal configurado
`SameSite=Strict`	restringe fortemente envio entre sites	pode prejudicar links e fluxos externos legítimos
`SameSite=Lax`	equilíbrio comum, restringindo vários envios entre sites	não substitui toda defesa CSRF
`SameSite=None`	permite contexto entre sites	exige `Secure` e amplia superfície de CSRF/rastreamento
`Path`	limita o caminho de envio	não é fronteira robusta de autorização
`Domain`	amplia para domínio/subdomínios definidos	pode expor a sessão a subdomínio vulnerável
`Max-Age`/`Expires`	define persistência no navegador	não revoga a sessão no servidor

O prefixo __Host- exige Secure, Path=/ e ausência de Domain, reduzindo ambiguidades de escopo. Consulte a referência atual de Set-Cookie no MDN e a RFC 6265.

9.1 Quem configura?

backend/framework emite Set-Cookie;
navegador aplica os atributos;
proxy/CDN garante HTTPS e preserva o cabeçalho;
frontend não precisa ler um cookie HttpOnly;
QA/AppSec confirma o comportamento no navegador e testa CSRF, XSS e logout.

9.2 Cookie, CSRF e XSS

Cookies são enviados automaticamente, por isso uma operação que altera estado precisa de proteção CSRF quando o modelo for vulnerável. Combine:

SameSite apropriado;
token anti-CSRF ligado à sessão, quando necessário;
verificação de Origin/Referer como defesa adicional;
métodos HTTP corretos: GET não deve alterar estado;
reautenticação para ações críticas.

O OWASP CSRF Prevention Cheat Sheet trata SameSite como defesa em profundidade, não como justificativa para ignorar o desenho completo.

XSS exige saída contextual segura, APIs do DOM seguras, CSP como camada adicional e redução de scripts de terceiros. HttpOnly protege contra leitura direta da credencial, mas não neutraliza a página comprometida.

9.3 Por que evitar tokens de autenticação no `localStorage`?

Qualquer JavaScript que execute naquela origem pode ler o localStorage. Uma dependência comprometida ou XSS pode exfiltrar a credencial. Para web, considere cookie de sessão HttpOnly ou BFF. O OWASP Session Management Cheat Sheet recomenda não armazenar identificadores de sessão e tokens de autenticação em localStorage/sessionStorage.

Critérios de aceite desta parte

Cookie de sessão usa Secure, HttpOnly, SameSite e escopo mínimo documentado.
Domain é omitido quando não é necessário; __Host- é usado quando compatível.
A expiração do navegador e a invalidação do servidor são testadas separadamente.
Operações mutáveis têm proteção CSRF adequada ao fluxo.
Tokens de autenticação não ficam em localStorage, sessionStorage, URL ou código-fonte.
Testes no navegador verificam login, navegação entre sites, múltiplas abas, logout e sessão expirada.

10. OAuth, OpenID Connect, SSO e autenticação corporativa

Esses termos atuam em partes diferentes:

OAuth 2.0: delegação de autorização — o que um cliente pode acessar;
OpenID Connect (OIDC): identidade/login construído sobre OAuth — quem foi autenticado;
SSO: experiência de entrar uma vez e acessar vários sistemas;
SAML: federação/SSO muito comum em ambientes corporativos;
LDAP: protocolo para consultar diretórios;
Active Directory (AD): produto/serviço de diretório da Microsoft;
Kerberos: autenticação baseada em tickets, comum em domínios corporativos.

10.1 Login moderno de usuário

Para aplicativo web, mobile ou desktop, o fluxo padrão moderno é Authorization Code com PKCE:

Aplicativo cria verifier + challenge e state/nonce
       ↓ abre o navegador do sistema
Servidor de identidade autentica e pede consentimento
       ↓ redireciona somente para URI cadastrada, com code
Aplicativo troca code + verifier por tokens
       ↓
API valida access token; aplicativo valida resposta OIDC/ID token

PKCE, definido na RFC 7636, reduz o risco de um código interceptado ser trocado por outra aplicação. O RFC 9700 recomenda correspondência exata de URI, proteção CSRF, não usar o fluxo implícito e não usar o antigo Resource Owner Password Credentials grant.

Em agosto de 2026, OAuth 2.1 ainda é um Internet-Draft, não uma RFC final. Em produção, cite requisitos normativos publicados — OAuth 2.0 mais o RFC 9700 e extensões aplicáveis — e acompanhe a evolução do rascunho.

10.2 ID token não é access token

ID token: afirma ao cliente informações sobre a autenticação, conforme OpenID Connect Core 1.0.
Access token: é destinado a uma API e limitado por audiência/escopo.
Refresh token: serve ao cliente autorizado para obter novos access tokens.

Não envie ID token a uma API “porque também é JWT”. Valide cada tipo com regras exclusivas.

10.3 Sistema com sistema

Quando não existe usuário humano, pode-se usar OAuth Client Credentials, identidade de workload, certificado/mTLS ou mecanismo oficial do provedor:

Serviço A → servidor de autorização: client authentication
Serviço A ← access token de escopo mínimo
Serviço A → API B: Bearer access token

Prefira credenciais de curta duração e identidade de workload a segredos estáticos. Para risco elevado, mecanismos vinculados ao emissor, como mTLS ou DPoP — RFC 9449, podem reduzir o uso de token roubado, mas aumentam a complexidade.

10.4 Perguntas para escolher a solução

Usuários já têm identidade Microsoft/Google/corporativa?
É necessário SSO, MFA ou passkey?
Quem administra desligamentos, grupos e recuperação?
O cliente é web com backend, SPA, mobile, desktop ou serviço?
Quais APIs, audiências e escopos existem?
Há múltiplas empresas (tenants)?
É necessário consentimento do usuário?
Qual ação exige reautenticação?
Há suporte oficial do IdP e bibliotecas certificadas?

Critérios de aceite desta parte

OAuth é usado para autorização e OIDC para identidade quando o caso exige login federado.
Clientes de usuário usam Authorization Code + PKCE e navegador apropriado.
Redirect URIs são exatas; state/nonce e PKCE são validados.
Fluxos implícito e password grant não são usados em novos projetos.
Cada API valida audiência e escopo mínimos; ID token não substitui access token.
Credenciais sistema-sistema são separadas por aplicação e ambiente, rotacionáveis e de menor privilégio.
Desligamento, perda de dispositivo, recuperação e comprometimento têm procedimentos testados.

11. Chamadas, paginação, cotas e rate limit

11.1 Uma requisição não é igual a um registro

Se você chama GET /ordens uma vez e a resposta contém 1.000 ordens, normalmente isso é uma requisição HTTP e 1.000 registros transferidos. Se GET /usuarios retorna dez usuários, também é uma requisição.

O impacto, porém, muda:

bytes transferidos;
memória e CPU para serializar/deserializar;
tempo de banco e rede;
quantidade de dados expostos se houver falha;
custo específico do fornecedor;
chance de timeout e experiência ruim.

Cada provedor define sua cota: chamadas, linhas, bytes, computação, egress, operações de banco ou combinação. Consulte o contrato/documentação; não existe contador HTTP universal.

11.2 Paginação e filtros

Evite “retornar tudo” por padrão:

GET /api/v1/ordens?status=aberta&limit=50&cursor=eyJpZCI6IjEyMyJ9

Resposta:

{
  "items": [
    { "id": "os_123", "status": "aberta" }
  ],
  "nextCursor": "eyJpZCI6IjE3MyJ9"
}

Paginação por cursor tende a ser estável em listas que mudam muito. Limite máximo, ordenação determinística e filtros permitidos devem ser documentados. Para exportações grandes, prefira job assíncrono, arquivo temporário protegido, expiração e auditoria.

11.3 Rate limit e consumo de recursos

Rate limit reduz abuso, mas não é só “X por minuto”. Considere limites por:

IP, usuário, cliente, tenant e endpoint;
operação cara, upload, login e recuperação;
concorrência, tempo, memória, tamanho de body e número de registros;
orçamento de chamadas a terceiros e custos financeiros.

Quando o cliente ultrapassa o limite, 429 Too Many Requests e Retry-After são respostas comuns. Os demais cabeçalhos de limite precisam seguir a documentação da API; não presuma um padrão que o fornecedor não adotou.

O cliente deve usar espera exponencial com variação (jitter), respeitar Retry-After e não repetir automaticamente operações não idempotentes sem proteção. A API deve definir timeout, cancelamento, fila e limite de carga. Isso trata o risco API4:2023 Unrestricted Resource Consumption.

Critérios de aceite desta parte

Listas têm paginação, limite máximo, filtros e ordenação documentados.
Cotas são conhecidas por dimensão e ambiente; alertas antecedem o bloqueio/custo excessivo.
Login, reset, busca cara, exportação e upload têm limites próprios.
Cliente respeita 429/Retry-After e usa retry apenas quando seguro.
Exportação em massa exige permissão, minimização, expiração e trilha de auditoria.
Testes de carga verificam CPU, memória, banco, dependências, timeout e degradação controlada.

12. Segurança de APIs

Uma API segura não é apenas “uma API com token”. Ela precisa verificar identidade, ação, objeto, campos, contexto, consumo de recursos e fluxo de negócio.

12.1 OWASP API Security Top 10:2023 aplicado

Risco oficial	Exemplo prático	Controle e teste mínimo
API1 — autorização quebrada em nível de objeto (BOLA)	usuário troca `/ordens/123` por `/ordens/124` e lê outra empresa	consulta já limitada por usuário/tenant; testes cruzados de ler, editar e excluir
API2 — autenticação quebrada	reset enumera contas; token fraco; login sem limite	IdP maduro, MFA conforme risco, mensagens genéricas, rate limit e testes do ciclo completo
API3 — autorização quebrada em nível de propriedade	cliente envia `{"role":"admin"}` ou recebe campo salarial	DTO/allowlist de entrada e saída; autorização por campo; testes de mass assignment
API4 — consumo irrestrito de recursos	busca sem limite derruba banco ou gera custo em terceiro	paginação, quotas, timeouts, limites de body/arquivo/concorrência e custo
API5 — autorização quebrada em nível de função	usuário comum chama `DELETE /admin/usuarios/5`	negar por padrão; política no servidor para toda função/verbo; testes por perfil
API6 — acesso irrestrito a fluxo sensível	robô compra estoque, envia SMS ou cria milhares de reservas	modelar abuso de negócio, limites contextuais, detecção, confirmação e antifraude
API7 — SSRF	API busca uma URL fornecida e acessa metadados internos	allowlist de destinos, parser seguro, bloqueio de redes internas, egress e redirecionamentos controlados
API8 — configuração insegura	debug, CORS amplo, método desnecessário, erro com stack trace	baseline endurecida, configuração como código, headers, ambientes e verificação contínua
API9 — inventário inadequado	`/v1` abandonada continua pública com dados reais	inventário de hosts/versões/endpoints, dono, classificação e retirada monitorada
API10 — consumo inseguro de APIs	backend confia em resposta de parceiro e grava conteúdo malicioso	validar esquema/limites, autenticar origem, timeout, isolamento e tratar terceiro como não confiável

Veja a lista e os cenários no OWASP API Security Top 10:2023.

12.2 Autorização deve entrar na consulta

Inseguro:

const ordem = await db.ordens.findById(req.params.id);
return ordem; // qualquer usuário autenticado pode tentar qualquer ID

Mais seguro:

const ordem = await db.ordens.findFirst({
  where: {
    id: req.params.id,
    tenantId: req.auth.tenantId,
    allowedUserIds: { has: req.auth.userId }
  },
  select: CAMPOS_PERMITIDOS_PARA_O_PERFIL
});

if (!ordem) return notFound(); // evita revelar a existência indevida

Uma checagem isolada antes da consulta pode sofrer condição de corrida ou ser esquecida. A camada de dados, políticas centralizadas e RLS podem reforçar a regra, sem substituir os testes do backend.

12.3 Entrada, saída e contrato

use OpenAPI/JSON Schema como contrato versionado;
aceite apenas Content-Type, métodos, campos, tipos, tamanhos e valores previstos;
ignore não: rejeite campos sensíveis desconhecidos quando isso revelar erro/ataque;
mapeie entrada para comandos/DTOs, nunca diretamente para entidade do banco;
aplique allowlist de campos de saída por papel e finalidade;
normalize com cuidado; validar antes e depois de transformações relevantes;
gere erros consistentes com Problem Details — RFC 9457, sem stack trace ou segredo.

Exemplo contra atribuição em massa:

const comando = schema.parse(req.body);
// schema permite somente: descricao, prioridade e equipamentoId
await ordens.criar({ ...comando, criadoPor: req.auth.userId, tenantId: req.auth.tenantId });

12.4 Idempotência e repetição

Timeout não diz se o servidor executou a ação. Para criação/pagamento/comando importante:

cliente envia uma Idempotency-Key imprevisível;
servidor associa chave + cliente + operação + hash do corpo;
mesma chave e mesmo corpo devolvem o resultado anterior;
mesma chave com corpo diferente é rejeitada;
registro expira conforme a janela de repetição.

12.5 Inventário e retirada

Para cada API registre: dono, finalidade, dados, exposição, versão, ambiente, autenticação, dependências, data de revisão, consumidores e fim de vida. APIs de desenvolvimento e documentação interativa não devem apontar inadvertidamente para produção.

Critérios de aceite desta parte

Cada endpoint verifica função, objeto, tenant e propriedades autorizadas no servidor.
Há testes negativos entre usuários, papéis, empresas, IDs e métodos.
Contrato rejeita tipos, tamanhos, formatos e campos não permitidos.
Paginação, quota, timeout, concorrência, upload e payload têm limites.
CORS é restrito às origens necessárias e nunca tratado como autorização.
APIs e versões possuem inventário, dono e plano de desativação.
Operações repetíveis/financeiras têm idempotência e proteção contra replay.
Dependências externas são autenticadas, limitadas e validadas como entrada hostil.

13. Segurança do backend

O backend é a fronteira de confiança principal. Tudo que chega do navegador, aplicativo, arquivo, fila, webhook, banco ou serviço parceiro deve ser tratado segundo seu nível de confiança, e não segundo sua aparência.

13.1 Validação e injeção

Validação verifica formato e regra de negócio; codificação/escape protege o contexto de saída; parametrização separa dados de comandos. Uma não substitui a outra.

Inseguro — SQL montado por concatenação:

const sql = `SELECT * FROM usuarios WHERE email = '${req.body.email}'`;
await db.raw(sql);

Seguro — parâmetro separado:

const usuario = await db.query(
  "SELECT id, email FROM usuarios WHERE email = $1",
  [emailNormalizado]
);

Use consultas parametrizadas/ORM corretamente, contas de banco sem poder administrativo e allowlist para partes que não aceitam parâmetro, como nomes de coluna de ordenação. Consulte o OWASP SQL Injection Prevention Cheat Sheet.

O mesmo princípio vale para shell, templates, LDAP, XPath e NoSQL: não transforme entrada em instrução. Evite executar shell; quando inevitável, use API estruturada, argumentos separados, allowlist e usuário isolado.

13.2 SSRF e chamadas de saída

Se o backend aceita uma URL e a acessa, o atacante pode tentar localhost, IP privado, serviço de metadados de nuvem, DNS mutável ou redirecionamento. Controles:

permitir apenas esquemas e destinos necessários;
resolver e verificar IPs públicos permitidos, inclusive após redirecionamento;
bloquear loopback, link-local, redes privadas e metadados na rede/egress;
não encaminhar cookies, tokens ou headers internos;
limitar tamanho, tempo, redirects e tipo de conteúdo;
usar proxy de saída e monitorar destinos.

O OWASP SSRF Prevention Cheat Sheet detalha casos com e sem allowlist.

13.3 Upload de arquivos

extensão e MIME são apenas sinais; valide assinatura/conteúdo quando aplicável;
gere nome no servidor e separe metadados do objeto;
limite tamanho, quantidade e descompressão; proteja contra zip bomb;
armazene fora da raiz executável e, preferencialmente, em domínio isolado;
remova execução, macros/metadados quando o negócio permitir;
faça varredura/sandbox e quarentena;
exija autorização também no download;
use URLs assinadas curtas e registre acesso;
não publique arquivo antes de concluir as verificações.

Referência: OWASP File Upload Cheat Sheet.

13.4 Erros, logs e observabilidade

O cliente recebe mensagem útil e não sensível; internamente, um correlationId liga a resposta ao evento técnico.

Registre eventos de alto valor: login/recuperação, mudança de MFA/senha, negação de acesso, mudança de permissão, exportação, segredo/chave, operação administrativa e validação anômala. Não registre senha, token, cookie, segredo, dados excessivos ou payload integral por conveniência.

Proteja logs contra alteração, limite acesso, sincronize relógios, defina retenção e crie alertas testados. Log sem alerta e responsável é apenas armazenamento.

13.5 Resiliência e condições excepcionais

timeout para banco e cada dependência;
cancelamento e limites de concorrência;
retry somente em falha transitória e operação idempotente, com backoff e jitter;
circuit breaker e fila quando necessários;
transações e compensações para consistência;
comportamento seguro quando autorização, KMS, fila ou terceiro falham;
desligamento limpo, saúde e capacidade;
erro fechado (fail closed) para controle de acesso — sem transformar indisponibilidade em permissão.

Checklist do backend

Toda entrada tem esquema, limite e validação de regra de negócio.
Consultas/comandos usam parâmetros; não há execução dinâmica com entrada.
Autorização é centralizada, negada por padrão e aplicada em toda ação.
SSRF, upload, deserialização, template e processamento de arquivo foram modelados.
Erros não vazam stack, SQL, caminho, configuração, dados ou credenciais.
Logs são úteis, minimizados, protegidos e alimentam alertas exercitados.
Dependências possuem timeout; retries são limitados e seguros.
Contas de processo, banco e nuvem têm menor privilégio e são separadas por ambiente.

14. Segurança do frontend e de aplicativos clientes

Frontend é executado em dispositivo sob controle do usuário. Tudo que está em JavaScript, bundle, aplicativo móvel ou variável “pública” pode ser inspecionado. Portanto:

não coloque segredo, chave privada, service_role, senha de banco ou credencial administrativa;
não confie em campo oculto, botão desabilitado, rota escondida ou role local;
valide no cliente para usabilidade e novamente no servidor para segurança;
trate dados da API, URL, storage, postMessage e terceiros como não confiáveis.

14.1 XSS: dados virando código

Inseguro:

resultado.innerHTML = termoDeBusca;

Mais seguro para texto:

resultado.textContent = termoDeBusca;

Frameworks costumam escapar texto por padrão; recursos como HTML bruto, dangerouslySetInnerHTML ou bypass sanitizer reabrem o risco. Use sanitizador maduro quando HTML do usuário for requisito real, aplique saída correta para cada contexto e nunca tente resolver XSS apenas filtrando <script>.

Uma Content Security Policy (CSP) restritiva reduz impacto, mas é defesa adicional. Comece em modo de relatório, elimine scripts inline/eval, use nonce/hash quando necessário e acompanhe violações. Referências: OWASP XSS Prevention Cheat Sheet e CSP Level 3 do W3C.

14.2 CORS não autentica nem autoriza

CORS é uma política do navegador sobre leitura de respostas entre origens. Clientes fora do navegador podem chamar a API diretamente. Configure uma allowlist exata, métodos/headers necessários, Vary: Origin quando dinâmico e credenciais somente para origens confiáveis. Access-Control-Allow-Origin: * não pode ser a autorização da API.

14.3 Armazenamento, cache e dispositivos

prefira cookie HttpOnly/BFF na web;
em mobile/desktop, use armazenamento seguro oferecido pelo sistema e considere dispositivo comprometido;
não salve dado sensível em cache, analytics, crash report, clipboard ou notificação sem necessidade;
defina Cache-Control: no-store para respostas sensíveis quando apropriado;
limpe dados no logout e na troca de conta;
teste modo offline, cópias locais, screenshots e backups do dispositivo;
não faça certificate pinning sem plano de rotação e recuperação; TLS correto continua obrigatório.

14.4 Dependências e scripts terceiros

Cada tag de analytics/chat/mapa executada na origem pode acessar o que a página acessa. Minimize fornecedores, revise necessidade e dados, fixe versões quando possível, use integridade de sub-recurso para arquivos estáticos compatíveis, CSP e isolamento por iframe/origem. A aprovação jurídica não substitui a revisão técnica.

14.5 Headers de segurança

Headers são definidos pelo backend, proxy/CDN ou servidor de hospedagem e confirmados no navegador. Eles precisam refletir a aplicação real; copiar uma lista sem testar pode quebrar funções ou criar falsa segurança.

Header/política	Finalidade	Observação
`Strict-Transport-Security`	faz o navegador exigir HTTPS após receber a política	use somente quando domínio/subdomínios estiverem preparados; considere preload com cautela
`Content-Security-Policy`	restringe origens e contextos de conteúdo	prefira política restritiva; `frame-ancestors` controla quem pode enquadrar a página
`X-Content-Type-Options: nosniff`	reduz interpretação de conteúdo diferente do MIME declarado	envie também o `Content-Type` correto
`Referrer-Policy`	limita informação da URL enviada como referência	escolha conforme necessidade; evite dado sensível em URL de qualquer forma
`Permissions-Policy`	limita recursos do navegador, como câmera/geolocalização	permita apenas recursos e origens necessários
`Cache-Control`	controla armazenamento de respostas	`no-store` é apropriado para várias respostas sensíveis, após avaliar o fluxo

Políticas COOP/COEP/CORP podem oferecer isolamento adicional, mas têm impacto de compatibilidade e só devem ser ativadas com entendimento e testes. A referência prática é o OWASP HTTP Security Response Headers Cheat Sheet.

Checklist do frontend

Nenhum segredo real está no bundle, repositório, variável pública ou aplicativo distribuído.
HTML/DOM usam saída contextual segura; usos de HTML bruto têm revisão e sanitização.
CSP, headers e scripts terceiros são inventariados e testados.
CORS não é usado como controle de permissão.
Estado de autenticação usa armazenamento adequado; logout e troca de conta limpam dados.
Cache, analytics, telemetria, notificações e mapas de código não expõem dados sensíveis.
Toda ação continua protegida quando o usuário chama a API sem a interface.

15. Segurança do banco de dados e do Supabase

15.1 Controles fundamentais

banco não exposto publicamente sem necessidade e protegido por rede/TLS;
contas distintas por aplicação, migração, leitura, administração e ambiente;
aplicação sem SUPERUSER, criação de usuário ou alteração de schema;
consultas parametrizadas e procedimentos revisados;
privilégios por schema/tabela/coluna somente quando necessários;
dados classificados, minimizados e com retenção/descarte;
criptografia de disco/backup e criptografia de campo quando o modelo de ameaça exigir;
auditoria de acesso administrativo e operações sensíveis;
patches, configuração segura e monitoramento;
backup protegido, imutável quando apropriado e restauração exercitada.

O OWASP Database Security Cheat Sheet reúne práticas de conexão, autenticação, permissões, rede e configuração.

15.2 Row-Level Security (RLS)

RLS permite que o banco aplique políticas por linha. Exemplo conceitual no PostgreSQL:

ALTER TABLE ordens ENABLE ROW LEVEL SECURITY;

CREATE POLICY ordens_por_tenant
ON ordens
USING (tenant_id = current_setting('app.tenant_id')::uuid)
WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

RLS é defesa importante, especialmente multi-tenant, mas precisa de contexto confiável e testes. No PostgreSQL, superusuários, papéis com BYPASSRLS e normalmente o dono da tabela contornam RLS; FORCE ROW LEVEL SECURITY muda parte desse comportamento. Leia a documentação oficial de Row Security do PostgreSQL e teste usando o papel real da aplicação.

15.3 Supabase: chave pública não é autorização

No Supabase:

chave publishable (ou a antiga anon) pode aparecer no cliente; ela identifica o projeto/cliente e depende de RLS/políticas corretas;
chave secret (ou a antiga service_role) é somente servidor e possui acesso elevado; não pode ir ao navegador/aplicativo;
RLS deve ser habilitada e testada em tabelas expostas pela Data API;
regras de Storage e banco são controles diferentes;
funções SECURITY DEFINER, views, RPCs e caminhos alternativos precisam de revisão explícita.

Fontes oficiais: Securing your data, Row Level Security e API keys.

Não confunda backup do banco com backup dos objetos no Storage. A documentação de backups do Supabase informa o escopo; desenhe e teste a recuperação de cada componente.

15.4 Backup, RPO e RTO

RPO: quanto dado a organização aceita perder, por exemplo 15 minutos;
RTO: quanto tempo aceita ficar sem o serviço, por exemplo 2 horas.

Backup “configurado” não é evidência de recuperação. Restaure periodicamente em ambiente isolado, valide integridade, permissões, chaves, objetos externos e tempo real. Proteja backups contra exclusão pela mesma conta comprometida.

Critérios de aceite desta parte

A aplicação usa papel próprio, sem privilégios administrativos ou bypass de RLS.
RLS/políticas foram testadas com dois usuários e dois tenants, incluindo escrita e caminhos RPC/view.
Chaves elevadas e conexão direta existem somente no servidor/cofre.
Produção, teste e desenvolvimento têm dados/credenciais separados; dados reais são mascarados quando necessários fora de produção.
RPO/RTO foram aprovados e restauração completa foi medida e documentada.
Retenção, anonimização/exclusão e auditoria atendem a finalidade e às obrigações aplicáveis.

16. Integrações, webhooks, arquivos, filas e ERP

Integração segura define identidade, formato, entrega, repetição, falha e reconciliação. A tecnologia muda, mas as perguntas permanecem: quem enviou, o que pode enviar, como provar, o que fazer se repetir e como reconciliar?

16.1 API síncrona

autenticação sistema-sistema e escopo mínimo;
contrato/versionamento, timeout e idempotência;
paginação/limites;
validação de resposta do ERP como dado não confiável;
correlação e auditoria sem credenciais.

Evite acesso direto ao banco do ERP sem mecanismo oficial: ele contorna regras, acopla ao schema, dificulta auditoria e pode invalidar suporte.

16.2 Webhook

Um endpoint secreto não é autenticação suficiente. Um padrão robusto usa assinatura sobre bytes exatos do corpo mais timestamp e identificador:

X-Webhook-Id: evt_123
X-Webhook-Timestamp: 1785600000
X-Webhook-Signature: v1=<HMAC-ou-assinatura>

Ao receber:

leia o corpo bruto com limite;
verifique timestamp e janela anti-replay;
calcule/verifique assinatura com comparação constante;
rejeite algoritmo/versão desconhecidos;
grave event_id de forma única;
confirme rapidamente e processe em fila;
torne o consumidor idempotente;
reconcilie periodicamente com a fonte.

Não registre o segredo. Planeje rotação com sobreposição e separe segredo por emissor/ambiente.

16.3 Arquivos e SFTP

conta e diretório próprios, chave/certificado e host key verificados;
criptografia de transporte e, se necessário, do arquivo;
esquema, encoding, tamanho, nome e quantidade validados;
arquivo temporário/quarentena antes de promover;
checksum/assinatura para integridade e origem;
prevenção de path traversal, fórmula perigosa em CSV e conteúdo malicioso;
marcador de processamento idempotente e pasta de erro;
retenção, descarte e reconciliação documentados.

16.4 Filas e eventos

autenticação e ACL por tópico/fila;
esquema versionado e compatibilidade;
identificador único, idempotência e ordenação necessária;
tentativas limitadas, dead-letter queue e alerta;
criptografia e minimização de payload;
retenção compatível com privacidade;
não considerar “entregue” igual a “processado com sucesso”.

Critérios de aceite desta parte

Cada integração possui dono, contrato, ambiente de teste, credenciais e matriz de dados.
Falhas, repetição, ordem, timeout, reconciliação e retirada estão documentados.
Webhooks têm autenticação criptográfica, anti-replay e idempotência.
Arquivos são validados e colocados em quarentena antes do uso.
Filas têm DLQ, limites, monitoramento e reprocessamento seguro.
Não há acesso direto não autorizado a banco de ERP nem usuário técnico compartilhado sem rastreabilidade.

17. Criptografia, chaves e segredos

17.1 Comece pela finalidade

Criptografia não corrige coleta excessiva. Antes, pergunte:

precisamos deste dado?
por quanto tempo?
quem realmente precisa ler?
precisa ser pesquisável ou pode ser tokenizado/anonimizado?
qual impacto de exposição, alteração e indisponibilidade?

17.2 Em trânsito e em repouso

Use HTTPS/TLS moderno em interfaces externas e internas conforme ameaça. A RFC 9325 é a prática atual para TLS: não usar SSL/TLS 1.0/1.1, suportar TLS 1.2 e preferir/suportar TLS 1.3. HSTS ajuda o navegador a exigir HTTPS após política válida.

Em repouso, criptografia de disco/serviço protege mídia e snapshots, mas não impede a aplicação comprometida de ler dados. Criptografia de campo ou tokenização pode reduzir acesso, desde que chaves e consultas sejam redesenhadas. Não invente algoritmo ou protocolo.

17.3 Segredo não é configuração comum

Segredos incluem senhas de banco, chaves de API, private keys, client secrets, signing keys e tokens administrativos.

armazene em secret manager/KMS/HSM conforme o caso;
conceda acesso por identidade de workload, não por segredo permanente quando possível;
separe por ambiente, serviço e finalidade;
injete em tempo de execução, sem gravar em imagem, repositório ou log;
inventarie dono, uso, data, rotação e consumidores;
rotacione automaticamente quando possível e ensaie emergência;
revogue ao desligar serviço/pessoa;
procure vazamentos em commits, artefatos, tickets, chat e telemetria.

Se um segredo foi commitado, removê-lo do último commit não basta: trate como comprometido, revogue/rotacione e investigue histórico, forks, caches e artefatos. O OWASP Secrets Management Cheat Sheet detalha o ciclo de vida.

17.4 Gestão de chaves

chave tem identificador, propósito, algoritmo, tamanho, dono, origem e validade;
geração usa fonte criptográfica aprovada;
chaves de assinatura, criptografia e ambientes não são reutilizadas;
acesso administrativo exige separação de funções e auditoria;
rotação preserva leitura/validação do legado pelo tempo necessário;
backup/escrow só quando requerido e protegido;
destruição é verificável;
compromisso aciona revogação, reemissão, recriptografia quando necessária e comunicação.

Critérios de aceite desta parte

Há inventário de dados, segredos, certificados e chaves com dono e ciclo de vida.
TLS e certificados são monitorados; protocolos/cifras obsoletos estão desabilitados.
Nenhum segredo está em código, imagem, frontend, log, ticket ou documentação aberta.
Serviços usam menor privilégio e credenciais curtas/identidade de workload quando disponíveis.
Rotação normal e emergencial foi testada sem indisponibilidade indevida.
Algoritmos, bibliotecas e parâmetros são aprovados e revisados; não existe criptografia caseira.

18. DevSecOps e cadeia de suprimentos

DevSecOps significa inserir segurança no planejamento, código, revisão, build, teste, entrega, operação e resposta — com automação e responsabilidade humana. Scanner no fim do projeto não substitui projeto seguro.

O NIST Secure Software Development Framework 1.1 organiza práticas em quatro grupos:

preparar a organização;
proteger o software contra adulteração;
produzir software bem protegido;
responder a vulnerabilidades.

18.1 Antes do código

classifique dados e impacto;
desenhe fluxo de dados e fronteiras de confiança;
faça modelagem de ameaças com negócio, arquitetura, desenvolvimento e operação;
defina requisitos verificáveis com base em risco;
escolha dependências/provedores suportados;
defina ASVS, SLAs de correção, logging, RPO/RTO e resposta;
registre riscos aceitos e controles compensatórios.

Perguntas simples para cada fluxo: o que protegemos, de quem, como pode falhar, como prevenimos, como detectamos e como recuperamos? Consulte o OWASP Threat Modeling Cheat Sheet.

18.2 Repositório e revisão

MFA resistente a phishing para administradores quando disponível;
acesso mínimo, contas individuais e revisão periódica;
branch protegida, revisão obrigatória e regras para código crítico;
commits/tags/artefatos assinados conforme risco;
detecção de segredos antes e depois do push;
alterações de pipeline, permissões, IaC, auth e migração recebem revisão especializada;
não permitir que o autor aprove sozinho exceções críticas;
backup e recuperação do repositório/configurações.

18.3 Pipeline e verificações

Uma pipeline baseada em risco pode incluir:

Verificação	Encontra principalmente	Limite
lint/compilação/testes	defeitos e regressões conhecidas	depende da qualidade dos testes
SAST	padrões perigosos no código	falsos positivos/negativos e pouco contexto de negócio
SCA	dependências vulneráveis/licenças	inventário e advisories podem estar incompletos
secret scanning	credenciais conhecidas/alta entropia	segredo ofuscado ou fora do alcance pode escapar
IaC/container scan	configuração e pacotes de imagem	estado real pode divergir
DAST/API test	comportamento executado	cobertura limitada ao que foi exercitado
teste de autorização	BOLA/BFLA/tenant	precisa de cenários de negócio e identidades reais de teste
SBOM/proveniência	composição e origem do build	não afirma que o software é seguro por si só

Falha crítica confirmada deve impedir promoção. Exceção exige risco, dono, prazo e controle compensatório — não simples clique para “ignorar”.

18.4 Dependências e build

use registros aprovados e verifique nome/origem de pacotes;
fixe versões e integridade com lockfile, mas mantenha processo de atualização;
remova dependências não usadas e scripts de instalação desnecessários;
gere SBOM por versão e guarde junto ao artefato;
proteja runners e tokens de CI, preferindo credenciais efêmeras;
separe build de código não confiável do ambiente de release;
gere uma vez e promova o mesmo artefato entre ambientes;
produza proveniência verificável e assine artefatos quando o risco justificar;
monitore vulnerabilidade e comprometimento depois da entrega.

A SLSA 1.2 fornece níveis e requisitos para aumentar confiança na proveniência e no processo de build. O OWASP Software Supply Chain Security Cheat Sheet reúne controles de dependência, build, distribuição e consumo.

18.5 Ambientes e implantação

desenvolvimento, homologação e produção isolados;
credenciais e dados diferentes; dados produtivos mascarados fora de produção;
infraestrutura/configuração como código revisada;
mudanças aprovadas e auditadas, com rollback;
implantação progressiva quando apropriado;
feature flags sem segredos e com dono/expiração;
patches de runtime/SO/imagem aplicados com SLA;
configuração real verificada continuamente contra o baseline;
conta de deploy não é conta administrativa permanente.

Critérios de aceite desta parte

A ameaça e os requisitos de segurança foram revisados antes da implementação.
Branch, CI, registry e produção usam MFA/acesso mínimo e trilha de auditoria.
SAST, SCA, segredos, IaC/container e testes de autorização rodam conforme risco.
Achados têm severidade, proprietário, SLA, evidência de correção e reteste.
Cada release tem versão, commit, SBOM, resultados de gates e artefato reproduzível/rastreável.
Dependências e imagens são monitoradas também depois da implantação.
Implantação e rollback foram testados; ambientes e credenciais são separados.

19. Código produzido com IA e “vibe coding”

Código gerado por IA deve cumprir os mesmos critérios do código escrito manualmente. A origem não reduz a responsabilidade do autor, revisor, empresa ou fornecedor. O risco adicional vem da velocidade, confiança indevida e acesso da ferramenta a repositório, terminal, segredos e serviços.

19.1 Falhas específicas frequentes

Risco	Exemplo	Controle
pacote inventado/slopsquatting	IA sugere dependência que não existe; atacante publica o nome	verificar registro oficial, mantenedor, histórico, assinatura e necessidade antes de instalar
versão obsoleta/vulnerável	exemplo treinado em API antiga	documentação oficial da versão instalada, SCA e testes
segurança “cenográfica”	middleware existe, mas não cobre uma rota	testes de integração/negativos e revisão do fluxo completo
autorização só na interface	IA esconde botão de excluir	autorização no backend/banco e teste direto da API
prompt injection indireta	issue, README ou página manda agente exfiltrar segredo	tratar conteúdo como não confiável, restringir ferramentas/rede e exigir aprovação para ações sensíveis
ferramenta/MCP excessiva	agente possui acesso a produção, e-mail ou cofre sem necessidade	menor privilégio, ambiente isolado, allowlist e logs de ferramenta
edição fora do escopo	agente altera pipeline, autenticação ou testes	diff pequeno, escopo declarado, proteção de arquivos e revisão obrigatória
teste enfraquecido	para “ficar verde”, código remove assertiva	proteger testes/gates; revisar motivo e cobertura, não só resultado
vazamento de contexto	segredo/cliente é colado em prompt ou log	política de dados, redaction, ferramenta aprovada e prevenção de segredo
código plausível, regra errada	fluxo aprova a própria solicitação	critérios de negócio, exemplos adversariais e aceite pelo dono do processo

O OWASP Secure Coding with AI Cheat Sheet recomenda regras versionadas, ambiente restrito, validação de dependências, revisão humana, proteção de testes e controle de ferramentas.

19.2 Fluxo seguro para assistência de IA

Tarefa e critérios explícitos
        ↓
Contexto mínimo, sem segredos
        ↓
Geração em branch/sandbox de baixo privilégio
        ↓
Revisão do diff, dependências e permissões
        ↓
Testes funcionais + negativos + scanners
        ↓
Revisor responsável aprova
        ↓
Pipeline normal promove o artefato

Nunca conceda produção apenas porque a tarefa “é mais rápida com agente”. Credenciais devem ser temporárias, limitadas e fora do contexto do modelo quando possível. Toda ação externa ou destrutiva necessita fronteira clara e autorização correspondente.

Checklist para código com IA

O repositório define regras de segurança, escopo permitido e arquivos protegidos.
A ferramenta usa conta/ambiente isolado, sem segredo ou produção por padrão.
Cada dependência sugerida foi verificada em fonte oficial e escaneada.
O revisor entende cada alteração crítica; não aprovou apenas porque testes passaram.
Testes não foram removidos, ignorados ou alterados para ocultar falha.
Autenticação, autorização, criptografia, pipeline e migração recebem revisão especializada.
Prompts, contexto, logs e telemetria não contêm dados/credenciais indevidos.
Saída passa pelo mesmo CI, critérios de aceite, assinatura e monitoramento do código humano.

20. Falhas comuns e como evitá-las

O OWASP Top 10:2025 organiza riscos atuais de aplicações web. A tabela traduz as categorias em ações de projeto:

Categoria	Sinal comum	Prevenção principal	Prova
A01 Broken Access Control	troca de ID revela dado; endpoint administrativo funciona	negar por padrão, checar objeto/função/tenant no servidor	testes cruzados de papéis e objetos
A02 Security Misconfiguration	debug, bucket público, CORS/headers permissivos	baseline seguro, IaC, inventário e verificação contínua	configuração exportada + scan do ambiente real
A03 Software Supply Chain Failures	pacote comprometido, pipeline alterada	dependência aprovada, SBOM, CI isolada, proveniência	SBOM e rastreio release→commit→build
A04 Cryptographic Failures	HTTP, chave no código, dado sensível desnecessário	TLS, KMS/cofre, algoritmos aprovados e minimização	teste TLS, inventário e rotação ensaiada
A05 Injection	SQL/shell/template construído com texto	parametrização, APIs estruturadas, validação contextual	testes e análise de sinks perigosos
A06 Insecure Design	abuso possível mesmo sem “bug” técnico	ameaça, regras, limites e cenários de mau uso	threat model + testes de abuso de negócio
A07 Authentication Failures	sessão infinita, reset fraco, MFA contornável	IdP maduro, MFA, política de sessão e recuperação equivalente	testes ponta a ponta e eventos de auditoria
A08 Software or Data Integrity Failures	update/build/dado não verificado	assinatura, origem, schema, revisão de pipeline	verificação de assinatura/proveniência
A09 Security Logging and Alerting Failures	ataque ocorre sem alerta acionável	eventos úteis, proteção, correlação, alerta/runbook	simulação detectada e respondida
A10 Mishandling of Exceptional Conditions	timeout libera acesso, retry duplica cobrança	fail closed, idempotência, limites e tratamento explícito	testes de dependência indisponível e caos controlado

20.1 Antipadrões por camada

Produto/gestão

pedir “login seguro” sem perfis, impacto, recuperação ou aceite;
manter dado “caso um dia precise”;
aceitar risco verbal sem dono/prazo;
medir entrega somente por tela funcionando.

Frontend

segredo em variável “oculta”;
autorização por botão;
token em URL/localStorage;
HTML bruto e script terceiro sem controle;
acreditar que CORS bloqueia atacantes.

Backend/API

autenticar e esquecer autorização por objeto;
aceitar entidade inteira enviada pelo cliente;
SQL/comando concatenado;
lista/exportação sem limite;
erro com stack/segredo;
retry indiscriminado e nenhuma idempotência.

Banco

usuário da aplicação como administrador;
RLS habilitada, mas bypassada pelo papel real;
ambiente de teste com cópia integral de produção;
backup sem restauração;
service_role/secret no frontend.

Infraestrutura/DevOps

segredo em CI/log/imagem;
painel administrativo exposto;
imagem latest e dependências sem inventário;
exceção de scanner permanente;
produção alterada manualmente sem trilha.

Operação

coletar logs sem alerta;
alerta sem dono/runbook;
certificado/segredo expirar sem aviso;
nenhum exercício de incidente, restore ou revogação.

21. Checklist mestre e critérios de aceite

Esta seção amplia o item 26 da conversa original. Use-a como base de projeto e ajuste após análise de risco. Para a maioria das aplicações de produção, o OWASP ASVS 5.0 nível 2 é uma referência de verificação útil; nível 3 atende casos de alta garantia. Isso não elimina requisitos setoriais, legais ou contratuais.

21.1 Governança e arquitetura

Dono do produto, dados, segurança, operação e cada integração estão nomeados.
Dados têm classificação, finalidade, base aplicável, retenção e descarte.
Diagrama mostra fluxos, fronteiras de confiança, terceiros e ambientes.
Modelagem de ameaças cobre fluxos normais, abuso, fraude e condições excepcionais.
Requisitos usam padrão definido (ASVS/API Security) e nível baseado em risco.
Exceções têm risco, compensação, aprovador, responsável e validade.
Terceiros têm requisitos, notificação de incidente, manutenção e saída contratual.

Aceite: diagrama, classificação, threat model e matriz de responsabilidades aprovados e versionados; nenhum fluxo crítico fica sem dono ou requisito testável.

21.2 Identidade, senha, MFA e recuperação

Identidade é individual; contas compartilhadas são eliminadas ou formalmente controladas.
Senhas usam hash próprio para senha, salt único e parâmetros versionados.
Política bloqueia senhas comprometidas, permite gerenciador/colar e evita troca periódica arbitrária.
MFA/passkeys são exigidos para administradores e conforme risco.
Recuperação, troca de e-mail/telefone e remoção de MFA não são mais fracas que o login.
Mensagens e tempos não enumeram contas de forma útil.
Tentativas e automação são limitadas sem criar lockout abusável.
Desligamento e comprometimento revogam sessões/credenciais rapidamente.

Aceite: testes automatizados e manuais demonstram cadastro, login, MFA, recuperação, bloqueio de senha comprometida, enumeração, revogação e reautenticação.

21.3 Autorização

Matriz define sujeito, ação, recurso, campo, tenant e condições.
Servidor nega por padrão e verifica toda requisição.
Interface não é fronteira de segurança.
Consulta ao banco limita objeto/tenant; RLS reforça quando aplicável.
Administração, suporte/impersonação e exportação têm controles e auditoria adicionais.
Mudanças de papel/permissão são aprovadas, notificadas e entram em vigor no prazo definido.

Aceite: suíte com pelo menos dois usuários, papéis e tenants prova que leitura, criação, edição, exclusão, busca e exportação cruzadas são negadas.

21.4 Sessões, tokens, JWT e cookies

Emissor, cliente, API, audiência, escopos e tipos de token estão documentados.
Access tokens são curtos; sessão tem limites ocioso e absoluto.
Refresh usa rotação/reuso detectado ou mecanismo vinculado ao emissor conforme o cliente.
JWT valida assinatura, algoritmo permitido, iss, aud, exp, nbf e typ.
ID token não é aceito como access token.
Chaves possuem KMS/cofre, rotação, kid controlado e plano emergencial.
Web usa cookie Secure, HttpOnly, SameSite e escopo mínimo/BFF quando adequado.
Token não está em URL, log, localStorage/sessionStorage ou analytics.
Logout e eventos críticos revogam sessão no servidor.

Aceite: matriz de testes inclui ausência, adulteração, replay, algoritmo não permitido, emissor/audiência/tipo errados, expiração, concorrência de refresh, reutilização, logout e rotação de chave.

21.5 Frontend e cliente

Nenhuma credencial privilegiada é distribuída ao cliente.
Saída é codificada por contexto; HTML bruto exige sanitização/revisão.
CSP e scripts terceiros seguem inventário e política.
CSRF é tratado no desenho de cookie e ações mutáveis.
CORS usa origens exatas quando necessário e não substitui autorização.
Cache, offline, clipboard, notificação, screenshot, telemetria e source maps foram avaliados.
Atualização do app e armazenamento local usam mecanismos da plataforma.

Aceite: teste no navegador/dispositivo confirma XSS/CSRF, sessão, cache, logout/troca de conta, dados locais e chamada direta da API.

21.6 Backend e API

Contrato define tipos, campos, limites, exemplos e erros.
Entrada usa allowlist/esquema; saída minimiza campos.
SQL/comando/template nunca concatena entrada; consultas são parametrizadas.
BOLA, BFLA e atribuição em massa têm testes negativos.
Paginação, payload, upload, timeout, concorrência e custo são limitados.
Operações críticas têm idempotência e proteção contra replay.
SSRF e egress são restritos; respostas de terceiros são validadas.
Erros não revelam implementação/segredos; correlação permite investigação.
APIs/versões têm inventário e retirada.

Aceite: OpenAPI validada, suíte de integração/abuso, teste de carga e relatório de API Security sem achado crítico/alto aberto fora de exceção aprovada.

21.7 Banco, arquivos e dados

Papéis separados e menor privilégio; aplicação não é administradora.
Rede/TLS, patches, configuração e auditoria estão ativos.
RLS foi testada com o papel de produção e não é contornada por owner/bypass.
Chave elevada do Supabase permanece somente no servidor.
Arquivos têm validação, quarentena, storage isolado e autorização de download.
Dados fora de produção são sintéticos ou mascarados.
RPO/RTO são aprovados; backup inclui todos os componentes necessários.
Restore completo, integridade e tempo foram testados.

Aceite: grants/policies exportados, testes multi-tenant, relatório de restauração e amostra de auditoria comprovam os controles.

21.8 Infraestrutura, segredos e criptografia

HTTPS/TLS moderno, HSTS onde aplicável e certificados monitorados.
Secret manager/KMS/HSM protege segredos e chaves conforme risco.
Credenciais são separadas por ambiente/serviço e preferencialmente efêmeras.
Painéis, portas, buckets e serviços não necessários não estão públicos.
Configuração/IaC tem baseline, revisão e detecção de desvio.
Imagens são mínimas, sem segredo, com identidade não-root quando aplicável.
Rotação normal/emergencial e expiração são monitoradas.

Aceite: scan externo/interno, inventário, política de acesso, teste de rotação e comparação do estado real contra IaC não apresentam exposição indevida.

21.9 DevSecOps e cadeia de suprimentos

Repositório/CI/registry têm MFA, acesso mínimo e branches protegidas.
Testes, SAST, SCA, segredo, IaC/container e DAST/API rodam conforme risco.
Dependências são verificadas, fixadas, atualizadas e removidas quando ociosas.
Release tem SBOM, proveniência, assinatura quando aplicável e rastreio ao commit.
Build usa ambiente isolado e credenciais temporárias; artefato é promovido sem recompilar.
Vulnerabilidades têm triagem, SLA, reteste e monitoramento pós-release.
Alterações com IA passam pelos mesmos gates e revisão humana responsável.

Aceite: uma release amostrada pode ser rastreada do requisito ao commit, revisores, build, SBOM, resultados, artefato e implantação.

21.10 Logs, detecção, operação e resposta

Eventos de segurança e negócio críticos estão definidos e correlacionados.
Logs não contêm senha, token, cookie, segredo ou dado excessivo.
Acesso, integridade, retenção e relógios dos logs são controlados.
Alertas possuem limiar, dono, canal, severidade e runbook.
Saúde, capacidade, abuso, custo, erro e dependência são monitorados.
Plano cobre segredo/token, conta, dado, dependência e disponibilidade.
Exercícios de revogação, incidente, rollback e restore geram melhorias.

Aceite: simulação controlada dispara alerta, chega ao responsável, segue runbook, produz linha do tempo e comprova contenção/recuperação.

21.11 Definition of Done de segurança

Uma funcionalidade sensível só está pronta quando:

ameaça, dados e permissões foram revisados;
critérios positivos e negativos passaram;
código/configuração têm revisão apropriada;
scanners e dependências foram tratados;
logs/alertas/runbook existem;
documentação e inventário estão atualizados;
riscos residuais foram aceitos por quem possui autoridade;
há evidência reproduzível ligada à versão entregue.

“Implementado” sem teste e evidência significa não verificado.

22. O que solicitar ao desenvolvedor ou fornecedor

Não peça apenas “uma API segura”. Entregue contexto de negócio e solicite artefatos verificáveis.

22.1 Informações que você precisa fornecer

objetivo e ações de negócio;
tipos de usuário, empresas/tenants e responsáveis;
matriz de consultar, criar, editar, aprovar, exportar, administrar e excluir;
campos, obrigatoriedade, sensibilidade, origem e destino;
volume, simultaneidade, tamanho, frequência e crescimento;
disponibilidade, RPO, RTO e períodos críticos;
sistemas/ERP/IdP/banco/terceiros e responsáveis por liberar acesso;
ambientes e dados de teste;
requisitos legais, contratuais e de auditoria;
risco aceitável e quem pode aceitar exceções.

22.2 Perguntas que o fornecedor precisa responder

Qual arquitetura e quais fronteiras de confiança foram escolhidas?
Quem autentica usuários e serviços? Há MFA, SSO e recuperação?
Como autorização por papel, objeto, campo e tenant é aplicada e testada?
Qual é o ciclo de access/refresh/session token? Onde cada credencial fica?
Como JWT, cookies, CSRF, CORS, TLS e chaves são configurados?
Quais limites protegem lista, busca, upload, exportação, login e terceiros?
Como a API valida entrada, saída e respostas de integrações?
Quais dados são guardados, por quê, por quanto tempo e em quais países/provedores?
Como segredos, dependências, pipeline, SBOM e releases são protegidos?
Quais logs, alertas, SLAs de vulnerabilidade e procedimentos de incidente existem?
Como backup/restore, rotação, revogação, rollback e continuidade foram testados?
Quais riscos residuais e dependências externas permanecem?

22.3 Entregáveis mínimos

Entregável	Conteúdo mínimo	Como aceitar
arquitetura e fluxo de dados	componentes, fronteiras, dados, terceiros e ambientes	revisão conjunta e versão ligada ao release
modelagem de ameaças	cenários, impacto, controles, dono e risco residual	cenários críticos têm tratamento/teste
documentação OpenAPI	endpoints, schemas, auth, erros, limites e exemplos	lint/contract tests passam
matriz de acesso	papel, ação, recurso, campo, tenant e condição	testes negativos rastreados à matriz
desenho de identidade	IdP, OAuth/OIDC, redirect, sessão, MFA, recuperação e revogação	demonstração de fluxos normais e adversariais
baseline de segurança	TLS, cookies, headers, CORS, rede, banco e secrets	verificação no ambiente real
plano/testes	unitário, integração, abuso, autorização, carga e segurança	relatório com versão, escopo, resultado e reteste
inventários	APIs, dados, dependências, SBOM, segredos/chaves e terceiros	dono e ciclo de vida para cada item
operação	dashboards, alertas, runbooks, on-call, backup/restore e incidente	exercício observado e evidência
vulnerabilidades	canal, triagem, SLA, exceção e divulgação	processo e amostra de correção/reteste
entrega	commit, aprovações, build, proveniência, artefato e implantação	rastreabilidade ponta a ponta

22.4 Texto-base para contratação

A solução deverá demonstrar controles de segurança proporcionais ao risco e critérios verificáveis, usando OWASP ASVS 5.0 nível 2 como referência inicial, além do OWASP API Security Top 10:2023 e requisitos aplicáveis. O fornecedor entregará arquitetura e fluxo de dados, modelagem de ameaças, matriz de autorização, OpenAPI, SBOM, resultados de testes, inventário de dependências/segredos/terceiros, evidências de pipeline e runbooks de operação, revogação, incidente, backup e restauração. Achados e exceções deverão possuir severidade, responsável, prazo, controle compensatório e aprovação do dono do risco. A aceitação dependerá de testes positivos e negativos e da rastreabilidade da evidência à versão entregue.

Adapte o nível ASVS e obrigações ao impacto. Um contrato não prova segurança; ele cria responsabilidade e condições de verificação.

23. Como acompanhar status sem aceitar respostas vagas

Status útil responde: o que foi feito, em qual versão/ambiente, qual evidência prova, o que falta, qual risco, quem é o dono e quando será reavaliado?

23.1 Vocabulário de status

Status	Significado objetivo	Evidência
não iniciado	requisito aceito, sem trabalho verificado	responsável e data planejada
em levantamento	dependências/regras ainda sendo mapeadas	perguntas abertas e decisores
em implementação	alteração em desenvolvimento	branch/issue e critérios de aceite
em revisão	código/configuração aguardando revisão	diff, revisores e achados
implementado, não verificado	mudança existe, teste independente ainda não confirmou	versão/ambiente e teste agendado
verificado	critérios passaram no escopo informado	relatório automatizado/manual rastreável
homologado	dono do negócio confirmou comportamento e impacto	aceite e versão
em produção	artefato identificado foi implantado	release/deployment e monitoramento
bloqueado	impedimento concreto impede avanço	dependência, dono, impacto e próxima ação
risco aceito temporariamente	falha conhecida foi formalmente aceita	aprovador autorizado, compensação e validade
corrigido e retestado	correção passou no mesmo caso e em regressão	evidência antes/depois e release

“Pronto”, “seguro”, “scanner passou” ou “usa JWT” não são status suficientes.

23.2 Exemplo de status bem escrito

Requisito: impedir leitura de OS entre empresas.
Status: implementado, não verificado.
Versão/ambiente: build 2026.08.01-rc3 em homologação.
Mudança: consulta agora exige ordem.id + token.tenant_id; RLS adicionada.
Evidência atual: revisão de código #482 e migração #117.
Falta: teste com usuários A/B e service role; reteste previsto para 03/08.
Risco atual: alto se publicado sem o teste.
Dono: equipe Backend; validação: AppSec/QA.

23.3 Perguntas de acompanhamento

O teste usou a identidade e o papel reais de produção?
Incluiu caso negado, adulterado, expirado e de outro tenant?
O ambiente reproduz proxy, gateway, banco e configuração de produção?
Qual commit/build foi testado e esse mesmo artefato será promovido?
Houve mudança de dependência, permissão, infraestrutura ou migração?
O achado foi corrigido ou apenas silenciado/aceito?
O controle gera alerta e alguém ensaiou o runbook?

24. Resposta a incidentes e vulnerabilidades

Prevenção falha. A organização precisa detectar, conter, recuperar e aprender. O NIST SP 800-61 Rev. 3 integra resposta a incidentes à gestão de risco do NIST CSF 2.0.

24.1 Preparação mínima

responsáveis, substitutos, contatos e autoridade de decisão;
classificação de severidade e critérios de acionamento;
inventário de ativos, dados, identidades, terceiros e dependências;
logs, relógios, retenção e acesso de emergência;
canais fora do sistema possivelmente comprometido;
runbooks para conta, token/segredo, dado, malware, dependência e indisponibilidade;
capacidade de revogar, bloquear, rotacionar, isolar, restaurar e comunicar;
obrigações de notificação e preservação de evidência validadas com jurídico/privacidade;
exercícios e melhorias rastreadas.

24.2 Se um token ou segredo vazar

trate como comprometido; não espere prova de abuso;
preserve evidências e identifique alcance, ambiente, privilégios e consumidores;
revogue/rotacione a credencial e encerre sessões/famílias relacionadas;
bloqueie/limite o caminho de abuso e remova a origem do vazamento;
busque uso histórico em logs, sem espalhar novamente o valor;
reemita dependências afetadas e valide recuperação;
comunique conforme impacto/obrigação;
corrija a causa: log, commit, frontend, ticket, CI, fornecedor ou permissão;
revise credenciais equivalentes e melhore detecção/testes.

Rotacionar antes de entender consumidores pode causar indisponibilidade; esperar para sempre mantém o invasor. O runbook deve permitir rotação coordenada e rápida.

24.3 Recebimento de vulnerabilidades

Publique um canal monitorado, política de boa-fé e informações de contato. Um arquivo /.well-known/security.txt, conforme a RFC 9116, ajuda pesquisadores a encontrar o canal. Defina:

confirmação de recebimento;
triagem/severidade;
comunicação e prazo;
correção, teste e divulgação coordenada;
proteção de dados e evidências;
aprendizado e prevenção de recorrência.

Critérios de aceite desta parte

Runbooks possuem decisões, comandos/processos seguros, donos e dependências.
Contatos e acessos de emergência funcionam fora do canal principal.
Revogação/rotação e restore foram exercitados no prazo esperado.
Uma simulação produziu alerta, linha do tempo, contenção e ações de melhoria.
Canal de vulnerabilidade é monitorado e tem SLA de confirmação/triagem.

25. Glossário

Termo	Explicação simples
API	contrato/interface para sistemas trocarem dados e ações
endpoint	método e endereço de uma operação da API
HTTP	protocolo de requisição e resposta usado na web
HTTPS	HTTP protegido por TLS
JSON	formato textual de dados; não é linguagem executável como Java
header	metadado da requisição/resposta, como tipo ou autorização
body	conteúdo da requisição/resposta
autenticação (AuthN)	provar quem é o sujeito
autorização (AuthZ)	decidir o que o sujeito pode fazer naquele contexto
IdP	provedor de identidade que autentica e emite afirmações/credenciais
IAM	gestão de identidades, autenticação, papéis, políticas e ciclo de acesso
sessão	período/estado autenticado entre cliente e serviço
cookie	dado que o navegador armazena e envia conforme atributos
token	credencial que representa sessão, identidade ou autorização
Bearer	modelo em que quem apresenta o token pode usá-lo; exige proteção contra roubo
JWT	formato de token com claims, frequentemente assinado e não criptografado
claim	declaração dentro de um token, como emissor, sujeito ou audiência
access token	credencial apresentada a uma API
refresh token	credencial para obter novos access tokens dentro de uma sessão autorizada
ID token	afirmação OIDC destinada ao cliente sobre autenticação/identidade
OAuth 2.0	estrutura de autorização delegada
OIDC	camada de identidade sobre OAuth 2.0
SSO	experiência de login único entre sistemas
SAML	padrão de federação muito usado em SSO corporativo
LDAP	protocolo de consulta/alteração de diretórios
Active Directory	serviço de diretório e identidade da Microsoft
Kerberos	protocolo de autenticação baseado em tickets
MFA	autenticação com fatores de categorias diferentes
passkey/WebAuthn	autenticação por credencial de chave pública, resistente a phishing quando corretamente usada
RBAC	permissão baseada em papéis/funções
ABAC	permissão baseada em atributos e contexto
RLS	política do banco que controla linhas acessíveis
tenant	organização/cliente lógico dentro de uma solução multiempresa
CORS	política do navegador para acesso entre origens; não é autorização
CSRF	induzir navegador autenticado a enviar ação indesejada
XSS	executar conteúdo não confiável como código na página
SSRF	induzir servidor a acessar destino indevido
SQL injection	transformar entrada em parte do comando SQL
rate limit	limite de consumo em uma janela/condição
idempotência	repetir a mesma solicitação sem multiplicar o efeito
webhook	notificação HTTP enviada quando um evento ocorre
SBOM	inventário dos componentes de uma versão de software
SAST/DAST/SCA	análise de código, teste dinâmico e análise de dependências
DevSecOps	segurança integrada ao desenvolvimento, entrega e operação
KMS/HSM	serviços/dispositivos para proteger e operar chaves criptográficas
RPO/RTO	perda máxima de dados e tempo máximo de recuperação aceitos
SIEM/SOC	plataforma de análise de eventos e equipe de operação de segurança
BFF	backend dedicado ao frontend, útil para manter credenciais fora do JavaScript
BOLA/BFLA	falha de autorização por objeto/função em APIs
CVE/CVSS	identificador público de vulnerabilidade e sistema de pontuação de severidade
zero trust	não confiar pela localização; verificar identidade, contexto e privilégio continuamente

26. Fontes oficiais e normas

Fontes consultadas e válidas na data de atualização deste guia. A segurança evolui; confirme versões no início e antes da entrega de cada projeto.

OWASP — verificação e riscos

OWASP — implementação

NIST e CISA — identidade, desenvolvimento e operação

IETF/OpenID — protocolos

Navegador e frontend

Banco, plataforma e cadeia de suprimentos

Encerramento: como pensar como responsável pela segurança

Não tente decorar siglas. Para cada funcionalidade, percorra esta sequência:

Qual é o ativo e o impacto?
        ↓
Quem ou qual sistema está agindo?
        ↓
Como prova a identidade?
        ↓
Qual ação, objeto, campo e tenant pode acessar?
        ↓
Que entrada, dependência ou repetição pode ser maliciosa?
        ↓
Como prevenir, detectar, limitar e recuperar?
        ↓
Qual teste e evidência provam isso na versão entregue?

Segurança madura não é a ausência prometida de falhas. É a capacidade demonstrável de reduzir probabilidade e impacto, verificar controles, enxergar desvios, reagir rapidamente e melhorar após cada descoberta.

Caderno complementar: Modelo mental e decisões de segurança verificáveis

Segurança de aplicação não é instalar uma ferramenta no final do projeto. É a capacidade de manter propriedades importantes mesmo quando alguém erra, um componente falha ou um adversário tenta abusar do sistema.

Imagine uma ordem de serviço. O eletricista deve vê-la e concluí-la; não deve alterar ordens de outro contrato. O supervisor pode reatribuir responsáveis. Uma integração do ERP pode atualizar estoque, mas não aprovar a própria compra. O objetivo não é “bloquear tudo”: é permitir exatamente o comportamento legítimo e tornar o restante difícil, detectável e recuperável.

O vocabulário antes da ferramenta

Ativo é algo que tem valor: dados pessoais, saldo de estoque, disponibilidade, credenciais, reputação ou capacidade de executar uma ação. Ameaça é uma causa potencial de dano. Vulnerabilidade é uma fraqueza explorável. Impacto é a consequência. Probabilidade representa quão plausível é o cenário no contexto. Risco combina cenário, probabilidade e impacto. Controle reduz probabilidade, impacto ou ambos. Risco residual é o que permanece depois.

Esses termos evitam conversas vagas. “Precisamos de JWT” começa pela solução. Uma decisão melhor começa pelo cenário: “um token roubado permitiria concluir ordens durante oito horas”. Só então comparamos sessão server-side, token opaco ou JWT, duração, revogação, prova de posse e controles do cliente.

As três propriedades clássicas — e o que elas não cobrem sozinhas

Confidencialidade: somente entidades autorizadas veem o dado.
Integridade: mudanças são autorizadas, corretas e detectáveis.
Disponibilidade: a capacidade continua utilizável dentro do compromisso.

Elas são um começo, não uma taxonomia completa. Autenticidade, responsabilização, privacidade, segurança física, finalidade de uso e segurança humana também podem ser necessárias. Um log íntegro pode ainda violar privacidade se guardar senha ou token. Um sistema disponível pode facilitar fraude se a autorização estiver errada.

Fronteiras de confiança

Uma fronteira aparece quando dados ou autoridade passam entre partes com níveis de confiança diferentes. O navegador é controlado pelo usuário; a API não pode confiar em um campo role: admin enviado por ele. A API confia parcialmente no provedor de identidade, mas precisa validar emissor, audiência, assinatura e validade do token. O ERP é uma dependência autorizada, não uma fonte infalível.

sequenceDiagram
  actor U as Usuário
  participant B as Navegador não confiável
  participant I as Provedor de identidade
  participant A as API
  participant D as Banco
  U->>B: solicita concluir OS 417
  B->>A: PATCH /ordens/417 + credencial
  A->>I: valida prova/metadata quando necessário
  A->>A: autentica identidade
  A->>D: busca OS 417 no escopo autorizado
  D-->>A: contrato, estado e versão
  A->>A: autoriza ação e valida transição
  A->>D: atualização atômica + auditoria
  A-->>B: resultado sem dados excessivos

O fluxo contém decisões diferentes:

TLS protege o canal, mas não decide se o usuário pode concluir a OS.
Autenticação identifica uma entidade; autorização avalia ação, recurso e contexto.
Validação sintática confirma formato; regra de negócio confirma transição válida.
Transação protege consistência; auditoria permite investigar o que ocorreu.
Resposta mínima reduz exposição; observabilidade detecta padrões anormais.

Exemplo inseguro: autorização apenas na interface

// INSEGURO: esconder o botão não protege o endpoint.
if (currentUser.role !== "admin") {
  hideDeleteButton();
}

await fetch(`/api/orders/${orderId}`, { method: "DELETE" });

Qualquer pessoa que controle o cliente pode chamar o endpoint diretamente. CORS também não resolve: ele é uma política de navegador, não autorização de negócio.

Exemplo melhor: autorização ligada à consulta

type Principal = {
  subject: string;
  tenantId: string;
  permissions: Set<string>;
};

async function concludeOrder(principal: Principal, orderId: string) {
  if (!principal.permissions.has("orders:conclude")) {
    throw new ForbiddenError("permission_required");
  }

  const order = await db.order.findFirst({
    where: { id: orderId, tenantId: principal.tenantId },
  });

  if (!order) throw new NotFoundError("order_not_found");
  if (order.status !== "IN_PROGRESS") {
    throw new ConflictError("invalid_status_transition");
  }

  return db.transaction(async (tx) => {
    const updated = await tx.order.update({
      where: { id_version: { id: order.id, version: order.version } },
      data: { status: "DONE", version: { increment: 1 } },
    });
    await tx.auditEvent.create({
      data: { actor: principal.subject, action: "ORDER_CONCLUDED", objectId: order.id },
    });
    return updated;
  });
}

O exemplo é conceitual: o ORM não substitui política, e o log de auditoria precisa de retenção, proteção e minimização próprias. A melhoria central é aplicar o escopo do locatário na busca e autorizar a ação no servidor. Retornar 404 para objeto fora do escopo pode reduzir enumeração; a escolha deve ser consistente e documentada.

Teste que prova a fronteira

it("não conclui uma ordem de outro contrato", async () => {
  const alice = principal({ tenantId: "shopping-a", permissions: ["orders:conclude"] });
  const order = await seedOrder({ tenantId: "shopping-b", status: "IN_PROGRESS" });

  await expect(concludeOrder(alice, order.id)).rejects.toMatchObject({
    code: "order_not_found",
  });

  expect(await readOrder(order.id)).toMatchObject({ status: "IN_PROGRESS" });
  expect(await auditEventsFor(order.id)).toHaveLength(0);
});

Testar apenas “administrador consegue” é insuficiente. Segurança costuma viver nos casos negativos: outro usuário, outro contrato, objeto inexistente, token expirado, repetição da chamada, corrida concorrente e dependência indisponível.

Da ameaça ao critério de aceite

Use esta cadeia:

ativo → cenário de abuso → fronteira → controle → verificação → evidência

Exemplo:

Elemento	Decisão
Ativo	integridade e sigilo das ordens do contrato
Cenário	usuário troca o ID e acessa ordem de outro shopping
Fronteira	navegador → API → consulta ao banco
Controle	escopo de locatário derivado da identidade e aplicado na consulta
Verificação	testes negativos para leitura, edição, exportação e anexos
Evidência	suíte no CI, resultado e evento de auditoria permitido

Critério de aceite verificável:

Dado um usuário autenticado do contrato A, quando ele consulta, altera, exporta ou anexa arquivo a uma ordem do contrato B, então nenhuma informação da ordem é retornada ou alterada, a resposta segue a política documentada e o evento de segurança não registra dados sensíveis.

“A API deve ser segura” não informa cenário, resultado nem teste.

Quem é responsável

Responsabilidade é compartilhada, mas não pode ser anônima.

Decisão	Responsável primário	Verificação independente
regras de acesso	produto/dono do processo	segurança + testes de aceite
enforcement na API	backend	revisão e testes negativos
comportamento seguro do cliente	frontend/mobile	acessibilidade e AppSec
identidade, MFA e ciclo de sessão	identidade/backend	segurança
TLS, segredos e isolamento	plataforma/infra	scan e revisão operacional
RLS, backups e restauração	dados/plataforma	exercício de recuperação
logs, alertas e resposta	operação/SRE/SOC	simulado de incidente

Um fornecedor pode implementar controles, mas o proprietário do sistema ainda precisa aceitar risco residual e garantir operação. “A nuvem cuida” confunde segurança da nuvem com segurança na configuração do cliente.

Checklist de projeto

Ativos e impactos estão nomeados em linguagem de negócio.
Diagrama marca identidades, dados sensíveis e fronteiras de confiança.
Ameaças incluem abuso legítimo, erro e falha de dependência.
Autorização ocorre no servidor e no objeto, não somente no menu.
Segredos não aparecem em frontend, repositório, logs ou exemplos.
Casos negativos testam isolamento, expiração, repetição e concorrência.
Logs permitem investigar sem armazenar credenciais ou conteúdo excessivo.
Backup possui RPO/RTO e restauração exercitada.
Dependências, builds e artefatos têm origem rastreável.
Existe responsável, prazo e evidência para cada risco aceito.

Exercício de recuperação ativa

Desenhe o fluxo “eletricista conclui uma OS” sem consultar o diagrama. Marque três fronteiras, dois ativos e cinco testes negativos. Depois compare com o capítulo.

Evidência de competência: outra pessoa consegue executar seus critérios e obter o mesmo resultado, sem depender de você explicar oralmente o que “seguro” queria dizer.

Relações

O livro de identidade aprofunda senha, sessão, token, OAuth, OIDC e SSO.
O livro de APIs aprofunda contratos, idempotência e consumo de recursos.
O livro de DevSecOps conecta controles a revisão, CI/CD e supply chain.
A biblioteca de sistemas de IA acrescenta prompt injection, isolamento de ferramentas, provenance de RAG e confirmação humana.

Caderno complementar: Respostas fundamentais sobre senhas, tokens, cookies e identidade

Este capítulo responde primeiro, explica depois e aponta para o capítulo completo. O exemplo contínuo é um aplicativo de manutenção que consulta ordens de serviço e integra com um ERP.

1. O que é hash de senha e quem configura

Resposta direta: hash de senha é uma transformação unidirecional e deliberadamente cara usada para verificar uma senha sem guardar a senha original. O backend ou o serviço de identidade executa essa transformação. O responsável técnico escolhe uma biblioteca madura e parâmetros; infraestrutura protege segredos adicionais; segurança revisa; testes verificam. O frontend não decide o hash definitivo e o banco não deve receber senha em texto claro para “resolver depois”.

cadastro
  senha digitada ──TLS──> backend/IdP
                            ├─ gera salt único
                            ├─ executa Argon2id
                            └─ grava parâmetros + salt + hash

login
  tentativa ──TLS──> backend/IdP ── recalcula ── comparação constante

Um salt diferente por senha impede que duas senhas iguais produzam registros iguais e dificulta tabelas pré-calculadas. Um pepper, quando usado, é um segredo separado do banco; ele não substitui salt, algoritmo apropriado ou controle de tentativas. SHA-256 puro é rápido demais para armazenamento de senha. Base64 é codificação reversível, não hash nem criptografia.

Quem faz o quê

Papel	Responsabilidade verificável
backend/serviço de identidade	usa API de alto nível da biblioteca; nunca inventa criptografia
arquiteto/segurança	define algoritmo, custo, migração e recuperação
infraestrutura	protege pepper/chaves em cofre, separa ambientes e controla acesso
banco	restringe acesso, cifra armazenamento quando cabível, audita e faz backup
QA/segurança	testa senha errada, enumeração, limite de tentativas e atualização de hash

Aceite mínimo: o banco contém hash adaptativo e salt, não senha; parâmetros são medidos no hardware real; login tem resposta indistinguível para usuário inexistente; redefinição invalida credenciais aplicáveis; vazamento de banco não revela pepper. A recomendação atual da OWASP privilegia Argon2id e reserva bcrypt principalmente para legados onde Argon2/scrypt não estejam disponíveis.

Leitura completa: Hash de senha e Password Storage Cheat Sheet (OWASP).

2. Quem gera o token e o que uma requisição contabiliza

Resposta direta: quem emite o token é um servidor confiável — o próprio backend ou, preferencialmente em cenários corporativos, um servidor de autorização/provedor de identidade. O aplicativo cliente solicita e guarda a credencial conforme a arquitetura; ele não deve “inventar” um token aceito pela API.

sequenceDiagram
  actor P as Pessoa
  participant App as Aplicativo
  participant IdP as Servidor de identidade
  participant API as API de manutenção
  P->>App: inicia login
  App->>IdP: autorização + PKCE
  IdP-->>App: código de uso único
  App->>IdP: troca código + verifier
  IdP-->>App: access token de curta duração
  App->>API: GET /ordens?limit=100 + token
  API->>API: valida credencial e autorização
  API-->>App: página + cursor da próxima página

Um token costuma representar identidade da aplicação ou do usuário, audiência, escopos e prazo. Ele não contabiliza quantos registros vieram. Contadores distintos podem existir:

requisições: uma chamada HTTP normalmente conta como uma chamada no rate limit;
itens: a resposta pode conter 10 usuários ou 100 ordens; isso altera bytes, tempo de banco, memória e custo, não necessariamente o contador de chamadas;
páginas: 1.000 ordens com limit=100 exigem aproximadamente dez chamadas;
tokens de LLM: são pedaços de texto processados por um modelo de IA; não têm relação com access token de autenticação;
quota/cobrança: cada provedor define sua unidade: chamada, byte, item, operação, tempo computacional ou combinação.

Pedir “todas as ordens” sem paginação pode estourar memória, tempo limite e banda. Uma API segura impõe limite máximo, pagina, ordena de forma estável e informa cursor/continuação. O cliente trata 429 Too Many Requests, respeita Retry-After quando fornecido e não faz retry cego de operações não idempotentes.

Leitura completa: Tokens, JWT e paginação/cotas/rate limit.

3. Quem configura `HttpOnly`, `Secure` e `SameSite`

Resposta direta: o servidor que cria a sessão envia esses atributos no cabeçalho HTTP Set-Cookie; frameworks/backend costumam oferecer a configuração. O navegador aplica as regras. Proxy e plataforma precisam preservar HTTPS e os cabeçalhos. O frontend não consegue adicionar HttpOnly com JavaScript — essa é justamente parte da proteção.

Set-Cookie: __Host-session=valor_opaco;
  Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

Atributo	O que faz	O que não faz
`HttpOnly`	impede leitura por `document.cookie`	não impede que o navegador envie o cookie; não corrige XSS
`Secure`	envia somente por HTTPS, salvo regras locais específicas	não cifra o valor dentro do navegador/servidor
`SameSite`	limita envio em contextos entre sites; ajuda contra CSRF	não substitui token anti-CSRF em todos os fluxos
`Path`/`Domain`	restringem onde o cookie é enviado	`Path` não é fronteira forte contra leitura indevida
`Max-Age`/`Expires`	controla persistência no navegador	não substitui expiração/revogação no servidor
prefixo `__Host-`	exige `Secure`, `Path=/` e ausência de `Domain`	não torna uma sessão segura sozinho

SameSite=Lax costuma equilibrar navegação e proteção. Strict pode quebrar fluxos legítimos. None permite contexto entre sites e exige Secure; só deve ser adotado quando o caso realmente necessita. A decisão depende de login federado, domínios e ameaças — não existe valor universal para todo cookie.

Leitura completa: Cookies e Set-Cookie (MDN).

4. O que acontece quando o token expira

Resposta direta: a API rejeita o access token expirado, normalmente com 401. A experiência de login pode ou não terminar. Se houver uma sessão válida ou refresh token válido, o cliente pode obter novo access token; se não houver, o usuário autentica novamente.

access token expirou
  ├─ há autorização renovável válida? ─ sim ─> rotação/novo token ─> continua
  └─ não, foi revogada ou excedeu sessão máxima ─> novo login

“Usuário ativo” não deve gerar validade infinita por acidente. Uma política pode combinar:

expiração curta do access token;
inatividade máxima da sessão;
duração absoluta, mesmo com atividade;
rotação e detecção de reutilização do refresh token;
revogação em logout, troca de senha, desligamento ou incidente;
reautenticação recente para ação sensível.

Não se deve renovar em loop a cada 401: chamadas simultâneas podem causar uma tempestade de refresh. O cliente coordena uma única renovação e repete somente operações seguras. A API valida assinatura (quando aplicável), emissor, audiência, validade e autorização atual — decodificar o JSON de um JWT não basta.

Leitura completa: Expiração e revogação.

5. OAuth, OIDC, SSO, LDAP e Active Directory sem mistura

Resposta direta: eles ocupam categorias diferentes.

Termo	Categoria	Pergunta que ajuda a responder
OAuth 2.0	framework de autorização delegada	“como um cliente recebe acesso limitado a uma API?”
OpenID Connect (OIDC)	protocolo de identidade sobre OAuth	“quem autenticou e como o app recebe essa identidade?”
SSO	experiência/arquitetura de login único	“como acessar vários sistemas após uma autenticação?”
LDAP	protocolo de acesso a diretório	“como consultar usuários, grupos e atributos do diretório?”
Active Directory Domain Services	produto/serviço de diretório Microsoft	“onde ficam identidades, computadores, grupos e políticas do domínio?”
Kerberos	protocolo de autenticação por tickets	“como obter acesso integrado a serviços do domínio?”
Microsoft Entra ID	serviço de identidade e acesso em nuvem	“como autenticar e governar identidades/aplicações modernas?”

Um sistema corporativo pode usar OIDC para login moderno, OAuth para chamar API, SSO como experiência, Entra ID como provedor e ainda manter Active Directory local, LDAP e Kerberos para sistemas legados. Não se escolhe “OAuth ou SSO” como se fossem equivalentes.

Para aplicações públicas modernas, o fluxo recomendado é Authorization Code com PKCE, validação exata de redirect URI e tokens restritos por audiência/escopo. O implicit grant e o fluxo de senha do usuário (resource owner password credentials) não pertencem ao caminho recomendado atual; a BCP de segurança do OAuth publicada pelo IETF em 2025 atualiza e desaconselha padrões antigos.

Leitura completa: OAuth/OIDC/SSO, RFC 9700 — OAuth 2.0 Security BCP e arquitetura LDAP com Microsoft Entra.

Teste de recuperação ativa

Sem reler, responda:

Por que SHA-256 é inadequado para senha mesmo sendo um hash criptográfico?
Uma resposta com mil ordens consome quantos “tokens”? Quais dois significados de token podem causar confusão nessa pergunta?
Por que HttpOnly não elimina XSS nem CSRF?
Expirar um access token é igual a encerrar toda a sessão?
Em uma frase, diferencie OAuth, OIDC e SSO.

Evidência de domínio: desenhe o login do seu sistema, marque quem emite cada credencial, onde ela fica, quem a valida, quando expira e como é revogada. Uma resposta aprovada não pode conter “o frontend valida a permissão” nem “o JWT é seguro porque está em Base64”.

Caderno complementar: Trilhas de cybersecurity do iniciante ao avançado

As trilhas abaixo alteram a ordem, não reduzem o conteúdo. O número entre parênteses é a unidade do índice completo.

Trilha 1 — Compreender sem programar ainda

Objetivo: conversar com desenvolvimento e fornecedor sem confundir conceitos.

Como usar (1) → mapa mental (2) → responsabilidade (3).
HTTP/JSON/TLS (4) → autenticação/autorização/sessão (5).
Hash (6) → tokens (7) → JWT (8) → expiração (9) → cookies (10).
OAuth/OIDC/SSO (11) → glossário (26).

Prática: produza um diagrama do login e uma matriz papel × ação × recurso. Aceite: consegue explicar por que autenticação bem-sucedida pode resultar em 403, por que JWT não é sessão obrigatória e quem configura um cookie.

Trilha 2 — Construir uma aplicação web segura

Pré-requisito: Trilha 1.

APIs e abuso (12–13).
Backend, frontend e banco (14–16).
Criptografia/segredos (18).
DevSecOps/supply chain (19) e falhas comuns (21).
Checklist/aceites (22) e resposta a incidentes (25).

Prática: implemente uma fatia vertical “eletricista conclui apenas ordem do próprio contrato”. Inclua teste positivo, teste de acesso horizontal negado, auditoria e rollback. Aceite: proteção existe na API e na consulta de dados, não apenas no botão; segredo não está no bundle; pipeline bloqueia vulnerabilidade crítica conhecida.

Trilha 3 — Integrar ERP, webhooks e filas

Pré-requisito: HTTP, autenticação e autorização.

Paginação/cotas/rate limit (12).
APIs (13) e integrações (17).
Segredos e identidade de máquina (18).
DevSecOps (19), incidentes (25) e fontes (27).

Prática: modele “ERP confirmou baixa de estoque”. Defina assinatura do webhook, proteção contra replay, idempotency key, fila de falhas, reconciliação e responsável operacional. Aceite: repetir a mesma mensagem não duplica a baixa; perda temporária do ERP é recuperável; logs correlacionam a operação sem guardar credencial.

Trilha 4 — Segurança de desenvolvimento com IA e agentes

Pré-requisito: Trilha 2.

Código com IA/vibe coding (20).
Supply chain (19) e falhas comuns (21).
APIs, backend, dados e segredos (13–18).
Checklist (22), status/evidência (24) e incidentes (25).

Prática: dê a um agente um ticket com acesso somente ao repositório e ambiente efêmero. Negue acesso a produção por padrão. Faça revisão independente do diff, SAST, teste de autorização e inventário de dependências. Aceite: ferramenta destrutiva exige aprovação; segredos são redigidos dos logs; saída do modelo não é tratada como comando confiável; o agente tem limite de passos e condição de parada.

Trilha 5 — Liderar, contratar e auditar

Pré-requisito: compreensão das quatro primeiras trilhas ou equipe técnica responsável por demonstrá-las.

Responsabilidade (3).
Checklist e critérios (22).
Solicitação a fornecedor (23) e acompanhamento de status (24).
Incidentes (25), fontes/normas (27) e encerramento (28).

Prática: transforme “a aplicação deve ser segura” em dez critérios com responsável, ameaça, evidência, ambiente e consequência da falha. Aceite: cada item pode ser aprovado ou reprovado por evidência; “feito”, “usamos JWT” ou “passou no scanner” isoladamente não contam como prova.

Progressão de competência

Nível	Você demonstra que sabe quando…	Evidência
alfabetização	diferencia termos e responsáveis	mapa de fluxo comentado
aplicação	implementa controle em uma fatia real	testes positivos e negativos
diagnóstico	reproduz uma falha e encontra a fronteira errada	relatório com causa e evidência
decisão	compara alternativas e risco residual	ADR/threat model
operação	detecta, contém, recupera e aprende	exercício de incidente e runbook
ensino	transfere o método para outro domínio	revisão de projeto alheio com justificativa

Leitura não concede o último nível. Competência é demonstrada por decisões, testes, operação e capacidade de explicar limites.

Caderno complementar: Checklists e critérios de aceite de segurança

Checklist reduz esquecimento; não prova segurança sozinho. Cada item abaixo deve registrar ameaça, responsável, ambiente, evidência e risco residual.

Antes de escrever código

ativos, atores, dados sensíveis e ações críticas foram inventariados;
fronteiras de confiança e fluxos de dados estão desenhados;
papéis e permissões cobrem recurso e contexto, não só tela;
requisitos de privacidade, retenção, backup e recuperação têm dono;
dependências externas, ERP, IdP e indisponibilidade têm estratégia;
abuso de negócio e falhas de autorização possuem casos negativos.

Aceite: existe threat model versionado; pelo menos um cenário por fronteira tem prevenção, detecção e recuperação; decisões difíceis de reverter estão em ADR. Leitura: mapa mental.

Identidade, senha, sessão e autorização

senha usa função adaptativa apropriada e parâmetros medidos;
MFA é exigido para ações/perfis de alto impacto;
cookies sensíveis têm escopo mínimo, Secure, HttpOnly e SameSite decidido;
access token tem audiência, escopo e prazo mínimos;
refresh/session possuem rotação, revogação e duração absoluta;
API autoriza cada recurso; IDs previsíveis não concedem acesso;
mudança de senha/desligamento/incidente invalidam acesso conforme política.

Teste de aceite essencial: usuário A altera o ID para recurso de B e recebe negação sem vazamento; o evento é auditado. Token expirado, assinatura inválida, emissor/audiência errados e escopo insuficiente também são rejeitados.

API, backend, frontend e dados

entrada é validada por esquema e regra de negócio no servidor;
consultas aplicam o escopo autorizado antes de retornar dados;
paginação e limites impedem respostas sem teto;
operação mutável é idempotente quando precisa suportar retry;
erros externos não expõem stack, SQL, segredo ou dado pessoal;
frontend não contém segredo nem é autoridade de permissão;
banco usa conta de menor privilégio, migração controlada e backup restaurado em teste;
upload valida tamanho, tipo real, nome, armazenamento e processamento isolado.

Evidência: testes de contrato, autorização horizontal/vertical, integração, restauração e carga. Leitura: APIs, backend, frontend e dados.

Integrações, segredos e supply chain

credenciais são distintas por ambiente, rotacionáveis e fora do código;
webhooks têm autenticidade, janela temporal e proteção contra replay;
mensagens possuem idempotência, dead-letter e reconciliação;
lockfile, revisão, atualização e análise de dependências estão ativos;
artefato de build é rastreável à revisão e pipeline que o produziu;
SBOM e procedência existem quando o risco/contrato exigir;
agente de IA e automação recebem apenas ferramentas e dados necessários.

Aceite: uma credencial pode ser rotacionada sem rebuild manual; repetir evento não duplica efeito; componente vulnerável bloqueante impede promoção; produção não é gravável por job de pull request.

Deploy, observabilidade e incidente

homologação e produção têm identidades e segredos separados;
deploy tem rollback/roll-forward testado;
logs estruturados usam correlação e redigem credenciais/dados desnecessários;
alertas têm limiar, responsável e runbook;
RTO/RPO são definidos e restauração é exercitada;
processo de vulnerabilidade e incidente define triagem, contenção e comunicação;
aprendizado gera teste, regra, arquitetura ou treinamento correspondente.

Aceite: exercício controlado detecta uma ação negada repetitiva, aciona a pessoa correta e permite reconstruir o evento sem revelar segredo. Um backup só é aceito após restauração demonstrada.

Modelo de critério de aceite copiável

Cenário de ameaça:
Ativo e impacto:
Controle preventivo:
Controle de detecção:
Responsável por implementar:
Responsável por operar:
Ambiente e versão:
Teste positivo:
Teste negativo:
Evidência anexada:
Risco residual e aprovador:
Plano de recuperação:
Prazo de revalidação:

Exemplo preenchido

Cenário: eletricista tenta concluir OS de outro contrato alterando o ID.
Ativo/impacto: integridade operacional; fraude e parada indevida.
Preventivo: consulta da API filtra order_id + tenant_id autorizado.
Detecção: evento authorization_denied com actor, tenant e correlation_id.
Responsável implementação: equipe API.
Responsável operação: segurança/SRE.
Teste positivo: eletricista conclui OS própria no estado permitido.
Teste negativo: mesma credencial + ID de outro contrato retorna 404/403 pela política.
Evidência: teste de integração no pipeline e log redigido em homologação.
Risco residual: credencial legítima comprometida; MFA e detecção reduzem risco.
Revalidação: a cada mudança na política ou em 90 dias.

O checklist mestre original permanece completo em Checklist mestre e critérios de aceite.

Guia prático de cybersecurity para aplicações

Como usar este guia

Referências-base deste material

Sumário

1. O mapa mental da segurança

1.1 Os objetivos: confidencialidade, integridade e disponibilidade

1.2 Segurança não é um produto isolado

1.3 Três princípios que aparecem em todo o guia

2. Quem é responsável por cada configuração

2.1 Resposta direta: quem configura hash, tokens e cookies?

Critérios de aceite desta parte

3. HTTP, requisição, resposta e JSON

3.1 O que é HTTP?

3.2 Para que serve cada parte?

3.3 Por que JSON e não Java?

3.4 Status não substitui detalhes seguros

3.5 HTTPS e TLS

Critérios de aceite desta parte

4. Autenticação, autorização e sessão

4.1 A diferença fundamental

4.2 RBAC, ABAC e ReBAC

4.3 Exemplo inseguro e seguro

4.4 Teste que realmente encontra a falha

Critérios de aceite desta parte

5. Hash de senha

5.1 O que é

5.2 Hash não é criptografia e Base64 não é segurança

5.3 Salt e pepper

5.4 Algoritmos adequados

5.5 Exemplo conceitual seguro

5.6 Regras modernas de senha

5.7 Quem configura e quem protege

5.8 Falhas comuns

Critérios de aceite desta parte

6. Tokens: o que são, quem gera e como funcionam

6.1 Quem gera o token?

6.2 Token opaco e token autocontido

6.3 Como gerar um token opaco

6.4 O ciclo de vida

Critérios de aceite desta parte

7. JWT sem mistério

7.1 Claims importantes

7.2 Validação correta

7.3 Falhas clássicas e controles

7.4 Chaves e rotação

Critérios de aceite desta parte

8. Expiração, renovação, logout e revogação

8.1 O que acontece quando o token vence?

8.2 A sessão é renovada enquanto o usuário está ativo?

8.3 Refresh token com rotação

8.4 Logout não é só apagar a tela

Critérios de aceite desta parte

9. Cookies: HttpOnly, Secure, SameSite e afins

9.1 Quem configura?

9.2 Cookie, CSRF e XSS

9.3 Por que evitar tokens de autenticação no localStorage?

Critérios de aceite desta parte

10. OAuth, OpenID Connect, SSO e autenticação corporativa

10.1 Login moderno de usuário

10.2 ID token não é access token

10.3 Sistema com sistema

10.4 Perguntas para escolher a solução

Critérios de aceite desta parte

11. Chamadas, paginação, cotas e rate limit

11.1 Uma requisição não é igual a um registro

11.2 Paginação e filtros

11.3 Rate limit e consumo de recursos

Critérios de aceite desta parte

12. Segurança de APIs

12.1 OWASP API Security Top 10:2023 aplicado

12.2 Autorização deve entrar na consulta

12.3 Entrada, saída e contrato

12.4 Idempotência e repetição

12.5 Inventário e retirada

Critérios de aceite desta parte

13. Segurança do backend

13.1 Validação e injeção

13.2 SSRF e chamadas de saída

13.3 Upload de arquivos

13.4 Erros, logs e observabilidade

9.3 Por que evitar tokens de autenticação no `localStorage`?