Este artigo faz parte do guia completo de segurança de APIs.
REST
Em REST, o foco está em autorização por objeto e por função, exposição excessiva de campos e inconsistência entre endpoints. Versões antigas e rotas de administração costumam ser os pontos mais frágeis.
GraphQL
GraphQL dá flexibilidade ao cliente — e isso muda o risco. Consultas profundamente aninhadas ou com aliases repetidos podem consumir recursos; a introspecção, se exposta, revela o schema inteiro; e a autorização precisa ser aplicada por campo, não só por consulta.
Além disso, é comum um único endpoint concentrar tudo, o que dificulta limites por rota. O controle precisa ser por complexidade e por profundidade da consulta.
- Limitar profundidade e complexidade das queries.
- Desativar introspecção em produção (quando não necessária).
- Autorizar por campo e por tipo, não apenas no endpoint.
- Atenção a mutações: valem tanto quanto as leituras.
gRPC
gRPC usa HTTP/2 e contratos definidos (protobuf), o que favorece consistência. Os riscos se deslocam para autenticação, propagação de contexto/permissões entre serviços e exposição de métodos internos.
Em arquiteturas de microsserviços, um serviço que confia em outro sem revalidar a identidade do usuário é uma porta de entrada silenciosa.
O que é igual em todas
Independentemente do estilo, o essencial não muda: autenticar bem, autorizar no servidor por objeto e por função, limitar consumo e devolver só o necessário. O protocolo muda a forma; a disciplina é a mesma.
Perguntas frequentes
GraphQL é menos seguro que REST?
Não é intrinsecamente menos seguro, mas exige cuidados específicos (limites de consulta e autorização por campo) que, se ignorados, ampliam a superfície.