REST domina 93% das equipas de desenvolvimento e o GraphQL já corre em produção em mais de metade das empresas, segundo o relatório State of the API 2025 da Postman. Mas qual das duas arquiteturas é mais segura para expor dados críticos em 2026? A resposta não é simples: cada estilo de API traz a sua própria superfície de ataque, e escolher mal pode custar caro, como mostraram as violações da Salesforce e da ServiceNow este ano. Este artigo compara REST e GraphQL em segurança, desempenho, custo e casos reais, com base no OWASP API Security Top 10 2023 e em dados de mercado verificados.

Para equipas de engenharia em Portugal, a escolha entre REST e GraphQL raramente é apenas técnica. Bancos, seguradoras e operadoras de telecomunicações que expõem APIs a parceiros externos têm de justificar essa escolha perante auditores, reguladores e clientes empresariais. Este guia junta os números de adoção, os benchmarks de desempenho mais recentes, os preços reais de mercado e cinco incidentes documentados para ajudar a decidir com dados, não com preferência pessoal.

REST vs GraphQL: o que muda na segurança da API

REST (Representational State Transfer) organiza dados em endpoints fixos, um por recurso: /utilizadores/123, /pedidos/456. Cada pedido devolve uma estrutura pré-definida pelo servidor. O GraphQL, criado pelo Facebook e hoje mantido pela GraphQL Foundation, inverte essa lógica: existe um único endpoint e é o cliente que escolhe exatamente quais campos quer receber, numa só chamada.

Essa diferença estrutural muda o modelo de ameaça por completo. Numa API REST, um atacante testa endpoints um a um à procura de falhas de autorização – o clássico Broken Object Level Authorization (BOLA), que continua a ser a vulnerabilidade mais comum em auditorias de API segundo a OWASP API Security Top 10 2023. Numa API GraphQL, o atacante tem outra arma: o endpoint de introspecção, que pode revelar todo o esquema de dados (tipos, campos, mutações) sem autenticação, e consultas aninhadas que multiplicam a carga no servidor até provocar negação de serviço.

Por isso, comparar REST com GraphQL em termos de segurança não é dizer “um é seguro, o outro não”. É perceber que cada arquitetura desloca o risco para sítios diferentes: REST espalha o risco por dezenas de endpoints; GraphQL concentra-o num único ponto de entrada, mas com uma superfície de ataque muito mais rica.

Tabela comparativa: REST vs GraphQL em 12 critérios

A tabela seguinte resume as diferenças técnicas e de segurança entre as duas arquiteturas, com base na documentação oficial e nos estudos de desempenho mais recentes.

CritérioRESTGraphQL
Modelo de endpointMúltiplos endpoints por recursoEndpoint único, consulta dirigida pelo cliente
Formato de respostaFixo, definido pelo servidorVariável, campos escolhidos pelo cliente
Adoção entre equipas (2025)93%33%
Adoção empresarial em produção~83% das APIs públicas50-70% das empresas usam-no algures
Vulnerabilidade típica nº1Broken Object Level Authorization (BOLA)Introspecção exposta / abuso de profundidade
Rate limitingSimples, por endpointComplexo, precisa de análise de custo de query
Latência em queries complexas~250ms (múltiplas chamadas)~180ms (uma chamada agregada)
Throughput sob cargaSuperior (~20.000 req/s em testes)Inferior (~15.000 req/s em testes)
Tamanho do payloadMaior (over-fetching comum)30-62% menor em média
DocumentaçãoOpenAPI/Swagger, manualEsquema autodescritivo (introspecção)
Ferramentas de testePostman, Burp Suite, NucleiPostman, InQL, GraphQL Cop
Curva de aprendizagemBaixaMédia a alta
Melhor cenário de usoMicroserviços de alto débito, APIs públicas simplesApps móveis, dashboards, agregação de múltiplas fontes

