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, so 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, please use our Vulnerability Report form, which routes directly to our security team. You can also email [email protected] directly. Either way, please include:

• 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. With your permission, valid reports are credited on our Security Hall of Fame.

Security reports: [email protected].