# 9 práticas de segurança em API REST que você ignora > APIs REST exigem 9 práticas de segurança frequentemente negligenciadas. Autenticação multifator, validação de entrada, limitação de taxa de requisições, criptografia de dados em trânsito e repouso, uso de tokens JWT com expiração curta, registro de logs de acesso, testes de penetração regulares, sanitização de parâmetros de URL e implementação de CORS restrito protegem contra vulnerabilidades comuns. *Blog Sem Juízo · Destaques · 01 de julho de 2026 · Igor Bastos* Você acha que sua API REST está segura? Pois é, eu também achava. Até o dia em que um pentest amigável me mostrou 9 brechas que eu ignorava. Aqui vai o checklist que ninguém te conta. Morri de novo, e a culpa não é minha. Dessa vez, não foi um boss no Elden Ring, foi minha própria API REST que eu jurava estar segura. Um pentest amigável expôs 9 buracos que eu, na minha soberba de dev, ignorava. Se você acha que sua API está blindada, senta aqui e chora junto comigo. Segurança em API REST não é só colocar um token e rezar. É um checklist chato, mas necessário, que separa o dev que dorme tranquilo do que acorda com notificação de vazamento. Aqui estão as 9 práticas que você provavelmente está ignorando, e que vão te salvar de um trauma. ## 1. Sempre usar TLS, mas não só isso TLS é o mínimo. O problema? Muita gente usa TLS 1.0 ou 1.1, que já são aposentados. Exija TLS 1.2 ou 1.3. E não adianta criptografar a transmissão se você deixa porta 80 aberta redirecionando, um ataque MITM ainda pode acontecer se o redirecionamento for mal configurado. No Brasil, até o certificado SSL é caro, mas um Let's Encrypt grátis já salva. ## 2. Autenticação que não é só um token JWT JWT é prático, mas se você não rotaciona a chave secreta ou deixa o token expirar em 7 dias, é convite pra desastre. Use OAuth2 com refresh tokens de curta duração (15 minutos no máximo). E nunca, jamais, coloque dados sensíveis no payload do JWT, ele não é criptografado por padrão. ## 3. Rate limiting que você acha que não precisa Sua API REST sem limite de requisições é um buffet livre para ataques de força bruta. Implemente rate limiting por IP e por usuário. Comece com 100 requisições por minuto para endpoints públicos e 10 para login. O Nginx já faz isso de graça; não tem desculpa. ## 4. Validação de entrada que não é só regex SQL injection, XSS, NoSQL injection, sua API está vulnerável se você confia no cliente. Valide tipo, tamanho e formato de cada campo no servidor. Um campo id numérico? Rejeite string. Um campo email? Use validação de domínio. E nunca monte queries concatenando parâmetros. ## 5. Chaves de API com escopo, não tudo ou nada Aquela chave de API que você gera e dá acesso total à sua aplicação? Péssima ideia. Crie chaves com escopos específicos: leitura, escrita, admin. Se um cliente só precisa listar recursos, dê uma chave de leitura. Assim, se vazar, o estrago é limitado. ## 6. Logs que não expõem dados sensíveis Registrar tudo é bom para debugging, mas se você loga senhas, tokens ou CPF, está criando um passivo de segurança. Use mascaramento (ex.: ****1234) e nunca logue headers de autorização. Um log bem feito salva sua pele; um mal feito, entrega seus dados de bandeja. ## 7. Versionamento de API que você adia Mudar um endpoint sem versionar quebra clientes e abre brechas de compatibilidade. Use versão na URL (/v1/) ou no header. Quando precisar remover um campo, marque como obsoleto primeiro. Isso evita que ataques explorem comportamento inesperado de versões antigas. ## 8. Restrição de métodos HTTP Sua API aceita DELETE em um endpoint que só deveria ser GET? Um PUT que permite criar recursos onde só deveria atualizar? Restrinja métodos por endpoint. Use @RequestMapping no Spring ou decorators no Flask para bloquear o que não for necessário. Menos superfície de ataque, menos dor de cabeça. ## 9. Dependências atualizadas (sim, essa é chata) Aquela biblioteca de 2020 que você usa pra autenticação? Tem CVE conhecida. Faça varredura de vulnerabilidades com ferramentas como Snyk ou Dependabot. No Brasil, a gente releva update porque "tá funcionando", mas um ataque explorando lib desatualizada é a causa mais comum de breaches. Se você leu até aqui e sentiu um frio na espinha, respira. Ninguém nasce sabendo, e a culpa não é sua, mas a correção é. Comece pelo rate limiting e pela validação de entrada: são os dois que mais previnem ataques comuns. Depois, vá subindo a complexidade. Sua API REST agradece. ## FAQ ### Quais são as melhores práticas de segurança para APIs REST? As principais incluem: usar TLS 1.2+, autenticação forte (OAuth2), rate limiting, validação de entrada no servidor, chaves de API com escopo, logs seguros, versionamento, restrição de métodos HTTP e manutenção de dependências. Nenhuma é opcional. ### O que é segurança de API? Segurança de API é o conjunto de práticas para proteger interfaces de programação contra acessos não autorizados, vazamentos de dados e ataques como injeção, força bruta e DDoS. Inclui autenticação, criptografia, validação e monitoramento. ### O que é REST na API? REST (Representational State Transfer) é um estilo arquitetural para APIs que usa HTTP como protocolo, com recursos identificados por URLs e operações padronizadas (GET, POST, PUT, DELETE). É stateless e leve. ### APIs RESTful seguras? Sim, desde que sigam práticas como TLS, autenticação robusta, validação de entrada e rate limiting. Uma API RESTful sem essas medidas é tão segura quanto uma porta destrancada. --- Fonte (canonical): https://blogsemjuizo.com.br/destaques/9-praticas-de-seguranca-em-api-rest-que-voce-ignora/