Os números de adoção vêm do relatório Postman State of the API 2025 e de estimativas de mercado da Apollo GraphQL para adoção empresarial. Os dados de latência e payload aparecem detalhados na secção seguinte, com as fontes de cada estudo.

OWASP API Security Top 10 2023: onde REST e GraphQL falham mais

A lista oficial da OWASP para segurança de APIs foi atualizada em 2023 e continua a ser a referência em 2026, sem uma versão mais recente publicada até à data. Vale a pena mapear cada categoria porque a exposição muda consoante a arquitetura escolhida, e porque a maioria das auditorias de segurança contratadas por empresas portuguesas usa esta lista como estrutura de referência para classificar a gravidade de cada falha encontrada.

  • API1:2023 – Broken Object Level Authorization. O problema mais comum em ambas as arquiteturas: falhar a verificar se o utilizador tem direito ao objeto pedido.
  • API2:2023 – Broken Authentication. Tokens mal validados, sessões que não expiram, chaves de API deixadas em código-fonte.
  • API3:2023 – Broken Object Property Level Authorization. Junta os antigos “Excessive Data Exposure” e “Mass Assignment” – devolver ou aceitar campos que o cliente não devia ver nem alterar.
  • API4:2023 – Unrestricted Resource Consumption. Em GraphQL, isto materializa-se em ataques de profundidade e de alias, em que uma única query aninhada obriga o servidor a milhares de operações internas.
  • API5:2023 – Broken Function Level Authorization. Um utilizador comum acede a uma mutação ou endpoint reservado a administradores.
  • API6:2023 – Unrestricted Access to Sensitive Business Flows. Automatização abusiva de fluxos de negócio (compras, registos, reservas) sem limites.
  • API7:2023 – Server-Side Request Forgery (SSRF). Categoria nova em 2023, relevante quando a API aceita URLs fornecidos pelo utilizador.
  • API8:2023 – Security Misconfiguration. CORS mal configurado, cabeçalhos de segurança ausentes, ambientes de debug expostos em produção.
  • API9:2023 – Improper Inventory Management. Endpoints antigos ou versões de teste esquecidas e ainda acessíveis – foi este o vetor usado contra a ServiceNow em junho de 2026.
  • API10:2023 – Unsafe Consumption of APIs. Confiar cegamente em dados vindos de APIs de terceiros integradas no sistema.

Consulte a lista completa da OWASP API Security Top 10 2023 para detalhes técnicos de cada categoria. O ponto central: BOLA lidera as auditorias há anos e continua a ser o bug de maior gravidade encontrado em testes de penetração, segundo a análise da Wiz sobre o OWASP API Top 10.

Riscos específicos do REST

Numa API REST, a superfície de ataque cresce com o número de endpoints. Cada rota nova é outra porta a fechar. Os riscos mais frequentes incluem falhas de autorização objeto a objeto (BOLA), inventário de endpoints desatualizado (versões antigas de uma API que continuam ativas sem que ninguém se lembre delas) e excesso de exposição de dados, quando um endpoint devolve o registo completo em vez de só os campos necessários.

Este último ponto, o excesso de exposição de dados, é particularmente traiçoeiro porque não parece um bug à primeira vista. Um endpoint que devolve o objeto “utilizador” completo, incluindo campos internos como hash de password antiga, morada de faturação ou notas administrativas, funciona sem erros visíveis. O problema só aparece quando alguém analisa o tráfego de rede e percebe que o cliente recebe dados que nunca deveria ver, mesmo que a interface não os mostre. É por isso que a categoria API3:2023 da OWASP junta este risco à validação de propriedades no momento de escrita (mass assignment), tratando os dois lados do mesmo problema, o que entra e o que sai, como uma única disciplina de controlo.

O caso da Salesforce em julho de 2026 ilustra bem este ponto: os atacantes abusaram de uma API REST legada que “não tinha controlos de autenticação atualizados” para extrair 1,1 milhões de registos de CRM através de tokens OAuth e scripts automatizados. Já a ServiceNow, em junho de 2026, expôs um endpoint REST não autenticado (/api/now/related_list_edit/create) configurado incorretamente com requires_authentication=false, permitindo consultas diretas às tabelas de clientes hospedadas na plataforma.

