Security

This page describes how the platform is defended and how to report a flaw. It is a summary of the controls we hold ourselves to, not a certification.

Transport

HTTPS only; HSTS; no plaintext fallback

Authentication

Rotatable API keys — issued by hand and revocable at any moment

API access

Per-key authentication with plan-aware rate limits

Data layer

Parameterised ORM queries; no hand-built SQL

Isolation

No shell execution on user input; no server-side templating of it

• There is no password login to attack: access is a key we issue by hand, and revoking it takes effect immediately.
• Admin console tokens are HMAC-signed and verified against a pinned algorithm; the none algorithm is rejected and exp, iat and sub are mandatory.
• Sessions are stateless, so there is no custom session cookie to fixate or steal.
• API keys are per-account, revocable, and scoped to the caller's plan.

The API is JSON-only and returns a fixed error envelope, so failures do not leak stack traces or query fragments.

Injection

ORM-parameterised SQL; no OS command, LDAP or XPath sinks

Host header

Trusted-host middleware; the Host header never builds links

Clickjacking

X-Frame-Options: DENY and CSP frame-ancestors 'none'

MIME sniffing

X-Content-Type-Options: nosniff

CSRF

Bearer/API-key auth rather than cross-site cookies, plus a CORS allow-list

Open redirect

No input-driven redirects; the outbound client does not follow them

SSRF

Outbound fetches go through a guarded client with address filtering

• Rate limits on authentication and console endpoints blunt brute force and credential stuffing.
• Cloudflare Turnstile gates public surfaces against automation.
• Quotas are enforced per key so one account cannot exhaust shared upstream capacity.
• Anomalous query patterns are logged and reviewed; accounts used for prohibited activity are suspended under the AUP.

Query inputs are held for the lifetime of the request and its short cache entry. Passwords are stored only as hashes, and full payment card data never reaches our systems — the payment provider handles checkout on its own domain. Retention windows for each category are listed on the Privacy policy.

We welcome reports from security researchers and will not pursue action against good-faith research that follows the rules below.

• Report privately first and give us a reasonable window to fix before publishing.
• Use only your own accounts and test data. Do not access, modify or exfiltrate other users' data.
• No denial of service, no volumetric or stress testing, no social engineering of our staff or providers, no physical attacks.
• Stop as soon as you have demonstrated the flaw, and tell us what you touched.

We will acknowledge your report, keep you informed while we triage, and credit you if you want the credit. We do not currently run a paid bounty.

In scope

This site, the console, and the documented REST API

Out of scope

Cloudflare, the hosting provider and other upstream platforms

Also out of scope

Findings with no security impact — missing best-practice headers, version banners, self-XSS, or reports generated purely by a scanner

Third-party data

The accuracy of OSINT corpora is not a vulnerability; use Data removal for identifier delisting

Send reports through the Telegram help desk or a console ticket, marked as a security report. Include the affected endpoint, the steps to reproduce, what you observed, and the impact you think it has. A working proof of concept moves triage along considerably faster than a scanner export.

To be completed by the operator: publish a dedicated security contact address and, ideally, a /.well-known/security.txt so researchers do not have to route reports through a general help desk.