Found a vulnerability?

We take security seriously and we welcome responsible disclosure from researchers and users. If you've found a vulnerability in htmldrop, please tell us before posting it publicly.

How to report

Email [email protected] with:

• A short description of the issue.
• The steps you took to reproduce it, with example requests / payloads if possible.
• The affected component (marketing site, dashboard, API, share serving, worker, infra).
• Whether you'd like to be credited if we publish a fix advisory.

If you'd like to encrypt your report, ask us for our PGP key in the first message and we'll send it back.

What we'll do

• Acknowledge your report within 2 business days.
• Triage and reproduce within 5 business days.
• Aim to ship a fix within 30 days for high-severity issues, sooner for actively exploited ones.
• Keep you updated through the cycle.
• Credit you (with your permission) once a fix is released.

Safe-harbour for researchers

If you act in good faith, follow this policy, avoid privacy violations, data destruction, and service degradation, and give us a reasonable chance to fix the issue before disclosing it publicly, we won't take legal action against you.

Please do not:

• Run automated scans that generate significant load.
• Test against other users' drops without their permission.
• Exfiltrate data beyond the minimum needed to demonstrate the issue.
• Use social engineering against our team or users.

Encryption

htmldrop applies encryption in layers — each one a separate defence so a single compromise doesn't read the whole stack:

• In transit. Every external connection runs over TLS 1.2+; certificates issued by Cloudflare for the apex and via Cloudflare for SaaS for customer custom hostnames.
• Drop content at rest. The object store (MinIO) is configured with SSE-S3 default encryption: every drop body is encrypted with AES-256 via a server-side master key (MINIO_KMS_SECRET_KEY) kept in a Kubernetes secret, never in source. Reads transparently decrypt so customers don't notice the difference at the share URL.
• Customer integration tokens at rest. Cloudflare API tokens (and any future BYO connector credentials) are sealed with AES-256-GCM via a 32-byte CREDENTIAL_KEY before they touch the database. A DB snapshot leak doesn't yield usable tokens.
• Passwords. Account passwords and drop passwords are stored as Argon2id hashes. We never learn the plaintext, even at first set.
• Session + share cookies. HMAC-signed JWTs with separate secrets per surface (login session, share unlock, anonymous tenant). A leaked one signs none of the others.

What we already do

Other controls in place today (this list isn't exhaustive — it's a snapshot, not a guarantee):

• Server-side input validation on every endpoint that accepts user content.
• Per-IP rate limiting on anonymous drop uploads.
• Cloudflare Turnstile gating the anonymous upload endpoint against bot traffic.
• Heuristic + manual abuse review for phishing and credential-harvest patterns; trip wires fire a 410 Gone with no preview.
• Regular dependency updates and migrations applied atomically on startup with an advisory lock.
• Principle-of-least-privilege secrets in Kubernetes, pulled from a single managed secret store.
• Soft-delete + 30-day grace on account deletion, with a worker that hard-deletes (rows + object-store prefixes) at the deadline.

What's not in scope

• Issues that require physical access to a user's device.
• Issues in third-party services we use (please report those to the provider — we're happy to forward).
• Self-XSS reports that require the victim to paste a payload into their own dev tools.
• Missing best-practice security headers without a concrete impact.
• Email-spoofing reports against domains we explicitly don't send email from.

Contact

Middle East Software Solutions Limited
Security: [email protected]