Ambos os incidentes têm a mesma raiz: não é a arquitetura REST em si que falha, é a gestão de inventário e configuração ao longo do tempo. Uma API REST bem desenhada, com autenticação forte em cada endpoint e testes de autorização automatizados, continua a ser uma opção sólida para a maioria dos casos de uso empresariais.

Riscos específicos do GraphQL

O GraphQL troca “muitos endpoints simples” por “um endpoint poderoso e complexo”. Isso concentra o risco, mas também facilita a defesa se for bem implementada, e complica-a se não for. Ao contrário do REST, onde cada vulnerabilidade tende a ficar isolada a um único endpoint, uma falha de configuração no esquema GraphQL pode afetar simultaneamente todos os dados que esse esquema expõe, porque não existe fronteira física entre “recursos” como existe em REST.

Introspecção exposta

Por definição, o GraphQL é autodescritivo: qualquer cliente pode perguntar ao servidor “que tipos, campos e mutações existem?”. Se essa funcionalidade não for desativada em produção, um atacante obtém um mapa completo da base de dados interna sem sequer autenticar-se. Foi exatamente isto que aconteceu com o Parse Server (CVE-2025-53364, divulgada em julho de 2025): a API GraphQL permitia introspecção pública sem token de sessão nem chave mestra, expondo metadados detalhados sobre tipos, campos, queries e mutações. A correção chegou nas versões 7.5.3 e 8.2.2.

Ataques de profundidade e de alias

Como o GraphQL permite consultas aninhadas, um pedido malicioso pode pedir o mesmo campo centenas de vezes com aliases diferentes, ou aninhar relações umas dentro das outras até esgotar a memória do servidor. Foi este o mecanismo por trás da CVE-2024-39895 no Directus (julho de 2024), corrigida na versão 10.12.0, e da CVE-2024-47614 na biblioteca async-graphql em Rust (setembro de 2024). A Wallarm documentou também, num estudo de caso publicado em outubro de 2024, um exploit GraphQL real que expôs 30 milhões de contas de utilizador.

Em julho de 2026, o GitHub confirmou uma campanha de reconhecimento em massa que usou contas falsas (“ghost accounts”) para gerar volumes elevados de queries automatizadas, com a maioria dos pedidos dirigida à API GraphQL da plataforma e o resto a rotas REST. Não houve exfiltração confirmada de dados, mas o episódio mostra como o GraphQL pode ser explorado para enumeração em massa quando não existem limites de complexidade de query.

Autenticação e autorização: OAuth 2.0 e JWT em REST vs GraphQL

A camada de autenticação é, na prática, igual nas duas arquiteturas: a esmagadora maioria das APIs modernas usa OAuth 2.0 para delegar acesso e JSON Web Tokens (JWT) para transportar a identidade do utilizador entre pedidos. A diferença aparece na autorização, ou seja, em decidir o que cada utilizador autenticado pode ver ou fazer.

Numa API REST, a autorização costuma viver no middleware de cada endpoint: um filtro de acesso corre antes de qualquer lógica de negócio, verificando o token e as permissões associadas àquela rota específica. É um modelo direto de auditar, porque cada endpoint tem uma responsabilidade única e é fácil de testar isoladamente com ferramentas como o Postman ou o Burp Suite.

No GraphQL, essa verificação tem de acontecer dentro de cada resolver, a função que resolve um campo específico do esquema. Isto significa que a autorização deixa de estar centralizada num único ponto de entrada e passa a espalhar-se por dezenas ou centenas de resolvers. Esquecer um único resolver sem verificação de permissões é suficiente para abrir uma falha de Broken Object Level Authorization, mesmo que todos os outros estejam corretamente protegidos. Frameworks como o Apollo Server e o GraphQL Shield ajudam a centralizar essa lógica em middlewares de esquema, mas exigem disciplina de configuração que muitas equipas subestimam ao migrar de REST.

