Trust

Terms of service

The rules for using Torvane. In short: only scan sites you own or have written permission to test, and you are responsible for the scans you start. Enterprise testing of logged-in areas happens only under a signed scope agreement.

1. Authorization

You may only scan a site you own, or one whose owner has given you explicit written permission to run automated security tests. Before the first scan of a site you confirm this for that site; we record the confirmation with its time, your IP address and browser. You are responsible for having the legal authority to authorize the testing under the laws that apply to you and to the site.

2. What a scan does

Standard scans (Free, Pro and Ultra plans). A standard scan sends a limited number of read-only requests (GET, HEAD and OPTIONS) to the one host you added (and, only if you allow it, the Supabase or Firebase project it uses). It looks for exposed files, leaked keys, weak headers, TLS and cookie settings, CORS mistakes and known-vulnerable libraries. A standard scan never logs in, submits forms, sends attack payloads or tries passwords, and it never contacts private or internal network addresses. Requests are rate-limited and capped per scan, per account and per site. These limits apply in the same way to scheduled scans, which you can turn on for a site whose ownership you have proven, and which stop if that proof is removed: a daily schedule runs a quick check of headers, cookies, TLS, exposed files and scripts, with a full scan once a week, at night in your time zone unless your plan lets you choose the hour. "Unlimited" scans on paid plans are subject to fair use: every scan keeps its request cap and rate limit, and the daily caps per account and per site still apply. We record every request a scan sends. Every plan shows a summary of them with each report; Pro and Ultra also show each request and the scan log.

Enterprise engagements. Testing of logged-in areas, manual review and any other work beyond a standard scan is available only on the Enterprise plan, and only under a signed scope agreement (see section 7). Enterprise engagements are the only exception to the limits above, and only to the extent the scope agreement says so.

3. Prohibited use

  • Scanning a site without the authorization described in section 1.
  • Using results to attack, extort or harm anyone.
  • Working around the limits, for example with several accounts.
  • Giving us test credentials or systems you are not authorized to test.

4. Responsibility

You are responsible for the scans you start and agree to cover claims that arise from scans you started without authorization. Results are automated and may be incomplete or wrong; they are not a guarantee that a site is secure.

5. Data

We keep the status code, size and a masked excerpt of what a check found, never full responses. Secrets are masked to their first characters. The details are on Security and your data.

6. Reporting abuse

If our scanner contacted your site without your permission, tell us. Our requests carry a User-Agent that contains Torvane and link to our abuse page, and each one includes a scan reference (scan= followed by letters and digits) so you can match it to your logs. We investigate every report, can see which account started the scan, and suspend accounts that scan without authorization.

Report an unwanted scan, or email abuse@torvane.app with the host, the time of the requests and, if you can, a log line.

7. Enterprise engagements and authenticated testing

7.1 Written scope agreement required. We do not run authenticated testing or manual review until you have signed a scope agreement with us. The agreement lists the hosts and applications in scope, the test accounts to be used, the testing window, the request limits, the actions that are allowed and not allowed, and a contact person on your side who can tell us to stop.

7.2 Your authority. You confirm that you own every system in scope or have the owner's written permission for this testing, and that you have the legal authority to authorize it under the laws that apply to you and to those systems. If a system is hosted or operated by a third party (for example a cloud provider or SaaS vendor), you are responsible for any permission that party requires.

7.3 Test accounts only. Authenticated testing uses dedicated test accounts that you create and give us for this purpose. We do not guess, brute-force or reset passwords, and we do not use accounts that belong to real users. You should not give test accounts access to real customer data.

7.4 What we will not do. Unless the scope agreement explicitly allows it, we will not:

  • delete, overwrite or modify production data beyond what a test account created during the engagement;
  • complete payments or purchases, or send emails, messages or notifications to real people;
  • run denial-of-service, load or stress tests;
  • try to access other users' accounts or data, other than limited access checks on test accounts you set up for that purpose;
  • test systems outside the agreed scope, or move from one system to another.

7.5 Credentials and evidence. We store the credentials you give us encrypted, use them only for the engagement, and delete them within 30 days after it ends, or earlier on your request. As with standard scans, we keep evidence in masked form and do not store full responses unless the scope agreement says otherwise.

7.6 Stopping and findings. You or we may stop testing at any time. If we find a serious issue that could expose user data, we tell your named contact promptly through the channel set out in the scope agreement, before the final report, and we do not publish or share findings with anyone else.

7.7 Manual review. Manual review is done by our security specialists, who are bound by confidentiality. Findings from manual review are included in your report together with automated findings.

7.8 Records. We log every request made during an engagement and every action on your account, and you can see these logs.

7.9 Responsibility. Section 4 applies to Enterprise engagements. Reports are based on the scope and time available and are not a guarantee that a system is secure.