Service Scans

Service Scans are bounded runtime posture checks Guara Shield runs against the public HTTP endpoints of your services. They look for the most common exposure and misconfiguration issues, including broad CORS, missing browser hardening headers, exposed docs or metrics routes, debug or admin surfaces, verbose public errors, insecure cookies, and framework fingerprint leaks. When something needs your attention, they write actionable Security Findings.

Where Service Scans run

Only services you own with a public endpoint are scanned. That means:

• Public endpoints of your application services.
• Custom domains and the default Guara subdomain alike.

For catalog services like Postgres, Redis, and NATS, see Vulnerabilities. Internal-only services without a public endpoint, anything outside your own account, and third-party endpoints reached by your services are out of scope.

What checks are run

The v1 check set is deliberately narrow and user-actionable:

Check	What it looks for	Severity
Broad CORS	Access-Control-Allow-Origin: * paired with credentials, or other dangerously permissive CORS combinations.	high
Missing clickjacking header	No X-Frame-Options (and no frame-ancestors in CSP) on HTML responses.	medium
Missing MIME-sniffing guard	No X-Content-Type-Options: nosniff on HTML responses.	low on HTML
Framework fingerprint leak	X-Powered-By or similar headers that volunteer your application stack to the public internet.	low
Exposed docs or OpenAPI	Common public documentation routes such as /docs, /api/docs, /swagger, /swagger.json, or /openapi.json.	medium
Exposed metrics	A successful public response on /metrics.	medium
Debug/admin surfaces	Successful public responses on /debug, /admin, /actuator, or /actuator/env.	high
Verbose public errors	Stack trace or framework exception indicators in bounded public HTTP responses.	medium
Insecure cookies	Set-Cookie headers missing expected security attributes. Cookie values are not stored.	medium

Browser-only checks are scoped to HTML responses, so your API-only services aren’t punished for not setting X-Frame-Options on JSON endpoints where it doesn’t apply.

Platform-controlled posture (HSTS, HTTP to HTTPS redirect) is recorded as context, not as a finding. If Guara Cloud is the one in control of a header, we don’t blame you for it.

When scans run

• After every healthy deploy of a public service. As soon as the deploy passes its readiness checks, the scan is queued.
• On a regular cadence for all eligible public services, so newly exposed conditions surface even without a deploy.

Scans run automatically after every healthy deploy and on a regular cadence, so you don’t have to schedule anything yourself. The cadence is intentionally predictable and bounded.

How the scanner behaves

Scans are intentionally polite and bounded:

• Only GET requests today, within the allowed safe method family (GET, HEAD, OPTIONS).
• A fixed safe route set only: /, /robots.txt, /sitemap.xml, /docs, /api/docs, /swagger, /swagger.json, /openapi.json, /metrics, /debug, /health, /admin, /actuator, and /actuator/env.
• No fuzzing, no input mutation, no authentication-bypass attempts.
• No request-body probing.
• Hard timeouts on every request, so scans either complete quickly or back off.
• Manual redirect handling with a small redirect limit, so there are no infinite loops.
• Capped response read size. Shield may classify bounded response content in memory, but never stores raw response bodies.

This means scans behave like a single, careful visitor.

What the scanner stores

• Selected response headers relevant to the checks (e.g., Access-Control-Allow-Origin, X-Frame-Options).
• Context fields like the endpoint host and content type.
• Findings for any actionable issue, with bounded structured evidence.

The scanner does not store:

• Raw response bodies.
• Raw request bodies.
• Cookies, session tokens, or authorization headers.
• Customer payloads of any kind.
• Anything classified as a secret.

If a header value, cookie, URL, or bounded response classification would reveal a secret, it is redacted before storage.

Acting on findings

Every actionable scan result opens a finding with:

• The specific check that flagged.
• The endpoint that was scanned.
• The observed and expected header (where applicable).
• Remediation guidance. For header issues, this includes the exact header value to set.

Triage actions work the same way as every other finding type: acknowledge, resolve, suppress, mark as false positive. See Security Findings.

How to deploy the headers

The fastest fixes for most service scan findings live in your application response layer (middleware, framework config). Common targets:

• X-Frame-Options: DENY (or a CSP frame-ancestors 'none').
• X-Content-Type-Options: nosniff.
• A narrow Access-Control-Allow-Origin instead of * when credentials are involved.
• Drop X-Powered-By (Express, PHP, ASP.NET, etc. all let you turn this off in one line).

Once the next deploy lands, the post-deploy scan re-checks the endpoint and resolves the finding automatically.

Where to go next

• See the chronological scan history: Security Events (look for service_scan_completed).
• Triage findings produced by scans: Security Findings.
• Get a plain-language read on a specific scan finding: Explain This Threat.