📋 Lista de verificação de pré-desenvolvimento

Itens a serem verificados antes de desenvolver um novo endpoint de API.

  • A especificação da API (OpenAPI) foi criada
  • Os métodos de autenticação e autorização foram determinados
  • Os tipos de parâmetros de entrada e as restrições foram definidos
  • Os campos a serem incluídos nas respostas foram claramente definidos
  • O formato de resposta a erros é padronizado
  • Foram estabelecidos requisitos de limitação de taxa
  • O manuseio de dados pessoais e confidenciais foi confirmado
  • O método de autenticação foi determinado (OAuth 2.0, JWT, API Key)
  • As permissões necessárias (escopos/funções) foram definidas para cada ponto de extremidade
  • As verificações de autorização em nível de recurso foram projetadas (contramedida BOLA)
  • As funções administrativas são claramente separadas
  • Os métodos de expiração e atualização do token foram determinados
  • A comunicação usa TLS 1.2 ou superior
  • O método de criptografia para dados armazenados foi determinado
  • Foram determinadas políticas de mascaramento e anonimização para informações pessoais
  • Informações confidenciais (tokens, senhas) não são incluídas nos registros
  • As informações de depuração e os rastreamentos de pilha não são incluídos nas respostas da API

👀 Perspectivas da revisão de código

Perspectivas de segurança a serem verificadas durante as revisões de código da API.

Verificar itemImportânciaExplicação
O middleware de autenticação é aplicado a todos os pontos de extremidadeNecessárioGarantir que nenhuma verificação de autenticação esteja faltando, exceto para APIs públicas
Existem verificações de autorização em nível de objetoNecessárioVerificar se os recursos solicitados pertencem ao usuário solicitante
As funções administrativas têm verificação de funçãoNecessárioGarantir que usuários comuns não possam chamar APIs de administração
O algoritmo é especificado durante a verificação do JWTNecessárioPrevenção de ataques alg: nenhum
A expiração do token está configurada corretamenteRecomendadoToken de acesso: dentro de 15 minutos
Verificar itemImportânciaExplicação
O corpo da solicitação tem validação de esquemaNecessárioValidação de tipo, comprimento e formato
As consultas SQL são parametrizadasNecessárioGarantir que as consultas não sejam criadas com concatenação de strings
Existe validação de formato de parâmetro de caminhoNecessárioVerificar o formato esperado, como UUID
Os parâmetros de paginação têm limites superioresRecomendadoImpedir solicitações excessivas como limit=999999
Os uploads de arquivos têm restrições de tipo e tamanhoRecomendadoValidação de Content-Type e tamanho do arquivo
Verificar itemImportânciaExplicação
As respostas não contêm campos desnecessáriosNecessárioEvite o vazamento de password_hash, IDs internas etc.
As respostas de erro não contêm rastreamentos de pilhaNecessárioNão exponha informações internas na produção
Os cabeçalhos de segurança são configuradosRecomendadoX-Content-Type-Options, HSTS, etc.
Content-Type está definido corretamenteRecomendadoEspecificar explicitamente application/json
Verificar itemImportânciaExplicação
A limitação de taxa é aplicadaNecessárioEspecialmente para pontos de extremidade de autenticação e pagamento
Registros apropriados estão sendo registradosRecomendadoRastreável: quem fez o quê e quando
Os segredos não são codificados por hardcodingNecessárioUse variáveis de ambiente ou gerenciadores secretos
As configurações de CORS são apropriadasRecomendadoEvite usar curingas
As dependências não têm vulnerabilidades conhecidasRecomendadoVerificar os resultados da auditoria do npm / Snyk

📜 Modelos de política de segurança

Modelos para políticas básicas no desenvolvimento interno de APIs. Personalize para se adequar ao seu projeto.

1. Política de autenticação

PolicyModelo
Métodos de autenticação
  - APIs voltadas para o usuário: OAuth 2.0 (código de autorização + PKCE)
  - APIs de servidor para servidor: OAuth 2.0 (Credenciais do cliente) ou mTLS
  - APIs de integração externa: Chave de API + assinatura HMAC

Gerenciamento de tokens
  - Expiração do token de acesso: 15 minutos
  - Expiração do token de atualização: 7 dias (rotação necessária)
  - Armazenamento de tokens: HttpOnly + Secure + SameSite Cookie

