Scanning methodology
Transparency about what is checked, how the score is produced, and what the scan cannot tell you.
Passive scanning
Passive modes request pages on the address you provide, read the HTTP responses, and evaluate the configuration that can be observed: security headers, cookie attributes, HTTPS and redirect behaviour, mixed content, caching of sensitive-looking responses, and technology or error details exposed in responses.
Every passive request is a normal read-only page request. No intentional attack-style test requests are sent.
Safe Active scanning
Safe Active is optional, never the default, and requires an explicit authorization confirmation before it starts. It adds bounded, non-destructive checks: HTTP method behaviour where safe, CORS preflight behaviour, safe error-handling checks and harmless parameter reflection checks.
The scanner does not attempt to bypass authentication, steal credentials, exploit systems destructively, or guarantee complete security. Safe Active requests are same-origin by default, rate limited, budget limited and cancellable.
Discovery, API and form inventory
Discovery follows same-domain links and reads robots.txt and sitemap.xml to improve coverage. API-looking paths (/api/, /v1/, /v2/, /graphql) and publicly published API documentation (openapi.json, swagger.json, api-docs) are recorded as an inventory with endpoint, method, content type, authentication indication and discovery source.
Forms are recorded by structure only — URL, method, action, field names, types and autocomplete attributes. Forms are never submitted and no entered values are stored. Discovery never implies that an endpoint is vulnerable.
CORS, headers, cookies and HTTPS analysis
Access-Control-Allow-Origin, Allow-Credentials, Allow-Methods and Allow-Headers are evaluated in context. A wildcard origin is not automatically treated as a vulnerability; confidence and evidence are reported alongside the finding.
Header, cookie and HTTPS analysis reports each item as Detected, Missing, Weak or Needs review, with the context needed to judge it for your own site. /.well-known/security.txt is reported as a recommendation, never as a vulnerability.
Technology detection
Technologies are reported from observable evidence only. Where only the product is visible the report says 'Technology detected'; a version is only reported as 'Version exposed' when the target itself exposes it.
Request limits
Each scan runs under a request budget with conservative rate limiting, page limits, crawl depth limits and per-request timeouts. Budgets are configurable and never unlimited; scan coverage reports how much of the budget was used.
Scoring
Each scan starts at 100 points. Open findings deduct: critical -40, high -20, medium -8, low -2, informational 0. Low-confidence findings deduct half. The score never falls below 0.
The score is an automated assessment of observable configuration. It is not a guarantee of security and does not replace a professional penetration test. Historical scans keep the score and methodology version recorded at the time they ran.
Severity and confidence
Severity reflects potential impact; confidence reflects how certain the detection is. A missing header is not automatically a vulnerability — each finding explains the context so you can judge it for your own site.
Safety and abuse protection
Targets are validated before any request. Local, loopback, private-network, cloud-metadata and internal hostnames are rejected, and hostnames are re-resolved and re-checked before the scanner connects, so the service cannot be used as a proxy into private infrastructure.
Every redirect hop is revalidated independently: a public hostname that redirects to an internal address is stopped and rejected. Crawling is same-domain only, rate limited, depth and page limited, and respects robots.txt disallow rules.
Handling of sensitive data
Cookie values, authorization headers and tokens are never stored or displayed. Anything matching a known secret pattern is masked before it reaches a report or log, for example sk_live_****************.
Current limitations
The scanner analyses a limited number of pages and infers certificate validity from a successful HTTPS connection rather than a full chain inspection. It cannot evaluate authenticated areas, business logic, or issues that are only visible from inside the application.
Results describe what the checks performed could observe. No issues detected means no issues were detected by the checks performed — not that the website is secure.