Vale ainda notar uma diferença prática no uso de tokens: como o GraphQL agrega múltiplos recursos numa só chamada, um único JWT comprometido pode dar acesso a mais dados de uma só vez do que aconteceria contra uma API REST, onde o atacante teria de repetir o ataque contra vários endpoints separados. Por isso, a rotação frequente de tokens e a aplicação do princípio do menor privilégio (scopes OAuth granulares) importam ainda mais em ambientes GraphQL de produção.

Rate limiting e proteção contra abuso de recursos

Limitar o número de pedidos que um cliente pode fazer por minuto é trivial em REST: basta contar chamadas a um endpoint e bloquear acima de um limite fixo. A categoria API4:2023 (Unrestricted Resource Consumption) do OWASP cobre exatamente este ponto, e a maioria das gateways de API, incluindo o AWS API Gateway e o Kong, oferece rate limiting nativo por rota.

Em GraphQL, contar “pedidos” não chega, porque uma única query pode ser tão barata como pedir um nome de utilizador ou tão cara como agregar milhares de registos relacionados em várias camadas de profundidade. Por isso, a defesa correta não é limitar o número de chamadas, é limitar o custo computacional de cada query, através de três técnicas complementares: limitação de profundidade (depth limiting, normalmente entre 5 e 10 níveis), análise de complexidade (atribuir um “peso” a cada campo e somar o custo total antes de executar a query) e limites de alias (impedir que o mesmo campo seja repetido centenas de vezes num único pedido para multiplicar a carga na base de dados).

Sem estas três camadas configuradas, uma API GraphQL fica exposta a ataques de negação de serviço com um único pedido HTTP, algo que seria necessário centenas de pedidos separados para replicar contra uma API REST equivalente. Isto explica por que razão bibliotecas como o graphql-depth-limit e o graphql-cost-analysis se tornaram, na prática, tão obrigatórias em produção como a própria autenticação.

Contexto regulatório: GDPR, NIS2 e DORA na União Europeia

Para empresas a operar em Portugal e no resto da União Europeia, a escolha de arquitetura de API não é neutra do ponto de vista legal. O Regulamento Geral de Proteção de Dados (RGPD/GDPR) exige que qualquer exposição de dados pessoais através de uma API, seja REST ou GraphQL, tenha controlos de acesso demonstráveis e um registo auditável de quem acedeu a quê. Uma falha como a da ServiceNow, com um endpoint sem autenticação, é precisamente o tipo de incidente que gera notificação obrigatória à Comissão Nacional de Proteção de Dados dentro de 72 horas.

A Diretiva NIS2, transposta para a legislação portuguesa e já em vigor para operadores de setores essenciais e importantes, alarga as obrigações de gestão de risco de cibersegurança a mais empresas do que a legislação anterior, incluindo requisitos explícitos sobre segurança da cadeia de fornecimento de software, categoria onde caem tanto bibliotecas GraphQL como gateways REST de terceiros. Já o Regulamento DORA (Digital Operational Resilience Act), aplicável ao setor financeiro desde janeiro de 2025, exige testes de resiliência digital regulares, o que na prática empurra bancos e seguradoras portuguesas a incluir testes de penetração específicos para GraphQL (introspecção, profundidade de query) nos seus programas de auditoria, e não apenas os testes tradicionais desenhados para REST.

Na prática, nenhuma destas normas favorece uma arquitetura em detrimento da outra. O que exigem, em ambos os casos, é prova de que os controlos do OWASP API Security Top 10 2023 foram aplicados e testados, com documentação que resista a uma auditoria externa.

Desempenho: benchmarks de 2025-2026 lado a lado

Os números de desempenho variam consoante o cenário testado, mas três estudos independentes de 2025-2026 convergem num padrão: REST ganha em pedidos simples e alto débito, GraphQL ganha quando o cliente precisa de agregar dados de várias fontes numa só chamada.

