Nesta página

Última atualização: 23 de maio de 2026

Verificações de Serviço

As Verificações de Serviço são checagens limitadas de postura em runtime que o Guara Shield executa contra os endpoints HTTP públicos dos seus serviços. Elas procuram os problemas mais comuns de exposição e má-configuração, incluindo CORS aberto, ausência de cabeçalhos de hardening de navegador, rotas públicas de docs ou métricas, superfícies de debug ou admin, erros públicos verbosos, cookies inseguros e vazamento de fingerprint de framework. Quando algo precisa da sua atenção, elas escrevem Achados de Segurança acionáveis.

Onde as Verificações de Serviço rodam

Apenas seus serviços com endpoint público são verificados. Isso significa:

  • Endpoints públicos dos seus serviços de aplicação.
  • Domínios customizados e o subdomínio padrão do Guara, igualmente.

Para serviços de catálogo como Postgres, Redis e NATS, veja Vulnerabilidades. Serviços internos sem endpoint público, qualquer coisa fora da sua conta e endpoints de terceiros acessados pelos seus serviços ficam fora de escopo.

Quais checagens são executadas

O conjunto v1 de checagens é deliberadamente estreito e acionável pelo usuário:

ChecagemO que procuraSeveridade
CORS abertoAccess-Control-Allow-Origin: * combinado com credenciais, ou outras combinações de CORS perigosamente permissivas.alta
Ausência de proteção contra clickjackingSem X-Frame-Options (e sem frame-ancestors no CSP) em respostas HTML.média
Ausência de proteção contra MIME sniffingSem X-Content-Type-Options: nosniff em respostas HTML.baixa em HTML
Vazamento de fingerprint de frameworkX-Powered-By ou cabeçalhos similares que entregam sua stack de aplicação à internet pública.baixa
Docs ou OpenAPI expostosRotas públicas comuns de documentação como /docs, /api/docs, /swagger, /swagger.json ou /openapi.json.média
Métricas expostasResposta pública bem-sucedida em /metrics.média
Superfícies de debug/adminRespostas públicas bem-sucedidas em /debug, /admin, /actuator ou /actuator/env.alta
Erros públicos verbososIndicadores de stack trace ou exceção de framework em respostas HTTP públicas limitadas.média
Cookies insegurosCabeçalhos Set-Cookie sem atributos de segurança esperados. Valores de cookie não são armazenados.média

Checagens específicas de navegador são restritas a respostas HTML, então seus serviços apenas-API não são punidos por não definir X-Frame-Options em endpoints JSON onde isso não se aplica.

Postura controlada pela plataforma (HSTS, redirect HTTP para HTTPS) é registrada como contexto, não como achado. Se a Guara Cloud é quem controla um cabeçalho, não te culpamos por isso.

Quando as verificações rodam

  • Após todo deploy saudável de um serviço público. Assim que o deploy passa nos checks de readiness, a verificação é enfileirada.
  • Em cadência regular para todos os serviços públicos elegíveis, então condições recém-expostas aparecem mesmo sem deploy.

As verificações rodam automaticamente após todo deploy saudável e em cadência regular, então você não precisa agendar nada. A cadência é intencionalmente previsível e limitada.

Como o scanner se comporta

As verificações são intencionalmente educadas e limitadas:

  • Apenas requisições GET hoje, dentro da família de métodos seguros permitidos (GET, HEAD, OPTIONS).
  • Um conjunto fixo de rotas seguras: /, /robots.txt, /sitemap.xml, /docs, /api/docs, /swagger, /swagger.json, /openapi.json, /metrics, /debug, /health, /admin, /actuator e /actuator/env.
  • Sem fuzzing, sem mutação de input, sem tentativas de bypass de autenticação.
  • Sem sondagem de body de requisição.
  • Timeouts rígidos em cada requisição, então verificações ou terminam rápido ou recuam.
  • Tratamento manual de redirects com limite pequeno, sem loops infinitos.
  • Tamanho de leitura de resposta limitado. O Shield pode classificar conteúdo limitado em memória, mas nunca armazena bodies brutos de resposta.

Isso significa que verificações se comportam como um único visitante cuidadoso.

O que o scanner armazena

  • Cabeçalhos de resposta selecionados relevantes para as checagens (ex.: Access-Control-Allow-Origin, X-Frame-Options).
  • Campos de contexto como host do endpoint e content-type.
  • Achados para qualquer problema acionável, com evidência estruturada e limitada.

O scanner não armazena:

  • Bodies brutos de resposta.
  • Bodies brutos de requisição.
  • Cookies, tokens de sessão ou cabeçalhos de autorização.
  • Payloads do cliente de qualquer tipo.
  • Qualquer coisa classificada como segredo.

Se um cabeçalho, cookie, URL ou classificação limitada de resposta revelaria um segredo, ele é redigido antes do armazenamento.

Agindo em achados

Cada resultado acionável abre um achado com:

  • A checagem específica que disparou.
  • O endpoint que foi verificado.
  • O cabeçalho observado e o esperado (quando aplicável).
  • Orientação de remediação. Para problemas de cabeçalho, isso inclui o valor exato a definir.

As ações de triagem funcionam igual a qualquer outro tipo de achado: reconhecer, resolver, suprimir, marcar como falso positivo. Veja Achados de Segurança.

Como deployar os cabeçalhos

As correções mais rápidas para a maioria dos achados de verificação de serviço vivem na camada de resposta da sua aplicação (middleware, configuração do framework). Alvos comuns:

  • X-Frame-Options: DENY (ou um CSP frame-ancestors 'none').
  • X-Content-Type-Options: nosniff.
  • Um Access-Control-Allow-Origin estreito em vez de * quando credenciais estão envolvidas.
  • Remover X-Powered-By (Express, PHP, ASP.NET, etc. todos permitem desligar isso em uma linha).

Assim que o próximo deploy passar, a verificação pós-deploy revisita o endpoint e resolve o achado automaticamente.

Para onde ir agora