Fechamos o bloco de APIs com uma tecnologia que mudou como APIs são construídas — o GraphQL — e com um problema transversal das APIs: a exposição excessiva de dados. Ambos ilustram como escolhas de design que priorizam flexibilidade e velocidade de desenvolvimento podem, sem os devidos cuidados, ampliar a superfície de ataque. Esta aula completa sua compreensão de segurança de APIs. Pratique com implementações GraphQL vulneráveis (como o DVGA).

O cliente pede o que quer, e a introspection

Comece pelo GraphQL. Diferente das APIs REST tradicionais (onde cada endpoint retorna uma estrutura fixa de dados), o GraphQL permite que o cliente especifique exatamente quais dados quer, numa única requisição flexível, consultando um "grafo" de dados interconectados. É poderoso para desenvolvedores — reduz o número de requisições, evita buscar dados demais ou de menos. Mas essa flexibilidade tem implicações de segurança próprias. A primeira é a introspection (introspecção): o GraphQL tem um recurso que permite consultar o próprio esquema da API — descobrir todos os tipos, campos e operações disponíveis. É útil para desenvolvimento, mas se deixado habilitado em produção, entrega ao atacante um mapa completo da API — toda a "superfície invisível" (aula OWASP API Security Top 10: BOLA, autenticação e a superfície invisível) revelada de bandeja. Desabilitar a introspection em produção é uma das primeiras recomendações de segurança GraphQL.

Consultas pesadas e negação de serviço

As demais preocupações de segurança do GraphQL derivam de sua flexibilidade. Como o cliente pode construir consultas complexas e aninhadas, um atacante pode criar consultas maliciosamente pesadas — profundamente aninhadas ou que solicitam enormes quantidades de dados — causando negação de serviço (a "denial of service por complexidade de consulta"). Como o GraphQL frequentemente tem um único endpoint para tudo, as verificações de autorização precisam ser feitas no nível dos campos e resolvers (não por endpoint), o que reintroduz o problema de autorização em escala de forma ainda mais granular — cada campo do grafo pode precisar de sua própria verificação. E os erros verbosos do GraphQL às vezes vazam informação sobre o esquema e a implementação. O GraphQL não é inseguro por natureza, mas sua flexibilidade exige controles de segurança específicos que, se esquecidos, ampliam a exposição.

Exposição excessiva de dados

Agora o problema transversal: a exposição excessiva de dados (excessive data exposure). É um padrão comum em APIs, especialmente as que retornam objetos completos. Imagine uma API que retorna o perfil de um usuário: internamente, o objeto "usuário" pode conter muitos campos — nome, e-mail (ok), mas também hash de senha, token interno, papel, flags administrativas, dados de outros usuários relacionados. Se a API retorna o objeto inteiro e confia que o cliente (o app) só exibirá os campos apropriados, ela cometeu um erro grave: o atacante que chama a API diretamente (ignorando o app) vê todos os campos, incluindo os sensíveis. É a manifestação, em APIs, do princípio da aula Arquitetura web e HTTP: entendendo o terreno — nada que roda no cliente é confiável, incluindo a filtragem de exibição. A API não deve confiar que o cliente ocultará dados; ela deve não enviar os dados que o usuário não deveria ver.

Confiar no cliente e priorizar a conveniência

O ponto conceitual que amarra o bloco de APIs: as vulnerabilidades de API frequentemente nascem de confiar no cliente e priorizar a conveniência do desenvolvedor sobre a segurança. O GraphQL prioriza a flexibilidade do cliente (que pode pedir o que quiser) — e sem controles, isso vira introspection exposta e consultas abusivas. A exposição excessiva de dados prioriza a simplicidade do desenvolvimento (retornar o objeto inteiro e deixar o cliente filtrar) — e vira vazamento. O BOLA nasce de esquecer verificações de autorização granulares no afã de construir endpoints rapidamente. O tema recorrente: APIs são construídas por desenvolvedores focados em funcionalidade, e a segurança exige uma disciplina adicional de não confiar no cliente e verificar autorização granularmente que é fácil de negligenciar sob pressão de prazo. Isso conecta com o "secure by design" (aula OWASP Top 10: o mapa das vulnerabilidades web) — a segurança de API precisa ser pensada na arquitetura, não remendada.

