Security & Vulnerability Disclosure Policy

We take the security of Quklink and its users seriously. This page describes the technical measures we rely on and how to report a vulnerability to us responsibly.

• Session tokens are signed using an asymmetric (RS256) keypair, not a shared secret — a leaked server config alone cannot be used to forge a valid session.
• Passwords are hashed before storage; we never store or log plaintext passwords.
• Cookies carrying session tokens are HTTP-only, secure in production, and scoped with a restrictive SameSite policy so they cannot be read by page scripts or leaked cross-site.
• Security-sensitive comparisons (e.g. one-time tokens) use constant-time comparison to resist timing attacks.
• Content Security Policy and HTTPS/HSTS are enforced to reduce the risk of injected-script and downgrade attacks.
• Rate limiting is applied to authentication and other sensitive endpoints via a Redis-backed limiter. In the rare event our rate-limiting infrastructure is unreachable, requests are allowed through rather than blocked (a fail-open design), so rate limiting should not be relied on as an absolute guarantee.
• File uploads are restricted to specific image formats, validated by both MIME type and extension, and size-capped, to reduce the risk of malicious file uploads.
• Admin access is restricted to a single authorized account, gated by a magic-link plus password step, independently re-checked at the edge on every request.

This disclosure process covers the Quklink web application and its APIs. It does not cover third-party services we integrate with (e.g. Stripe, Google, Microsoft, Bunny.net, Upstash, MongoDB Atlas) — please report vulnerabilities in those services directly to their own security teams.

If you believe you've found a security vulnerability, email support@quklink.com with:

• A clear description of the vulnerability and its potential impact.
• Steps to reproduce it, including any request/response details needed.
• Your contact information, so we can follow up with questions or credit you if you'd like.

• Give us a reasonable opportunity to investigate and address a report before disclosing it publicly.
• Avoid accessing, modifying, or deleting data that isn't your own while testing.
• Do not run automated scanning or load-testing tools against production without our prior written permission.
• Do not attempt to exploit a vulnerability beyond what's necessary to demonstrate it.

We will acknowledge a good-faith report, investigate it, and keep you reasonably informed of our progress. We will not pursue legal action against researchers who follow the guidelines above.

Security reports: support@quklink.com.