Security

Vulnerability Disclosure Policy

Voretix exists to make the web safer, and that starts with our own platform. If you have found a security vulnerability in Voretix, we want to hear about it — this page explains how to report it, what is in scope, and what you can expect from us in return.

Last updated: July 7, 2026 Machine-readable: /.well-known/security.txt

1. How to Report

Email [email protected] with "Security report" in the subject line. A machine-readable pointer to this policy is published at /.well-known/security.txt (RFC 9116).

A good report lets us reproduce the issue without guessing. Please include:

  • the affected URL or API endpoint and the type of vulnerability;
  • step-by-step reproduction instructions — requests, payloads, screenshots or a proof-of-concept where relevant;
  • your assessment of the impact: what an attacker could actually do with it;
  • any accounts, scan IDs or timestamps involved, so we can trace it in our logs.

Please report in private — not in public scan comments, social media or an issue tracker — and do not include other users' personal data in your report beyond the minimum needed to demonstrate the issue. Reports in English are preferred.

2. Scope

In scope:

  • voretix.com — the website, including authentication, scan submission, reports, search, hunt, profile and API-key management;
  • api.voretix.com — the public REST API;
  • the scanning pipeline itself — for example sandbox escapes, server-side request forgery through the scanner, or ways to make a scan report attack the analyst viewing it.

Out of scope:

  • Websites that appear in scan reports. We analyze those pages; we do not own or operate them. A malicious site in the corpus is content, not a vulnerability — and you can flag it by scanning it;
  • Third-party services we build on — vulnerabilities in Amazon Cognito, Cloudflare, Google Fonts or jsDelivr themselves belong with those vendors (their scope, their disclosure programs);
  • Social engineering of Voretix staff or users, and anything requiring physical access;
  • Denial of service and other findings whose demonstration degrades the Service (see the rules below).

3. Rules of Engagement

Security research is welcome within these limits:

  • Use your own accounts and your own scans. Do not access, modify or delete other users' data. If a vulnerability exposes someone else's data, stop at the minimum proof needed and report immediately — do not download, keep or share it;
  • Do not degrade the Service. No volumetric or denial-of-service testing, and no high-rate automated fuzzing that affects other users. Testing whether a rate limit can be bypassed is fine; hammering the platform through the bypass is not;
  • Do not pivot. If you gain unintended access to infrastructure, demonstrate the entry point and stop — do not explore further, install persistence or move laterally;
  • Do not use findings for anything but the report. No extortion, no selling access, no public disclosure before the coordination window below.

4. What to Expect From Us

  • We aim to acknowledge your report within 5 business days;
  • we will investigate, keep you informed of our progress, and tell you when the issue is fixed — or explain why we assess it differently;
  • severe, exploitable issues are prioritised ahead of everything else we are building;
  • with your permission, we are happy to credit you when the fix ships. Voretix does not currently run a paid bug-bounty program, so please do not condition a report on payment.

5. Coordinated Disclosure

We ask that you give us 90 days from your report (or until a fix ships, whichever comes first) before disclosing the issue publicly. If we need longer for an unusually deep fix, we will tell you why and agree on a new date together. Once the issue is resolved you are free to publish your research — we would genuinely like to read it.

6. Safe Harbor

We consider security research conducted in line with this policy to be authorized, conducted in good faith, and exempt from restrictions in our Terms of Service that would otherwise forbid it. We will not initiate legal action or refer you to law enforcement for good-faith research that respects the rules above, and if a third party takes action against you for such research, we will make it known that your activity was conducted under this policy.

This safe harbor cannot extend to systems we do not own: it does not authorize testing of third-party services, or of the websites that appear in scan reports. If you are unsure whether something is covered, ask first — we answer scope questions too.

7. Findings We Usually Close Without Action

These are reported often but rarely represent exploitable risk on this platform. Please only submit them with a working demonstration of real impact:

  • missing security headers, cookie flags or DNS records (SPF/DKIM/DMARC) without a demonstrated exploit;
  • clickjacking on pages with no sensitive state-changing actions;
  • self-XSS, logout CSRF, and issues requiring an already-compromised browser or device;
  • software version disclosure and stack fingerprinting — much of it is public by design;
  • output of automated scanners with no analysis or proof of concept attached.

And a reminder: a scan verdict you disagree with is not a security vulnerability — use the report option on the scan result page, as described on the Contact & Support page.