Melhores Práticas de Segurança de API

Revise o limite da requisição desde a identidade do chamador até a autorização, entrada validada, armazenamento e resposta observável. Preserve o provedor de identidade e o modelo de dados reais da aplicação em vez de introduzir um segundo sistema de autenticação.

Quando Usar

Use ao adicionar um endpoint protegido, revisar o acesso a objetos, substituir a análise permissiva de requisições ou investigar um caminho de abuso de API. Para um defeito concreto, comece com a rota que falha e seus chamadores; não implante infraestrutura de segurança não relacionada.

Entradas e pré-requisitos

Registre as rotas, o modelo de chamador/inquilino, o provedor de identidade, o contrato de token, as versões de tempo de execução e de dependências bloqueadas, o esquema do banco de dados, a topologia do proxy e o escopo de teste autorizado. Use identidades sintéticas em um ambiente de teste. A autorização de tarefa existente é transferida; verificações de produção, gravações de conta e envios de mensagens precisam de sua própria autoridade. Os exemplos de Node abaixo são esboços de integração para Express, jsonwebtoken e Zod; adaptadores de aplicação/banco de dados são deliberadamente nomeados em vez de apresentados como um serviço completo executável. Confirme as APIs contra as versões instaladas antes de integrar.

1. Autentique o contrato de token exato

Prefira o middleware de provedor/sessão estabelecido. Quando o serviço possui um contrato JWT HMAC, exija uma chave forte de propriedade do servidor, um algoritmo fixo, emissor e público exatos, e declarações de tempo de execução obrigatórias. Não infira permissões de um token decodificado antes da verificação da assinatura. Nunca aceite um algoritmo de verificação selecionado pelo chamador.

const jwt = require('jsonwebtoken');

// Illustrative first-party access-token contract; not a third-party OAuth adapter.
const ACCESS_POLICY = {
  algorithms: ['HS256'], issuer: 'example-auth', audience: 'example-api'
};
function verifyAccessToken(token, signingKey) {
  const claims = jwt.verify(token, signingKey, ACCESS_POLICY);
  if (!claims || typeof claims !== 'object' ||
      typeof claims.sub !== 'string' || !claims.sub ||
      typeof claims.tenantId !== 'string' || !claims.tenantId ||
      !Number.isSafeInteger(claims.exp) || !Number.isSafeInteger(claims.iat) ||
      claims.exp <= claims.iat) {
    throw new Error('Invalid access claims');
  }
  return { subject: claims.sub, tenantId: claims.tenantId };
}
function readBearer(header) {
  if (typeof header !== 'string' || header.length > 8192) return null;
  const match = /^Bearer ([A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+)$/i.exec(header);
  return match ? match[1] : null;
}

Emita tokens de acesso com o mesmo emissor/público/algoritmo e uma curta expiração aprovada pela aplicação. Trate a falha de verificação como um 401 genérico sem ecoar o token ou a exceção. A expiração por si só não revoga um token; defina a revogação ou sessões de curta duração de acordo com o modelo de ameaça real. Um serviço que usa chaves de provedor assimétricas precisa da validação de descoberta/JWKS do provedor e da política de rotação de chaves, não deste exemplo HMAC. Nunca reutilize um token de acesso como um token de atualização.

Atualize sessões

Use o fluxo de sessão suportado pelo provedor ou um design de atualização opaco do lado do servidor: armazene apenas um resumo, expiração, família de usuário/sessão e estado de revogação. Em uma transação atômica, consuma o token ativo antigo e crie o substituto. A reutilização concorrente não deve emitir dois sucessores; o tratamento de reutilização definido revoga a família afetada. Verifique o status e as permissões do usuário atual ao emitir novos tokens de acesso. Vincule a atualização ao cliente/sessão pretendido e proteja as requisições baseadas em cookie contra CSRF. Não registre tokens, armazene-os em texto plano em um banco de dados ou retorne um token de atualização através de uma URL. Teste atualização simultânea, expiração, repetição, revogação e falha de transação antes de considerar o fluxo completo. Nenhum adaptador de transação de banco de dados está incluído aqui.

2. Autorize o recurso e a operação

A autenticação identifica o chamador; a autorização decide a operação exata em um objeto e inquilino. Um nome de função não concede automaticamente acesso entre inquilinos. Aplique o predicado de proprietário/inquilino na mutação do banco de dados para evitar uma corrida de verificação-depois-escrita e permita propriedades graváveis. Use 404/403 consistentemente com a política de divulgação de recursos do produto.

// Esboço estilo Prisma; os tipos de id e tenant devem corresponder ao seu esquema real.
async function deleteOwnedPost(prisma, postId, principal) {
  const result = await prisma.post.deleteMany({

…