Show the evidence
Every result links a conclusion to provider responses, records, redirects, certificate details, page indicators, and timestamps. The report exposes what could not be checked.
About Securvex
Built to make
uncertainty legible.
Most safety tools answer a hard question with a reassuring badge. Securvex instead shows what was checked, what was found, what failed, and what the result cannot prove.
Why this exists
A verdict should show its work.
Website safety is rarely a binary question. A domain can be newly registered but legitimate. A page can use a valid certificate and still impersonate a bank. A threat feed can return no match because the site is safe, because it has never been seen, or because the lookup failed.
Securvex was designed around that reality. It collects evidence from several independent layers, marks unavailable data honestly, and produces an estimated risk rating with stated limitations. The most important sentence in the product is simple: no threat detected is not the same as guaranteed safe.
The application is self-hostable and provider-neutral. Operators can run it with no external reputation keys, enable one or more threat-intelligence services, and add an optional AI explanation. Every one of those states is visible in the scan report.
Product principles
Transparency is a security property.
These principles shape the scan engine, the report design, and the documentation. They also define what the product refuses to claim.
Keep the score deterministic
Rules own the verdict. AI can make the explanation easier to read, but it cannot silently change the score or override confirmed intelligence.
Never equate silence with safety
A missing provider, failed DNS lookup, or unparsed page reduces confidence. It does not become a clean signal or a reason to lower the score.
Label uncertainty precisely
The product distinguishes confirmed threat intelligence, strong and weak indicators, not configured, unavailable, failed, and insufficient data.
Minimize and protect data
Reports use unguessable links, sensitive query values are redacted before storage, and retention is finite. External lookups are disclosed before the scan.
Prefer inspectable systems
The scanner uses ordinary HTTP, public registries, documented provider APIs, and rule-based scoring. Its behaviour is meant to be reviewed and self-hosted.
Architecture
Small, inspectable components.
The scanner is a Next.js application with a server-side scan pipeline, Prisma-backed report storage, and a server-rendered evidence dashboard. Reports can be downloaded as JSON and copied as plain text.
- Node.js runtime for network checks; no browser automation.
- Provider adapters with explicit configuration and failure states.
- Deterministic risk module with unit tests and transparent group scores.
- SQLite by default for portable self-hosting; PostgreSQL path documented.
Independence
Data sources, not endorsements.
Securvex is not affiliated with Google, VirusTotal, abuse.ch, Phishunt, any registrar, or any brand referenced by the impersonation checks. Third-party names identify data sources and protection patterns only.
Threat-intelligence terms and API limits still apply to the deployment operator. Google Safe Browsing and the VirusTotal public API, for example, have non-commercial-use conditions. The default Phishunt feed is a public CC0 community feed; its matches can be stale or wrong. Those constraints are documented alongside the integrations.
A scan is decision support, not professional security, legal, or financial advice. Verify high-stakes websites independently.
What we will not do
No fake certainty, no invented checks.
The scanner does not fabricate provider responses, simulate a browser, claim to have inspected content behind a login, or label an unqueried source as clean. When the deployment lacks an API key, the report says the provider was not configured. When a timeout occurs, the report marks the lookup unavailable.
AI is optional and deliberately constrained. It must first return a structured evidence audit that cites real evidence IDs and agrees with the deterministic verdict. The explanation is then checked for unsupported numbers, domains, provider statuses, safety claims, unsafe advice, and instruction-injection content. A rejected response is replaced by the deterministic explanation. AI can still make mistakes, so the rule-based report remains authoritative.