Fonte / cenárioRESTGraphQLVencedor
Latência em queries complexas multi-recurso250 ms180 msGraphQL (-28%)
Throughput sob carga20.000 req/s15.000 req/sREST (+33%)
Teste “hello-world” simples – latência média7,68 ms13,51 msREST
Teste “hello-world” simples – pedidos por segundo11.972 RPS7.085 RPSREST
Estudo académico (SCITEPRESS 2025), duração média de pedido247,17 ms915,14 msREST
Redução de payload num feed tipo rede socialBase-62% em médiaGraphQL
Redução de payload em enterprise scaleBase-30% a -50%GraphQL
Cenário under-fetching (mais de 4 endpoints REST)Base36,84% a 93,04% mais rápidoGraphQL

A leitura destes dados é clara: para microserviços de alto volume com respostas simples e previsíveis, o REST continua a vencer em throughput e latência bruta. Para ecrãs que precisam de dados de múltiplas fontes numa só chamada (dashboards, apps móveis, feeds), o GraphQL reduz drasticamente o número de pedidos e o volume de dados transferidos, à custa de 5 a 10 ms extra de análise da query no servidor.

Tabela de preços: quanto custa gerir cada arquitetura

A escolha entre REST e GraphQL também tem impacto direto na fatura de infraestrutura. Aqui estão os preços de 2026 das principais ferramentas de gateway e gestão de API.

FerramentaModeloPreço 2026
AWS API Gateway (REST)Por milhão de pedidos3,50 USD/milhão (primeiros 333M/mês)
AWS API Gateway (HTTP)Por milhão de pedidos1,00 USD/milhão – 71% mais barato que REST
Apollo GraphOS (GraphQL)Plano Developer, por operação5,00 USD/milhão de operações, sem compromisso
Apollo GraphOS StandardPlano empresarial2.500 USD/mês, inclui 250M de pedidos
Kong Gateway OSSSelf-hostedGratuito
Kong Konnect PlusGerido, por serviço~105 USD/mês por serviço + 200 USD/milhão extra
PostmanPor utilizador/mêsGrátis a 49 USD/utilizador (plano Enterprise anual)
Azure API Management – ConsumptionServerless0 USD base + ~3,50 USD/milhão de chamadas (1M grátis)
Azure API Management – DeveloperInstância dedicadaA partir de 50 USD/mês
Azure API Management – Standard v2Instância dedicada~250 USD/mês

Na prática, o REST via AWS API Gateway HTTP é a opção mais barata para tráfego simples e volumoso. O GraphQL via Apollo torna-se competitivo quando o número de pedidos é menor, mas cada um agrega mais dados, porque está a substituir várias chamadas REST por uma só. Vale ainda somar o custo indireto de ferramentas de teste e auditoria: uma equipa que já paga por Postman ou Burp Suite para REST vai precisar de orçamento adicional para extensões específicas de GraphQL, um item que raramente entra na comparação inicial de custos mas que pesa no orçamento anual de segurança.

5 exemplos reais de incidentes de segurança em APIs

Nada ilustra melhor os riscos do que casos concretos. Estes cinco incidentes de 2024 a 2026 mostram como as falhas se manifestam em ambientes de produção.

  • Salesforce (julho de 2026, REST): exploração de uma API REST legada com controlos de autenticação desatualizados; 1,1 milhões de registos de CRM expostos, incluindo contactos e dados de negócio.
  • ServiceNow (junho de 2026, REST): endpoint REST não autenticado por má configuração (requires_authentication=false), permitindo acesso direto a tabelas de instâncias de clientes.
  • GitHub (julho de 2026, GraphQL + REST): campanha de reconhecimento em massa com contas falsas, maioritariamente contra a API GraphQL, usada para enumeração em larga escala.
  • Parse Server – CVE-2025-53364 (julho de 2025, GraphQL): introspecção pública do esquema GraphQL sem autenticação, expondo metadados internos da base de dados.
  • Incidente documentado pela Wallarm (outubro de 2024, GraphQL): exploit num serviço com API GraphQL vulnerável expôs 30 milhões de contas de utilizador, segundo o estudo de caso da empresa de segurança.

