Checklist de segurança para APIs financeiras em 2026

Este é o checklist interno que usamos em auditorias de APIs financeiras. Não é teórico — cada item foi adicionado depois de encontrar a vulnerabilidade correspondente em produção.

1. Autenticação

• JWT com algoritmo explícito (rejeitar `alg: none`)
• Tokens com expiração curta (<15min) + refresh tokens rotativos
• Rate limit em /login — no máximo 5 tentativas por minuto por IP
• Lockout temporário após 10 falhas (evitar timing attacks com bcrypt)
• API keys com escopo mínimo e rotação forçada a cada 90 dias
• Sem secrets em query strings — sempre header `Authorization`

2. Autorização

• RBAC ou ABAC — nunca confiança implícita pelo contexto
• Verificar ownership em todo endpoint que acessa recurso por ID (IDOR)
• Middleware de auth antes de qualquer lógica de negócio
• Logs de acesso negado com usuário, IP, recurso e timestamp

3. Rate Limiting e DDoS

• Rate limit por IP + por usuário autenticado (separadamente)
• Sliding window em vez de fixed window — evita burst no início de cada janela
• Endpoints de pagamento: máximo 3 tentativas por minuto por conta
• Resposta 429 com `Retry-After` header — nunca silenciosamente ignorar
• Circuit breaker para dependências externas (gateway de pagamento, RPC nodes)

// Exemplo com Upstash Redis + sliding window
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, "1 m"), // 5 req/min
  prefix: "payment_api",
});

export async function POST(request: Request) {
  const identifier = request.headers.get("x-forwarded-for") ?? "anonymous";
  const { success, limit, reset, remaining } = await ratelimit.limit(identifier);

  if (!success) {
    return Response.json(
      { error: "Too many requests" },
      {
        status: 429,
        headers: { "Retry-After": String(Math.ceil((reset - Date.now()) / 1000)) }
      }
    );
  }

  // lógica de negócio
}

4. Input Validation

• Validar schema com Zod ou Joi — nunca confiar no tipo do campo
• Limitar tamanho de strings em campos de texto livre
• Sanitizar valores monetários: usar inteiros (centavos) nunca float
• Rejeitar campos não esperados (strict schema) — evitar prototype pollution
• Validar formato de IDs externos (UUID v4, endereços Solana, etc.)

import { z } from "zod";

const PaymentSchema = z.object({
  amount: z.number().int().positive().max(100_000_00), // centavos, máx R$100k
  recipient: z.string().regex(/^[1-9A-HJ-NP-Za-km-z]{32,44}$/), // endereço Solana
  description: z.string().max(200).optional(),
}).strict(); // rejeita campos extras

export async function POST(request: Request) {
  const body = await request.json();
  const result = PaymentSchema.safeParse(body);

  if (!result.success) {
    return Response.json({ error: result.error.format() }, { status: 400 });
  }

  // result.data é type-safe aqui
}

5. Prevenção de Fraude

• Idempotency keys em endpoints de pagamento — previne double-charge
• Verificar assinatura de webhooks (HMAC-SHA256) — nunca aceitar cegamente
• Replay protection: timestamp no payload + janela de 5 minutos
• Audit log imutável de todas as transações financeiras
• Alertas para padrões anômalos: valor fora da média, país diferente do histórico

6. Segurança de Transporte e Headers

• HTTPS obrigatório com HSTS e `max-age` mínimo de 1 ano
• CORS restrito ao domínio exato — sem wildcard em APIs financeiras
• CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
• Remove `X-Powered-By` e qualquer header que revele stack
• Certificate pinning em apps mobile que usam a API