Política de senha
  - Mínimo de 12 caracteres, pelo menos uma letra maiúscula, uma minúscula, um número e um símbolo
  - Hash com bcrypt (fator de custo 12 ou superior)
  - Proteção contra ataques à lista de senhas (integração da API Have I Been Pwned)

2. Política de design da API

PolicyModelo
■ Controle de versão
  - Gerenciamento de versões via caminho de URL: /api/v1/resources
  - Período mínimo de suporte de 6 meses para versões antigas
  - Notificação de depreciação por meio do cabeçalho Deprecation

Limitação de taxa (valores padrão)
  - APIs gerais: 100 solicitações/15 min
  - APIs de autenticação: 5 solicitações/15 min
  - APIs públicas: 30 solicitações/min
  - Sempre retorna cabeçalhos RateLimit-*

■ Respostas
  - Content-Type: application/json (fixo)
  - Respostas de erro no formato RFC 7807 (Detalhes do problema)
  - Nunca retorne rastreamentos de pilha em produção
  - Paginação: padrão de 20 itens, máximo de 100 itens

3. Política de registro e auditoria

PolicyModelo
Campos de registro obrigatórios
  - Registro de data e hora (ISO 8601, UTC)
  - ID da solicitação (UUID para rastreabilidade)
  - ID do usuário / ID do cliente da API
  - Método HTTP + ponto final
  - Código de status
  - IP de origem
  - Tempo de resposta

Campos de registro proibidos (dados confidenciais)
  - Senhas / Tokens / Chaves de API
  - Números de cartão de crédito
  - Exibição completa de PII (mascaramento necessário)

Alertas de monitoramento
  - Falhas de autenticação: Alerta a 5+/min
  - Erros 403: Alerta a 10+/min
  - 500 erros: Alerta imediato em 1 ocorrência
  - Limite de taxa excedido: Análise de padrão

🚨 Fluxo de resposta a incidentes

Fase 1: Detecção

Detectar incidentes por meio de alertas de monitoramento, relatórios de usuários ou notificações externas. Determinar a gravidade por meio da triagem inicial.

0-30 minutos

Fase 2: Contenção

Evitar o aumento de danos. Invalide as chaves de API, suspenda temporariamente os pontos de extremidade afetados e identifique o escopo do impacto.

30 min - 2 horas

Fase 3: Erradicação e recuperação

Corrigir as vulnerabilidades, aplicar patches e restaurar os serviços. Notifique os usuários afetados.

2 a 24 horas

Fase 4: Análise pós-incidente

Conduzir o post-mortem. Realizar análise de causa raiz, desenvolver medidas de prevenção de recorrência e documentar as descobertas.

1-5 dias úteis

🤖 AI / LLM Security Checklist

Additional checklist items for systems integrating AI models and LLM-powered features.

  • Model provider has been evaluated for security and compliance (SOC 2, data processing agreement)
  • System prompts are stored securely and not exposed to end users
  • Token budget and cost limits are configured per request and per user
  • Data classification policy defines what data can be sent to external LLM APIs
  • LLM outputs are validated and sanitized before rendering or downstream processing
  • Fallback behavior is defined for model unavailability or degraded responses
  • Model version pinning strategy is documented to prevent unexpected behavior changes
  • Agent permissions follow least privilege principle — only necessary tools and APIs are accessible
  • Tool/function calling uses an explicit allowlist (not a denylist)
  • Human-in-the-loop approval is required for high-impact actions (payments, deletions, external communications)
  • Agent memory scope is bounded — conversation history does not leak across tenants or sessions
  • Inter-agent communication is authenticated and uses signed messages
  • Goal drift detection is implemented — agents are monitored for deviation from intended objectives
  • Emergency kill switch exists to halt agent execution immediately
  • Training data provenance is documented with lineage tracking
  • Data integrity checks exist for training and fine-tuning datasets (hash verification)
  • Model artifacts are versioned and stored in a tamper-proof registry
  • Model drift monitoring is in place to detect performance degradation
  • Third-party models and embeddings have been evaluated for known vulnerabilities
  • PII and sensitive data scrubbing is applied to training datasets

🧐 AI / LLM Code Review Perspectives