Repare no padrão: os dois maiores incidentes de 2026 (Salesforce, ServiceNow) aconteceram em APIs REST por falhas de configuração e autenticação, não por uma fraqueza intrínseca do REST. Já os incidentes GraphQL (Parse Server, GitHub, o caso da Wallarm) exploram características específicas da arquitetura, introspecção e profundidade de query, que precisam de controlos dedicados para serem mitigadas.

Vale também notar o que estes cinco casos têm em comum apesar das diferenças de arquitetura: em nenhum deles a causa raiz foi uma vulnerabilidade nova ou desconhecida. Tanto a falha de autenticação REST na Salesforce como a introspecção GraphQL exposta no Parse Server correspondem a categorias documentadas há anos no OWASP API Security Top 10. Isso reforça a conclusão mais incómoda para qualquer equipa de engenharia: a maioria dos incidentes graves em produção não resulta de ataques sofisticados, resulta de checklists de segurança básicos que não foram seguidos antes do lançamento.

Guia de migração: de REST para GraphQL sem abrir novas falhas

Muitas empresas não escolhem entre REST e GraphQL, acabam por correr os dois em paralelo, com o GraphQL a atuar como camada de agregação sobre serviços REST já existentes através do padrão Backend for Frontend (BFF). Se está a planear essa migração, siga esta sequência para não introduzir riscos novos. O erro mais comum observado em migrações reais não é técnico, é organizacional: tratar o lançamento do GraphQL como um projeto de produto sem envolver a equipa de segurança desde o primeiro esboço do esquema.

  1. Desative a introspecção em produção antes de publicar o primeiro endpoint GraphQL. É a primeira coisa que um scanner automatizado tenta.
  2. Implemente limites de profundidade e complexidade de query (depth limiting, cost analysis) para impedir consultas aninhadas que sobrecarregam a base de dados.
  3. Mantenha a autorização ao nível do objeto em cada resolver, replicando exatamente as regras que já existiam nos endpoints REST – o BOLA não desaparece só porque mudou a arquitetura.
  4. Desative o batching e o aliasing sem limites, ou imponha um número máximo de alias por pedido, para evitar ataques de amplificação.
  5. Faça o inventário de todos os endpoints REST antigos antes de os desligar. Um endpoint esquecido e ainda ativo é exatamente o vetor usado contra a ServiceNow.
  6. Corra os dois sistemas em paralelo durante a transição, com testes automatizados a comparar respostas REST e GraphQL para o mesmo pedido de dados.
  7. Adote ferramentas de auditoria específicas para GraphQL (InQL, GraphQL Cop) além das que já usa para REST (Burp Suite, Nuclei, Postman).
  8. Forme a equipa de segurança nas particularidades do GraphQL antes do lançamento. Os testes de penetração tradicionais, feitos para REST, não cobrem introspecção nem abuso de profundidade sem adaptação.

Prós e contras do REST

Prós: modelo simples e bem compreendido por praticamente toda a indústria (93% de adoção), ferramentas de teste maduras, cache HTTP nativo em cada endpoint, throughput superior sob carga elevada, custo mais baixo por pedido em serviços como AWS API Gateway HTTP.

Contras: over-fetching e under-fetching frequentes (o cliente recebe mais ou menos dados do que precisa), multiplicação de endpoints à medida que a aplicação cresce, risco elevado de inventário desatualizado (endpoints esquecidos), documentação manual sujeita a ficar desatualizada.

Prós e contras do GraphQL

Prós: o cliente pede exatamente os campos de que precisa, reduzindo o payload em 30% a 62% segundo os estudos citados; um único endpoint simplifica versionamento; esquema autodescritivo facilita a documentação; ideal para agregar dados de múltiplas fontes numa app móvel ou dashboard.

