O cenário de segurança de APIs em 2026
APIs REST se tornaram o sistema nervoso da web moderna. Aplicativos mobile, frontends SPA, integrações B2B, automações e sistemas de IoT - todos dependem de APIs para funcionar. E exatamente por isso que APIs se tornaram o vetor de ataque preferido: em vez de atacar um frontend protegido por CSP, validações de formulario e captchas, um atacante prefere ir direto na API, onde frequentemente ha menos proteções.
O relatorio State of API Security da Salt Security de 2024 aponta que 91% das organizações sofreram algum incidente de segurança relacionado a APIs nos últimos 12 meses. O relatorio da Akamai indica que ataques a APIs cresceram 137% entre 2022 e 2024. A OWASP, reconhecendo a gravidade do cenário, criou uma lista específica para APIs: o OWASP API Security Top 10, publicado em 2023 com atualizações para cobrir os novos padrões de ataque.
As principais vulnerabilidades em APIs REST
O OWASP API Security Top 10 de 2023 lista os vetores mais críticos:
API1:2023 - Broken Object Level Authorization (BOLA): A vulnerabilidade mais comum. Ocorre quando a API não verifica se o usuário autenticado tem permissão para acessar o objeto específico que está requisitando. Exemplo: GET /api/orders/12345 retorna o pedido 12345 sem verificar se pertence ao usuário autenticado, permitindo que um usuário acesse pedidos de outros usuários simplesmente mudando o número na URL.
API2:2023 - Broken Authentication: Tokens JWT sem expiração, chaves de API em texto plano, ausencia de rotação de credenciais, endpoints de autenticação sem rate limiting e senhas fracas aceitas.
API3:2023 - Broken Object Property Level Authorization: A API retorna mais campos do que o cliente deveria ver. Exemplo: um endpoint de perfil retorna {"name": "Joao", "email": "[email protected]", "isAdmin": false, "internalId": "abc123"} - o campo isAdmin não deveria ser visível.
API4:2023 - Unrestricted Resource Consumption: Ausencia de rate limiting, limites de tamanho de payload, limites de paginação e timeout. Um atacante pode fazer 10.000 requests por segundo ou enviar um payload de 100MB para derrubar o serviço.
API5:2023 - Broken Function Level Authorization: Endpoints administrativos acessíveis sem autorização adequada. Ex: DELETE /api/admin/users/{id} sem verificar o claim de admin no token JWT.
Quem foi afetado
Os casos reais de brechas em APIs são numerosos e impactantes. Em 2021, a Peloton teve uma API de usuário que retornava dados de qualquer conta sem autenticação, expondo dados de 4 milhoes de usuários. Em 2022, o vazamento da T-Mobile (37 milhoes de usuários) começou pela exploração de uma API que permitia busca por número de conta sem rate limiting. Em 2023, a brecha na API do ChatGPT expou histórico de conversas de outros usuários para uma porcentagem dos clientes ChatGPT Plus. Em 2024, a API da AT&T foi explorada via credential stuffing sem rate limiting, resultando no vazamento de dados de 73 milhoes de contas.
Como identificar vulnerabilidades em APIs
Ferramentas especializadas para auditoria de segurança de APIs incluem o OWASP ZAP com o plugin API Scanner, Postman com Interceptor para captura e replay de requests, Burp Suite Pro para análise manual aprofundada, e o 42Crunch para análise de especificações OpenAPI/Swagger contra as vulnerabilidades do OWASP API Top 10.
Testes manuais essenciais incluem: testar BOLA acessando recursos de outros usuários, testar ausencia de autenticação em todos os endpoints (incluindo documentação, health checks e webhooks), verificar se a API aceita payloads excessivamente grandes sem erro, e testar se endpoints administrativos são acessíveis sem claims de admin.
Como proteger sua API REST
1. Autenticação e autorização robustas
Use JWT com expiração curta (15-60 minutos) para access tokens e refresh tokens com rotação. Configure exp, iat e nbf em todos os tokens. Assine com RS256 (assimetrico) em vez de HS256 quando possivelmente tokens precisam ser verificados por multiplos serviços. Implemente Broken Object Level Authorization em todos os endpoints que acessam recursos por ID: sempre verifique se recurso.userId === token.userId ou se o usuário tem permissão explicita.
Exemplo em Node.js com verificação BOLA: const order = await db.orders.findOne({id: req.params.id}); if (!order || order.userId !== req.user.id) { return res.status(403).json({error: 'Acesso negado'}); }
2. Rate Limiting
Implemente rate limiting em todos os endpoints, com limites diferenciados por tipo:
- Endpoints de autenticação (/login, /register, /forgot-password): 5-10 requests por minuto por IP
- Endpoints de leitura geral: 100-300 requests por minuto por usuário autenticado
- Endpoints de escrita: 30-60 requests por minuto por usuário autenticado
- Endpoints de exportação/relatorio: 5-10 requests por hora por usuário
Em Node.js com express-rate-limit: const limiter = rateLimit({ windowMs: 60 * 1000, max: 100, standardHeaders: true, legacyHeaders: false }); app.use('/api/', limiter);
Em .NET com AspNetCoreRateLimit ou o built-in Rate Limiting do .NET 7+: builder.Services.AddRateLimiter(options => { options.AddFixedWindowLimiter("fixed", opt => { opt.Window = TimeSpan.FromMinutes(1); opt.PermitLimit = 100; }); });
3. Validação de schema e sanitização
Todo payload de entrada deve ser validado contra um schema rigido antes de qualquer processamento. Rejeite propriedades extras (additionalProperties: false no JSON Schema). Defina maxLength em todos os campos de string. Defina limites numericos (minimum, maximum) em campos numericos. Rejeite tipos inesperados.
Em Node.js com Zod: const createUserSchema = z.object({ name: z.string().min(2).max(100), email: z.string().email().max(254), password: z.string().min(8).max(128) }); app.post('/users', (req, res) => { const result = createUserSchema.safeParse(req.body); if (!result.success) return res.status(400).json(result.error); });
4. CORS configurado corretamente
Nunca use Access-Control-Allow-Origin: * em APIs que retornam dados de usuário. Liste explicitamente as origens permitidas. Rejeite preflight requests de origens não autorizadas. Não inclua Access-Control-Allow-Credentials: true com wildcard de origem.
5. HTTPS obrigatório com HSTS
Redirecione HTTP para HTTPS em nível de load balancer ou proxy. Configure HSTS no servidor: Strict-Transport-Security: max-age=31536000; includeSubDomains. Nunca aceite credenciais (Authorization header, cookies de sessao) em conexões HTTP.
6. Filtro de propriedades na resposta
Nunca retorne o objeto de banco diretamente. Mapeie para um DTO que contem apenas os campos necessarios. Em .NET, use DTOs separados. Em Node.js, use select() ou pick() para selecionar apenas campos necessarios antes de retornar.
7. Logs e monitoramento
Registre todas as requisições com: timestamp, IP, userId (se autenticado), endpoint, status code, tempo de resposta. Configure alertas para: picos de 401/403 (possível brute force), picos de 500 (possível exploração), volumes anormais de requests por IP. Use ferramentas como Datadog, New Relic, Elastic APM ou Grafana + Loki para correlacionar logs.
Análise técnica
A especificação OpenAPI/Swagger e uma das melhores ferramentas de segurança subutilizadas. Quando sua API tem uma especificação OpenAPI completa e precisa, ferramentas como 42Crunch e OWASP Zap API Scanner podem auditar automaticamente contra o OWASP API Top 10. Configure o projeto para gerar a especificação automaticamente a partir das anotações de código (como Swashbuckle em .NET ou swagger-jsdoc em Node.js) e inclua a validação OpenAPI no pipeline de CI/CD.
Para APIs públicas ou com alta exposição, considere um API Gateway como Kong, AWS API Gateway ou Apigee. Eles oferecem rate limiting, autenticação, logging e WAF em uma camada separada da logica de negócio, com políticas centralizadas e observabilidade integrada.
Impacto e consequencias
Uma API insegura e um vetor de ataque direto para os dados mais sensiveis da organização: banco de dados de usuários, dados financeiros, informações medicas, propriedade intelectual. Diferente de um ataque a frontend (que requer engano do usuário), um ataque a API pode ser automatizado e executado em escala - um script pode fazer 10.000 requests para testar BOLA em segundos. Do ponto de vista regulatório, vazamentos via API estão sujeitos as mesmas penalidades do GDPR e LGPD que qualquer outro vazamento de dados pessoais.
Dicas práticas e boas práticas
Checklist de segurança de API para produção:
1. Todos os endpoints verificam autenticação? Inclusive health checks que possam revelar versões de software.
2. Todos os endpoints que retornam recursos verificam autorização a nível de objeto (BOLA)?
3. Rate limiting configurado em todos os endpoints, com valores mais restritivos em autenticação?
4. Validação de schema com rejeição de campos extras e limites de tamanho?
5. Respostas de erro não revelam detalhes internos (stack traces, versões, queries SQL)?
6. CORS configurado com lista branca de origens (sem wildcard para APIs autenticadas)?
7. Tokens JWT tem expiração configurada e são verificados em todo request?
8. Logs incluem IP, userId, endpoint e status para todos os requests?
9. Alertas configurados para volumes anormais de 401/403/500?
10. Testes de segurança no pipeline de CI/CD (OWASP ZAP, 42Crunch)?
Conclusao: o que fazer agora
Se você tem uma API em produção, a primeira ação e testar BOLA nos 3 endpoints mais críticos (aqueles que retornam dados de usuário por ID). Crie duas contas de teste, autentique-se com a conta A, e tente acessar recursos da conta B mudando o ID na URL. Se conseguir, você tem BOLA - a vulnerabilidade número 1 do OWASP API Top 10.
A segunda ação e verificar o rate limiting no endpoint de login. Use uma ferramenta como Apache Bench ou wrk para enviar 50 requests em 10 segundos e veja se a API responde com 429 (Too Many Requests) ou aceita todos. Sem rate limiting em autenticação, sua API e vulnerável a credential stuffing e brute force.
Use o TrustSiteMonitor para uma auditoria automatizada que cobre os principais pontos do OWASP API Top 10, incluindo verificação de autenticação em endpoints públicos, rate limiting, headers de segurança e exposição de informações sensiveis em respostas de erro.