Boas práticas de segurança em APIs públicas

APIs públicas são a porta de entrada para serviços digitais modernos, conectando aplicações, dispositivos e usuários ao redor do mundo. No contexto da Lista Final de 1200 temas, a segurança dessas interfaces é um pilar fundamental para garantir integridade, confidencialidade e disponibilidade dos dados. Este artigo aborda as principais práticas que toda equipe de desenvolvimento deve implementar para proteger APIs expostas publicamente.

1. Autenticação e Autorização Robusta

A primeira camada de defesa de uma API pública é garantir que apenas entidades legítimas possam acessar os recursos. O padrão OAuth 2.0 combinado com OpenID Connect oferece um framework maduro para delegação de acesso.

// Exemplo de fluxo OAuth 2.0 com JWT
POST /oauth/token
Content-Type: application/json

{
  "grant_type": "client_credentials",
  "client_id": "seu-client-id",
  "client_secret": "seu-client-secret",
  "scope": "read:users write:orders"
}

// Resposta com token JWT de curta duração
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read:users write:orders"
}

Implemente tokens JWT com expiração curta (15-60 minutos) e utilize refresh tokens para renovação segura. Aplique o princípio do menor privilégio definindo escopos granulares por endpoint:

// Exemplo de validação de escopo no middleware
GET /api/v1/users/{id}
Authorization: Bearer <token>
Scope necessário: read:users

GET /api/v1/users/{id}/orders
Authorization: Bearer <token>
Scope necessário: read:orders

2. Controle de Acesso e Rate Limiting

APIs públicas são alvos frequentes de abuso e ataques de negação de serviço. Implemente múltiplas camadas de rate limiting:

// Configuração de rate limiting por camada
Headers de resposta:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1623456789

// Estratégias de throttling
- Por IP: 1000 requisições/hora
- Por chave de API: 5000 requisições/hora
- Por usuário autenticado: 10000 requisições/hora
- Endpoints críticos (login): 5 requisições/minuto

Utilize listas de bloqueio para IPs maliciosos e listas de permissão para parceiros confiáveis. Implemente quotas diárias com alertas automatizados:

// Exemplo de resposta para quota excedida
HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: application/json

{
  "error": "rate_limit_exceeded",
  "message": "Quota diária excedida. Tente novamente em 1 hora.",
  "quota_reset": "2024-01-15T14:00:00Z"
}

3. Validação e Sanitização de Entradas

Nunca confie em dados fornecidos pelo cliente. Valide rigorosamente todos os parâmetros, headers e corpo da requisição:

// Exemplo de validação de entrada
POST /api/v1/orders
Content-Type: application/json

{
  "user_id": "uuid-formato-estrito",
  "amount": 150.50,
  "currency": "BRL",
  "items": [
    {
      "product_id": "integer-positivo",
      "quantity": "integer-entre-1-e-100"
    }
  ]
}

// Validação de tipos e limites
- user_id: UUID v4 estrito
- amount: decimal positivo até 999999.99
- currency: enum ['BRL', 'USD', 'EUR']
- quantity: inteiro entre 1 e 100

Proteja contra injeções SQL e NoSQL utilizando consultas parametrizadas e ORMs seguros. Sanitize entradas para prevenir XSS:

// Sanitização de strings para evitar XSS
function sanitizeInput(input) {
  return input
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#x27;');
}

4. Criptografia e Proteção de Dados em Trânsito

Exija HTTPS obrigatoriamente com TLS 1.2 ou superior. Configure HSTS para forçar conexões seguras:

// Headers de segurança obrigatórios
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

// Configuração TLS no servidor
TLS versions: 1.2, 1.3
Cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256

Para payloads sensíveis, implemente criptografia adicional com chaves efêmeras:

// Exemplo de criptografia de payload sensível
POST /api/v1/payments
Content-Type: application/jose+json

{
  "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
  "encrypted_key": "ZHNlZTI0NTM0NjU0MzI0NTM0...",
  "iv": "MTIzNDU2Nzg5MDEyMzQ1Ng",
  "ciphertext": "dXNlciBkYXRhIGVuY3J5cHRlZA...",
  "tag": "YWJjZGVmMTIzNDU2Nzg5MA"
}

5. Gerenciamento Seguro de Chaves e Segredos

Armazene chaves de API e segredos em cofres de segredos como HashiCorp Vault ou AWS Secrets Manager:

// Configuração de acesso a secrets
apiVersion: v1
kind: Secret
metadata:
  name: api-credentials
type: Opaque
data:
  api-key: <base64-encoded>
  client-secret: <base64-encoded>

// Rotação automática de chaves
- Rotação a cada 90 dias
- Revogação imediata em caso de vazamento
- Duas chaves ativas simultaneamente para transição suave

Nunca exponha chaves em URLs, logs ou respostas de erro:

// Incorreto - nunca faça isso
GET /api/v1/data?api_key=sk-1234567890abcdef

// Correto - use headers de autorização
GET /api/v1/data
Authorization: Bearer sk-1234567890abcdef

6. Monitoramento, Logging e Resposta a Incidentes

Implemente logs estruturados e anônimos para auditoria:

// Log estruturado seguro
{
  "timestamp": "2024-01-15T10:30:00Z",
  "method": "POST",
  "endpoint": "/api/v1/orders",
  "status_code": 201,
  "user_id_hash": "a1b2c3d4e5f6...",
  "ip_hash": "f6e5d4c3b2a1...",
  "request_id": "uuid-unico",
  "latency_ms": 145
}

Utilize ferramentas de SIEM para detectar padrões anômalos:

// Alertas de segurança configurados
- Múltiplas falhas de autenticação (5+ em 1 minuto)
- Acesso a endpoints incomuns
- Picos de tráfego acima de 3 desvios padrão
- Tentativas de path traversal ou injeção

7. Headers de Segurança e Boas Práticas de Resposta

Configure CORS restritamente e utilize headers de segurança:

// Configuração CORS segura
Access-Control-Allow-Origin: https://app.exemplo.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

// Headers de segurança adicionais
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=()

Evite expor informações de infraestrutura em mensagens de erro:

// Incorreto - expõe detalhes internos
HTTP/1.1 500 Internal Server Error
{
  "error": "Erro no banco PostgreSQL versão 14.2 no servidor db-interno-01"
}

// Correto - mensagem genérica e segura
HTTP/1.1 500 Internal Server Error
{
  "error": "internal_server_error",
  "message": "Ocorreu um erro inesperado. Tente novamente mais tarde.",
  "request_id": "abc-123-def-456"
}

Conclusão

A segurança de APIs públicas é um processo contínuo que exige atenção em múltiplas camadas. Desde a autenticação robusta com OAuth 2.0 até o monitoramento constante com logs anônimos, cada prática contribui para construir uma API resiliente e confiável. A implementação cuidadosa dessas boas práticas reduz significativamente a superfície de ataque e protege tanto os dados dos usuários quanto a infraestrutura da aplicação.

Lembre-se: segurança não é um destino, mas uma jornada de melhoria contínua. Revise regularmente suas políticas, atualize dependências e mantenha-se informado sobre novas ameaças e contramedidas.

Referências