Security

Responsible disclosure.

mikrotikfilters.com is a community resource for RouterOS operators — security and privacy are first-order requirements, not afterthoughts. If you find a vulnerability, this page tells you how to report it and what we commit to in return.

How to report

  • Email security@mikrotikfilters.com with a description of the issue, impact, and reproduction steps.
  • Machine-readable contact: /.well-known/security.txt (RFC 9116).
  • Encrypted channel — PGP key URL is queued for the launch checklist; until it's published, send unencrypted reports and we'll respond to set up an encrypted channel if the report warrants it.

What we commit to

  • Acknowledge receipt of every good-faith report.
  • Engage in dialogue — clarifying questions, asking for repro steps, scoping the impact.
  • Credit you in the disclosure post if you want it (or keep you anonymous if you don't).
  • Never take adversarial action against a good-faith reporter — no legal threats, no Cloudflare bans, no takedown demands.

We don't publish a fixed turnaround time. mikrotikfilters is a solo-dev project and we don't make time-bound commitments we can't reliably keep. In practice we aim to acknowledge fast and ship fixes as soon as the impact + complexity warrant — which on a small surface usually means days, not weeks.

What we ask in return

  • Don't access, alter, or destroy data that isn't your own (test accounts you control are fine).
  • Don't degrade service for other users — no DDoS, no fuzzing in tight loops without rate-limiting, no credential-stuffing.
  • Give us a reasonable window to fix before public disclosure. We don't define "reasonable" rigidly — talk to us, we'll agree on a date together.
  • Stay within the scope of mikrotikfilters.com and its subdomains. The community-blocklist data inside the lists is upstream-supplied; vulnerabilities in the upstream feeds (Spamhaus, HotCakeX, Tor) belong with those projects.

Architectural posture

These controls are in place (or scheduled to be in place before v1.0 launch):

  • Strict CSP (no unsafe-inline, no unsafe-eval) — queued before v1.0.
  • HSTS preload-eligible (2-year, includeSubDomains, preload) — shipped in v0.32.2.
  • Strict transport headers: XCTO, XFO=DENY, COOP, CORP, Permissions-Policy with empty allowlists for unused features — shipped in v0.32.2.
  • Magic-link auth only — no passwords, no password-reset flow to defend.
  • Cloudflare Rate Limiting bindings (atomic, edge-shared) on auth + onboarding + submission surfaces — shipped in v0.32.1.
  • Stripe webhook signature verification + replay protection — queued before v1.0.
  • 2FA required for admin/moderator accounts — queued before v1.0.
  • Renovate / Dependabot for dependency updates; SAST (semgrep + npm audit) blocking on high/critical — queued before v1.0.
  • Audit log for every state-changing action — shipped in v0.25.0–v0.31.0; viewer at /admin/audit.
  • IP + User-Agent hashed at write-time with a salted scheme — DB never holds cleartext PII.