Security Policy

Last updated: May 8, 2026

ConvRadar is an independent project operated by Ivan Pika (Sole Proprietor, Georgia). This page explains how to report a security issue and what to expect after you do. A machine-readable version is available at /.well-known/security.txt (RFC 9116).

Reporting a vulnerability

Please report suspected security issues by email to with the subject line [security] <short summary>, or use our Contacts page. We accept reports in English and Russian.

If the issue is sensitive, you may PGP-encrypt your message; request the public key in a non-sensitive first email.

Please include, where possible:

A description of the issue and its potential impact.
Steps to reproduce, or a proof-of-concept.
Affected endpoint, MCP tool, or page (URL).
Tenant ID (if you have an account) so we can scope the test data.
Whether you would like to be acknowledged in our changelog.

Response timeline

Stage	Target
Acknowledgement of receipt	within 72 hours
Initial triage and severity assessment	within 7 days
Status update during fix	every 7 days until resolved
Public disclosure (coordinated)	typically within 90 days of report, sooner if mitigations are deployed

Scope

In scope

The web application at convradar.com and the dashboard.
The MCP connector server at mcp.convradar.com and any mcp.*.convradar.com subdomains.
The OAuth flow (authorisation, token exchange, refresh, revocation).
Tenant isolation and Row-Level Security in the Supabase database.
The screenshot/verification pipeline (ScreenshotOne / Browserless integration) when invoked through the Service.

Out of scope (please do not test)

Third-party services we depend on (Supabase, Render, Google APIs, Stripe, Resend, ScreenshotOne, Browserless). Report issues with those products to the respective vendors directly. See our Subprocessors page for the full list.
Denial-of-service against production. Please use a personal sandbox account and rate-limit your testing.
Social engineering of the operator, employees of vendors, or end users.
Findings that depend on physical access, lost devices, or stolen credentials.
Self-XSS or attacks that require an attacker to control the victim's browser.
Issues already publicly known or already filed in the public issue tracker.

Safe harbour

We will not pursue legal action against researchers who:

Make a good-faith effort to avoid privacy violations, data destruction, and service disruption.
Use only their own test accounts (or accounts they have explicit permission to test).
Stop testing and notify us as soon as they discover access to data that is not theirs.
Do not exploit the issue beyond what is needed to demonstrate the vulnerability.
Give us reasonable time to fix the issue before public disclosure.

Recognition

We do not currently run a paid bounty program. We will publicly thank reporters in our changelog with their preferred attribution (or anonymously) once a fix has shipped, if they consent.