Scope and evidence
What SiteGuardrail checks—and what it cannot prove
Learn what SiteGuardrail's passive website security scan checks, how evidence, severity and confidence are assigned, and what the result cannot prove.
- Default mode
- Passive
- Scope
- Public origin
- Credentials
- Never requested
Core principle
Report only what the public response supports.
A SiteGuardrail finding begins with an observable response from a public site. Evidence is tied to an affected URL, described in plain language, and redacted when it resembles a credential or private value.
Honest boundary
Unknown is not the same as safe.
If a check is skipped, blocked, times out, or falls outside the passive scope, SiteGuardrail records incomplete coverage. It does not infer that no issue exists in that area.
Scan lifecycle
From submitted domain to prioritised finding
- 01
Validate the target
Normalise the public HTTPS URL and reject embedded credentials, unusual ports, local, private, reserved, link-local, and cloud metadata destinations.
- 02
Constrain the scope
Keep public beta scans passive and origin-limited. Redirect destinations are revalidated before following them.
- 03
Collect bounded public responses
Use short timeouts, response-size limits, redirect limits, request budgets, and a narrow crawl rather than aggressive enumeration.
- 04
Evaluate evidence
Check transport, browser policy, content, public scripts, exposed paths, cookies, forms, DNS, and other externally visible signals without exposing the private rule inventory.
- 05
Score and explain
Assign severity and confidence, identify the affected target, redact evidence, explain risk, and provide a practical remediation.
- 06
Separate findings from warnings
Findings describe detected signals. Warnings describe missing or incomplete coverage and do not inflate the issue count.
How prioritisation works
Severity estimates impact. Confidence estimates certainty.
Evidence suggests immediate, material compromise or highly sensitive public exposure.
Evidence suggests a serious exposure with meaningful confidentiality, integrity, or access impact.
A weakness or exposure deserves remediation but normally needs context or another issue for larger impact.
Hardening, information exposure, or a lower-impact condition worth reviewing.
High confidence means the public response strongly matches the stated condition. Medium or low confidence means interpretation or manual verification matters more. The numerical score is a prioritisation aid derived from findings; it is not a certification or probability that a site will be compromised.
Not covered by a passive public scan
Important security work still has to happen elsewhere.
Account boundaries, role changes, IDOR, and business logic.
Repository secrets, vulnerable packages, infrastructure as code, and internal services.
Row-level rules, grants, stored procedures, and private data paths.
Injection, XSS exploitation, password testing, fuzzing, and destructive validation.
Unknown subdomains, shadow infrastructure, mobile apps, and non-web services.
A result is a point-in-time observation, not continuous monitoring or certification.
False positives
Context can turn a suspicious signal into intended design.
Public source maps can be deliberate. Public Supabase publishable keys are normal. An admin route can be properly protected. Review evidence, confidence, and application context before changing production.
False negatives
Unobserved behavior can still be vulnerable.
Runtime-loaded assets, authentication, blocked requests, unusual secret formats, nonstandard paths, private APIs, and application logic may sit outside completed coverage.