Contras: superfície de ataque concentrada num único ponto crítico; introspecção mal configurada expõe todo o esquema de dados; rate limiting tradicional não funciona bem (é preciso analisar o custo de cada query); throughput inferior ao REST em cenários de alto débito; curva de aprendizagem mais alta para as equipas de segurança.

5 casos de uso: qual arquitetura escolher

Nem todos os projetos têm o mesmo perfil de risco nem os mesmos requisitos de desempenho. Os cinco cenários seguintes cobrem os casos mais comuns encontrados em equipas de engenharia portuguesas e europeias.

  • API pública de alto volume (ex: pagamentos, logística): REST. O throughput superior e o cache HTTP nativo compensam a rigidez do formato fixo, e a maturidade das ferramentas de auditoria facilita a certificação por terceiros.
  • App móvel com ecrãs de dashboard complexos: GraphQL. Reduz o número de chamadas de rede e o consumo de dados do utilizador, algo crítico em ligações móveis instáveis ou com dados limitados.
  • Plataforma interna que agrega dados de vários microserviços: GraphQL como camada de agregação sobre REST, mantendo os serviços internos inalterados e reduzindo a complexidade percebida pelas equipas de frontend.
  • API financeira ou de saúde sujeita a auditoria regulatória: REST, pela maturidade das ferramentas de auditoria e pela simplicidade de aplicar controlos de acesso granulares por endpoint, um fator relevante sob o DORA e o RGPD.
  • Startup com equipa pequena e produto em rápida evolução: GraphQL, porque um único esquema evita ter de criar e manter dezenas de endpoints à medida que o produto muda, poupando tempo de engenharia num contexto de recursos limitados.

Em nenhum destes cinco cenários a decisão certa elimina a necessidade de aplicar o checklist de segurança descrito acima. A arquitetura determina onde investir esforço de proteção, não se esse esforço é dispensável.

Checklist de segurança antes de publicar uma API em produção

Independentemente da arquitetura escolhida, há um conjunto mínimo de verificações que qualquer equipa deve correr antes de expor uma API a tráfego real. Esta lista cruza os pontos específicos de REST e de GraphQL discutidos ao longo deste artigo.

  • Autenticação obrigatória em todos os endpoints e resolvers, sem exceções para rotas “internas” ou “temporárias” – foi exatamente uma exceção destas que expôs a ServiceNow.
  • Autorização verificada objeto a objeto, nunca apenas ao nível da rota ou do esquema geral.
  • Introspecção GraphQL desativada em todos os ambientes de produção, mantendo-a apenas em staging ou atrás de autenticação adicional.
  • Limites de profundidade, complexidade e alias configurados em qualquer endpoint GraphQL público.
  • Rate limiting ativo por utilizador, por IP e, no caso do GraphQL, por custo de query.
  • Inventário de endpoints atualizado e revisto trimestralmente, com desativação automática de versões antigas.
  • CORS configurado de forma restritiva, limitando origens autorizadas em vez de aceitar qualquer domínio.
  • Registo e monitorização de todos os pedidos, com alertas automáticos para padrões de tráfego anómalos.
  • Testes de penetração específicos para a arquitetura escolhida, incluindo ferramentas dedicadas a GraphQL quando aplicável.
  • Plano de resposta a incidentes documentado, com prazos de notificação alinhados com o RGPD e, quando aplicável, com a DORA.

Nenhum destes pontos é exclusivo de uma arquitetura. A diferença está na forma como cada um se implementa: um item como “autorização verificada objeto a objeto” significa um middleware por rota em REST, mas significa uma verificação dentro de cada resolver em GraphQL, dezenas ou centenas de pontos de verificação distintos em vez de um só.

Veredito: qual é mais seguro em 2026?

