Security policy

Vulnerability disclosure policy, scope, and safe harbour. RFC 9116 and ISO/IEC 29147 aligned.

If you have discovered a vulnerability in Dokima (the public scanner, the API, the badge endpoint, the CLI, the frontend, or our infrastructure), email us at [email protected] with as much detail as you can share. The well-known machine-readable contact point is /.well-known/security.txt per RFC 9116.

We follow a two-stage acknowledgement process aligned with RFC 9116 and ISO/IEC 29147 vulnerability-disclosure norms.

• Automated acknowledgement within 24 hours of receipt: every report is auto-acknowledged with a tracking identifier of the form DKM-VDP-YYYYMMDD-XXXX and an estimated triage window. Quote the tracking identifier in any follow-up so we can correlate fast.
• Human triage within 1 to 3 business days following the automated acknowledgement, with substantive reply, severity assessment (CVSS where appropriate), and proposed remediation timeline.
• Status updates at minimum every 5 business days while the report is open.
• Resolution timeline agreed in writing with the reporter; we negotiate disclosure timelines in good faith.

A useful report typically contains:

• a clear description of the issue and its impact;
• the affected surface (URL, API endpoint, CLI version, page route);
• reproduction steps a third party could follow — minimal proof of concept, request and response examples, screenshots;
• any sensitive data you encountered (stop testing immediately; describe what you saw, do not exfiltrate);
• your suggested severity and remediation, if you have one;
• how you would like to be credited in the acknowledgements section (or that you prefer to remain anonymous).

A short, well-structured report is more valuable than an exhaustive one — send what you have; we will ask follow-ups.

We will not pursue legal action against good-faith security researchers who follow this disclosure process. To qualify for safe harbour you should:

• test only against your own accounts and identifiers; do not access, modify, or destroy data you do not own;
• stop testing immediately if you encounter sensitive data and report what you saw rather than exploring further;
• give us a reasonable time window to remediate before public disclosure (typically 90 days, negotiable);
• do not perform volumetric attacks, social engineering against staff, or any action that degrades service for other users.

Outside good-faith research, the Acceptable Use Policy applies and conduct may constitute an offence under the Computer Misuse Act 1990. The Acceptable Use Policy governs what testing is permitted without prior written authorisation.

In scope:

• dokima.dev and all subdomains
• the public API and badge endpoint
• the Dokima CLI binary (latest release)
• infrastructure under our direct operational control

Out of scope:

• subprocessors (report directly to Hetzner, Cloudflare, Lemon Squeezy, MailerSend, Sentry, Grafana via their own security programmes)
• third-party dependencies for which we are not the upstream
• self-hosted forks of the open-source engine (those are out of our control)
• denial-of-service findings demonstrated only by volumetric load (we cap your traffic anyway)
• social-engineering of staff, vendors, or customers — please do not attempt
• findings on staging or pre-release surfaces that are not reachable from a customer-resolvable URL

• Critical: remote code execution, authentication bypass, full database read, full account takeover at scale, payment-system compromise.
• High: individual account takeover, persistent stored XSS on a customer-facing surface, privilege escalation within a tier, score-manipulation primitives at scale.
• Medium: CSRF on state-changing endpoints, broken access control on non-sensitive surfaces, information disclosure of non-personal data.
• Low / Informational: rate-limit edge cases, missing security headers without a concrete impact, minor misconfiguration.

At our discretion, and with the reporter's consent, we credit researchers in our security acknowledgements (a public list, this page, lower on this page). The acknowledgements section is empty at launch; submissions accepted from day one.

No public acknowledgements yet. Submit a finding to be the first.