Security check items specific to code that integrates LLMs, AI agents, and ML models.

Verificar itemImportânciaExplicação
System prompts are not exposed in client-side code or API responsesNecessárioPrompt leakage enables targeted prompt injection attacks
LLM outputs are validated before rendering (HTML/JS/SQL)NecessárioLLM-generated content may contain XSS payloads or injection vectors
User input and system instructions are clearly separated in promptsNecessárioPrevents direct prompt injection by maintaining instruction-data boundary
Tool/function call permissions are scoped per user roleNecessárioPrevent privilege escalation through agent tool access
Token count limits are enforced per request and per sessionRecomendadoPrevents cost explosion and denial-of-wallet attacks
RAG retrieval results are sanitized before insertion into promptsNecessárioRetrieved documents may contain indirect prompt injection payloads
Agent actions and tool calls are logged with full audit trailRecomendadoEssential for incident investigation and compliance in AI systems

📑 AI / LLM Security Policy Templates

Policy templates for organizations deploying AI models and LLM-powered applications.

4. AI Model Access Control Policy

PolicyModelo
■ Model Access Tiers
  - Tier 1 (Restricted): GPT-4 class / fine-tuned models — requires team lead approval
  - Tier 2 (Standard): GPT-3.5 class / embeddings — available to all developers
  - Tier 3 (Open): Open-source models (local inference) — no approval required

■ API Key Management for LLM Providers
  - One API key per service/environment (never share across projects)
  - Monthly spend alerts at 50%, 80%, 100% of budget
  - Hard spending caps enforced at the provider level
  - Key rotation: every 90 days or immediately upon team member departure

■ Data Sent to External Models
  - NEVER send: PII, credentials, internal IP, source code, customer data
  - ALLOWED with review: anonymized logs, public documentation, synthetic data
  - All prompts to external APIs must be logged (excluding PII)

5. AI Data Handling Policy

PolicyModelo
■ Training Data Requirements
  - All training data must have documented provenance and licensing
  - PII must be removed or anonymized before use in training/fine-tuning
  - Data poisoning checks: validate data integrity with hash verification
  - Retain training data snapshots for reproducibility and audit

■ RAG (Retrieval-Augmented Generation) Data
  - Document ingestion pipeline must sanitize content (strip scripts, injections)
  - Access control on vector store must mirror source document permissions
  - Embedding models must be versioned and pinned

■ Model Output Data
  - LLM outputs must not be trusted as authoritative — always verify facts
  - Generated code must pass the same security review as human-written code
  - Outputs containing PII must be flagged and redacted before storage

6. AI Incident Classification Policy

PolicyModelo
■ Severity Levels for AI-Specific Incidents
  - P1 (Critical): Prompt injection leading to data exfiltration or unauthorized actions
  - P1 (Critical): Model serving compromised or returning manipulated outputs
  - P2 (High): Training data poisoning detected, jailbreak bypass discovered
  - P2 (High): Agent performing unintended actions outside approved scope
  - P3 (Medium): Model drift causing degraded accuracy below threshold
  - P4 (Low): Cost overrun due to excessive token usage

■ Response Procedures
  - P1: Immediately disable affected model endpoint, notify security team
  - P2: Quarantine affected model version, roll back to last known good
  - P3: Trigger retraining pipeline, increase monitoring frequency
  - P4: Adjust rate limits and budget caps, review usage patterns

■ Post-Incident Requirements
  - Root cause analysis within 48 hours for P1/P2
  - Update prompt injection test suite with new attack vectors
  - Review and update guardrails configuration

Referência rápida: Códigos de status HTTP

Códigos de status HTTP relacionados à segurança usados no design da API.

CódigoSignificadoCaso de uso
400Bad RequestErro de validação de entrada
401UnauthorizedA autenticação é necessária ou o token é inválido
403ForbiddenAutenticado, mas com permissões insuficientes
404Not FoundO recurso não existe (também pode ser usado em vez de 403)
405Method Not AllowedMétodo HTTP não permitido
413Payload Too LargeTamanho do corpo da solicitação excedido
422Unprocessable EntityA sintaxe está correta, mas há um erro de semântica
429Too Many RequestsLimite de taxa excedido
500Internal Server ErrorErro interno do servidor (ocultar detalhes)