Nenhuma das duas arquiteturas é “mais segura” por definição. Os dados de 2026 mostram que ambas sofreram incidentes graves este ano. A diferença está em onde o risco se concentra e que tipo de controlos exige. O REST espalha o risco por muitos endpoints e exige disciplina de inventário; foi essa falta de disciplina, não uma falha de arquitetura, que custou 1,1 milhões de registos à Salesforce e expôs dados de clientes da ServiceNow. O GraphQL concentra o risco num único endpoint poderoso; sem introspecção desativada e limites de profundidade de query, esse único ponto vira um alvo de alto valor, como mostrou o caso do Parse Server.

Para a maioria das equipas em Portugal e na Europa, a resposta prática não é “REST ou GraphQL”, é “REST e GraphQL, cada um no seu lugar”: REST para serviços internos de alto débito e APIs públicas simples, GraphQL como camada de agregação para apps móveis e dashboards. O que separa uma implementação segura de um próximo incidente na lista não é a escolha da arquitetura, é a disciplina de aplicar o OWASP API Security Top 10 2023 a cada endpoint, seja ele REST ou GraphQL.

Se tivesse de resumir o veredito num único critério prático: escolha REST quando a prioridade é throughput, simplicidade de auditoria e maturidade de ferramentas; escolha GraphQL quando a prioridade é reduzir chamadas de rede e o esquema justifica o investimento em limitação de profundidade e complexidade desde o dia um. E, sobretudo, não trate a arquitetura escolhida como garantia de segurança. Os incidentes de 2026 mostraram, dos dois lados, que a arquitetura só é tão segura quanto a disciplina de quem a implementa.

Perguntas frequentes

O GraphQL é mais fácil de atacar do que o REST?

Não necessariamente mais fácil, mas diferente. Se a introspecção não for desativada em produção, um atacante consegue mapear todo o esquema de dados numa única consulta, algo que não tem equivalente direto em REST. Em compensação, o REST oferece mais superfície (mais endpoints) para procurar falhas de autorização isoladas.

É preciso escolher só uma das arquiteturas?

Não. Segundo estimativas ligadas à Apollo GraphQL e à Gartner, mais de metade das empresas já usam GraphQL como camada adicional sobre serviços REST existentes, em vez de o substituir por completo.

Qual é mais rápida, REST ou GraphQL?

Depende do cenário. Em pedidos simples e sob carga elevada, o REST tende a ser mais rápido (até 33% mais throughput em alguns testes). Em consultas complexas que agregam vários recursos, o GraphQL costuma reduzir a latência percebida porque substitui várias chamadas por uma só.

O que é o ataque de introspecção no GraphQL?

É o uso da funcionalidade nativa de autodescrição do GraphQL, pensada para ajudar programadores a explorar a API, para mapear todo o esquema de dados sem autenticação. Deve ser sempre desativada em ambientes de produção.

O BOLA afeta só APIs REST?

Não. O Broken Object Level Authorization é a vulnerabilidade número um do OWASP API Security Top 10 2023 e afeta ambas as arquiteturas sempre que um resolver ou endpoint não verifica corretamente se o utilizador tem direito ao objeto pedido.

Quanto custa gerir uma API REST vs GraphQL na AWS?

No AWS API Gateway, uma API REST custa 3,50 USD por milhão de pedidos, enquanto a variante HTTP (mais simples) custa 1,00 USD por milhão, 71% mais barata. Para GraphQL gerido via Apollo GraphOS, o plano Developer começa em 5,00 USD por milhão de operações.

Que ferramentas devo usar para testar a segurança de uma API GraphQL?

Além das ferramentas genéricas como Postman e Burp Suite, existem extensões específicas para GraphQL como o InQL e o GraphQL Cop, desenhadas para testar introspecção, profundidade de query e abuso de alias.

Vale a pena migrar uma API REST estável para GraphQL?

Só se houver um problema real a resolver, tipicamente over-fetching em apps móveis ou dashboards que agregam muitas fontes de dados. Uma API REST estável, bem documentada e sem esses sintomas não ganha nada em segurança ao migrar para GraphQL só por moda tecnológica; ganha, isso sim, uma nova superfície de ataque para proteger.