Terms of Service

Last updated

Webcuris (“the application”) is security scanning and monitoring software, offered as a single-operator hosted service. Whoever operates a deployment of it is the operator, and these terms govern use of that deployment.

Draft. Written to accurately describe this application's actual behavior, but not reviewed by qualified legal counsel — treat it as technical documentation rather than a finished legal document.
On this page

What the application does

The application performs passive security checks against websites you submit — HTTP security headers, Content-Security-Policy analysis, TLS and certificate configuration, DNS hygiene records, cookie attributes, mixed-content detection, and subdomain discovery via Certificate Transparency logs.

Separately, it scans source repositories you point it at — a local path on the server, or a repository on GitHub, GitLab, Bitbucket or Azure DevOps, public or private — for known-vulnerable dependencies across multiple ecosystems, likely hard-coded secrets in both the working tree and the commit history, Dockerfile and Kubernetes misconfigurations, pattern-based code risk including authentication and authorization patterns, and patterns in LLM/AI SDK usage. Private repositories require a read-only credential you supply; secret values are only shown for repositories whose control you have proven.

It does not perform SQL or command injection testing, denial-of-service or resource-exhaustion testing, deserialization or request-smuggling attacks, race-condition testing, credential stuffing or brute-force testing, or any attempt to exploit a finding. Those are refused by design, not merely unimplemented: a payload that proves such a vulnerability is a payload that runs on your systems.

On assets whose ownership you have proven, it does send a small, fixed number of crafted read-only requests: a redirect parameter pointing off-site, an inert marker containing HTML metacharacters, a path-traversal path, a template expression that evaluates arithmetic, and a static-looking suffix on a real path. Each is a GET, none writes or changes state, and the whole set is bounded so a scan cannot become a load test. On assets you have not verified, only passive checks run — the equivalent of a normal browser visit. The one tool that sends authenticated requests — the owner-only differential-access probe — acts only on a target and credentials an operator supplies explicitly.

Accounts and visibility

The first account, created during setup, is the owner. After that, anyone who can reach a deployment can create their own account via self-service signup.

Each account sees only the assets it created and the scans it personally triggered; requesting another account's scan returns a 404. The owner account is exempt from this filtering and can see and manage every asset and scan in the deployment. Organizations add an optional shared scanning scope on top of this. The exact boundaries — including what is not isolated — are documented in the Security Policy.

Your responsibility to have authorization

You are responsible for having the legal right to scan any website, domain, or repository you submit. Passive checks only send standard, publicly-observable HTTP/TLS/DNS requests equivalent to a normal browser visit, but you must not use this tool against systems you are not authorized to test, and you must not use it to violate any applicable law or any third party's terms of service. The Acceptable Use Policy sets out the specifics.

No warranty; accuracy of findings

Findings are generated by automated heuristics and by querying third-party vulnerability databases (see the Privacy Policy). They may contain false positives and false negatives, and are provided “as is” without warranty of completeness or accuracy.

A clean scan is not a certification of security and must not be represented as one. Severity ratings, confidence levels, and scores are estimates, not guarantees. Compliance mappings are best-effort situational context, not audited compliance claims.

Repository scanning risk

In local-path mode, the repository scanner reads files from any filesystem path you provide, with the permissions of the server process. Only point it at paths you control, and prefer setting the CODE_SCAN_ALLOWED_ROOTS restriction on any deployment with more than one trusted account. Hosted mode clones the repository — with your read-only credential if it is private — into a temporary directory that is deleted when the scan finishes, whether it succeeded or failed. The credential is passed to git through an ephemeral helper rather than embedded in the clone URL, so it does not appear in the process list or in the cloned repository's own config.

Changes

This document may change as the application's functionality changes. Continued use after a change constitutes acceptance of the updated terms.

Contact

Talk to us.

Questions about what the engine checks, whether it fits your estate, or what it deliberately refuses to do. A person reads every message.

  1. 01You writePlain form, no qualifying call, no obligation. The marketing checkbox is optional and unticked.
  2. 02A person reads itMessages land with the team, not a queue-bot. Nothing is auto-replied.
  3. 03You get an answerTo the address you gave — including “this product is not the right fit”, when that is the honest answer.
Prefer email?
Use the form — no address is published on this deployment.
Reporting a vulnerability?
Read the disclosure policy first — it tells you what is in scope and what to expect.
New messagereplies go to your email

Personal addresses (gmail, outlook, and similar) are not accepted.

+91

0 / 4000