SiteThreat performs focused, non-destructive checks against publicly reachable website endpoints, evaluates the evidence returned by the target server, calculates a Site Threat Score, and provides practical remediation guidance for findings that may require attention.
Provide a domain that you own, administer, or have explicit permission to assess. SiteThreat normalizes the domain, verifies that it resolves publicly, and rejects targets that do not meet the scanner’s validation requirements. The authorization confirmation is important because even limited external scanning should be performed only with the system owner’s knowledge and permission.
Choose whether to test the root domain, the www hostname, the mail hostname, or all three. These hostnames may point to different servers, applications, document roots, reverse proxies, or hosting configurations. A file blocked on one hostname may still be exposed on another, so broader host coverage can reveal inconsistent protections.
Run exposure-file checks, security-header checks, or both. Exposure checks request a controlled list of commonly mishandled paths such as environment files, backups, logs, dependency manifests, repository metadata, database exports, and server-information pages. Header checks review browser-facing protections without attempting to exploit the site.
For each request, SiteThreat reviews the HTTP status, final destination, response headers, content type, request time, and a limited response sample. The scanner does not crawl the entire website, brute-force directories, submit credentials, bypass authentication, alter content, upload files, or execute discovered code. Its purpose is targeted external exposure detection, not intrusive penetration testing.
Results are classified as safe, warning, medium, high, critical, or unknown based on the response evidence. A blocked path is treated differently from a path that returns a downloadable archive, credential pattern, application log, or production environment file. Ambiguous responses remain warnings or unknown results rather than being presented as confirmed vulnerabilities.
Open “How to fix” for a plain-language explanation, priority, recommended action, and configuration guidance when available. After correcting the server or application configuration, run the scan again. A sensitive resource that is properly protected should normally return a blocked or unavailable response such as 401, 403, 404, or 410.
SiteThreat concentrates on a defined set of externally observable conditions that frequently create avoidable website risk. The scanner is intentionally narrow so that its output remains understandable, repeatable, and suitable for remediation.
Environment files can contain database passwords, mail credentials, API keys, application secrets, encryption material, and third-party service tokens. SiteThreat checks several common environment-file names and looks for evidence that a real configuration file, rather than an ordinary error page, was returned.
Git metadata and dependency manifests may reveal source-control details, framework choices, package names, versions, internal paths, or recoverable source history. These files do not always contain credentials, but their exposure can provide useful reconnaissance to an attacker and should generally be blocked from the public document root.
Application logs may expose stack traces, user data, tokens, SQL errors, internal paths, or operational details. Public archives and database exports can be substantially more serious because they may disclose complete source code, credentials, customer information, and production data.
Diagnostic pages such as PHP information files and server-status endpoints can reveal software versions, enabled modules, filesystem locations, environment settings, request activity, and infrastructure details. SiteThreat flags these endpoints when they appear publicly accessible.
The scanner checks for several commonly recommended response headers, including transport, content-type, framing, referrer, and content-security controls. Missing headers do not automatically mean that a site is compromised, but they may reduce browser-level protection and indicate an opportunity for defensive hardening.
Many applications route unknown paths to a branded page that still returns HTTP 200. SiteThreat distinguishes obvious sensitive content from application pages, redirects, timeouts, and unclear responses. When the evidence is insufficient, the result is marked for manual verification rather than overstated.
The Site Threat Score measures the level of threat indicated by the checks completed during the scan. It is not a security grade. A score of 0 represents no or minimal detected threat within the scanner’s limited scope, while a score of 100 represents critical detected threat.
Each warning, medium, high, critical, or unknown result contributes to the score according to severity. Confirmed critical findings carry substantially more weight than informational warnings. The presence of a high or critical result can also establish a minimum threat range so that a serious exposure is not diluted by a large number of safe checks.
The visual ring is intentionally inverse to the threat number. A very low threat score displays an almost complete green ring. As the detected threat rises, the ring becomes less complete and transitions through yellow, orange, and red. The number therefore answers, “How high is the detected threat?” while the remaining ring visually represents the amount of low-threat condition retained.
Minimal Threat: No meaningful exposure was detected by the completed checks, although routine hardening and periodic retesting remain appropriate.
Low Threat: Limited warnings or lower-impact findings were detected. Review is recommended, but no major exposure was confirmed.
Moderate Threat: One or more findings require corrective attention and may expose technical information or reduce defensive protection.
High Threat: Sensitive operational, application, server, source, or log information may be publicly accessible and should be corrected promptly.
Critical Threat: Credentials, environment data, private keys, databases, or complete backups may be exposed. Immediate containment, removal, and credential rotation may be necessary.
The requested resource was blocked, unavailable, or returned a response that did not indicate direct exposure. No action is required for that specific check, although the result does not validate the entire website.
The response was unusual, redirected, returned a normal application page, or otherwise requires manual verification. A warning is not automatically a confirmed vulnerability.
Technical information is exposed, a dependency manifest is public, or a browser-facing defensive control is missing. Remediation is recommended as part of normal security hardening.
Sensitive operational, source, log, diagnostic, or server information appears publicly accessible. The finding should be reviewed and corrected promptly.
Credentials, environment files, private keys, database exports, complete backups, or similarly consequential information may be publicly exposed. Immediate action may be required.
The scanner could not reach a defensible conclusion because of DNS failure, TLS problems, timeout, connection refusal, rate limiting, intermediary blocking, or another technical error. Manual review is necessary.
A SiteThreat scan is one source of external evidence. It is not a substitute for a complete security program, authenticated assessment, code review, vulnerability-management process, compliance audit, or professional penetration test.
A low score means the completed checks found little or no evidence of the specific exposures tested. It does not prove that the application is secure, malware-free, properly patched, compliant with any law or standard, or free of vulnerabilities outside the scanner’s defined paths and headers.
Custom routing, security gateways, content-delivery networks, login pages, branded 404 pages, and unusual server behavior can produce ambiguous responses. Review the final URL, status, content type, reason, and sample before treating a warning as a confirmed exposure.
A sensitive file may exist under an untested name, require a different hostname, be exposed only intermittently, or be hidden behind application behavior that the scanner does not exercise. SiteThreat intentionally avoids aggressive discovery and exploitation techniques.
Review the evidence and open the final URL in a private browser session when it is safe and authorized to do so. Confirm whether the response contains real sensitive information or only an application-generated page.
For a genuine exposure, block public access, move the resource outside the document root, remove unnecessary diagnostic files, or correct the relevant web-server and application configuration.
If credentials, keys, tokens, database passwords, or other secrets were exposed, assume they may have been copied. Replace them, invalidate old values, and review access logs for suspicious retrieval.
Check adjacent files, backups, alternate hostnames, deployment pipelines, repository history, and server configuration for the same underlying mistake. A single exposed path may indicate a broader deployment issue.
Run SiteThreat again after remediation. Confirm that the affected resource now returns an appropriate blocked or unavailable status and that the Site Threat Score decreases accordingly.
Use SiteThreat only for domains and systems you own, administer, or have explicit authorization to assess. Keep scan reports within the team responsible for remediation, especially when results contain sensitive URLs, response samples, or infrastructure details.