Desligar introspection e retornar só o necessário

Do lado defensivo, as contramedidas específicas: para GraphQL, desabilitar a introspection em produção, limitar a profundidade e complexidade das consultas (contra DoS), implementar autorização no nível de campo/resolver, e não vazar informação em erros; contra exposição excessiva de dados, o princípio-chave é retornar apenas os dados que o usuário deve ver — definir explicitamente quais campos cada resposta inclui (um "schema" de saída, allowlist de campos), nunca retornar objetos internos completos, e jamais confiar que o cliente filtrará. Transversalmente, todas as lições do bloco de APIs: autorização rigorosa e granular, autenticação robusta, rate limiting, inventário de endpoints, e a mentalidade fundamental de tratar o cliente como hostil.

Fecha o Bloco XIII

Com esta aula, encerramos o Bloco XIII — API Security. Você entende agora por que APIs são uma superfície distinta, os riscos dominantes (BOLA/IDOR, exposição de dados, autorização em escala), e as tecnologias modernas (GraphQL) com seus desafios próprios. Somado ao Bloco XII, você domina a segurança de aplicações web e APIs — o maior e mais demandado campo do pentest, onde a maioria dos bug bounties e testes acontece. Daqui em diante o território é o mundo físico e das ondas: o Bloco XIV — Redes, Wireless e Engenharia Social, começando pelo sniffing de tráfego.

Fontes e leituras recomendadas

  • OWASP — API Security Top 10 e GraphQL Cheat Sheet
  • DVGA (Damn Vulnerable GraphQL Application) — para praticar
  • Documentação de segurança do GraphQL (graphql.org e recursos de segurança)
  • PortSwigger — labs e materiais sobre GraphQL API testing

Exercícios

  1. Como o GraphQL difere de uma API REST tradicional, e qual a vantagem para o desenvolvedor?

    ✓ Resposta:

    No REST, cada endpoint retorna uma estrutura fixa de dados; no GraphQL, o cliente especifica exatamente quais dados quer, numa única requisição flexível sobre um grafo de dados interconectados. A vantagem é reduzir requisições e evitar buscar dados demais ou de menos, dando flexibilidade ao cliente.

  2. O que é a introspection do GraphQL, e por que deixá-la habilitada em produção é um risco?

    ✓ Resposta:

    A introspection permite consultar o próprio esquema da API, revelando todos os tipos, campos e operações. Em produção, é um risco porque entrega ao atacante um mapa completo da API — toda a superfície de ataque, incluindo endpoints e operações que de outra forma seriam invisíveis.

  3. Explique a "exposição excessiva de dados" e por que confiar que o cliente filtrará os campos é um erro grave.

    ✓ Resposta:

    É a API retornar objetos completos (com campos sensíveis como hash de senha, papel, flags internas) confiando que o cliente exibirá só os apropriados. É grave porque o atacante que chama a API diretamente vê todos os campos — nada que roda no cliente é confiável, incluindo a filtragem de exibição; a API deve não enviar o que o usuário não deve ver.

  4. Como as consultas flexíveis do GraphQL podem levar a negação de serviço?

    ✓ Resposta:

    Como o cliente pode construir consultas complexas, profundamente aninhadas ou que solicitam enormes volumes de dados, um atacante pode criar consultas maliciosamente pesadas que consomem recursos excessivos do servidor, causando negação de serviço por complexidade de consulta.

  5. Qual o tema conceitual que une as vulnerabilidades de API (BOLA, exposição de dados, riscos de GraphQL), e como ele se conecta ao "secure by design"?

    ✓ Resposta:

    O tema é confiar no cliente e priorizar a conveniência do desenvolvedor sobre a segurança — BOLA (esquecer autorização granular), exposição de dados (deixar o cliente filtrar), GraphQL (flexibilidade sem controles). Conecta-se ao "secure by design" porque a segurança de API precisa ser pensada na arquitetura (não confiar no cliente, verificar autorização em cada ponto), e não remendada depois sob pressão de prazo.