Enzonic Send
Sign in
  1. Home
  2. Legal
  3. Security & Responsible Disclosure

Security & Responsible Disclosure

Last updated 2026-10-17

Summary in plain English

Your files travel over encrypted HTTPS connections and are encrypted at rest by our storage provider, and they are deleted automatically when the transfer expires. Enzonic Send is not end-to-end encrypted, so for confidential files, encrypt them yourself before uploading. If you find a security vulnerability, email admin@enzonic.com with the subject line "Security". We will not take legal action against good-faith research that follows this policy.

Last updated: October 17, 2026

1. How we protect your files

Enzonic Send is operated by Enzonic LLC and runs on Cloudflare's global infrastructure: Cloudflare Workers for application logic, Cloudflare R2 for file storage and Cloudflare D1 for transfer metadata.

Protection What it does
Encryption in transit All traffic between your browser or app and the Service uses HTTPS with TLS.
Encryption at rest Files stored in Cloudflare R2 are encrypted at rest by the storage provider.
Automatic deletion Files are permanently deleted when a transfer expires (1 hour to 7 days, plus up to 3 days of extensions), or earlier if the sender deletes the transfer.
Password protection Optional transfer passwords are stored only as a salted hash, never in plain text.
Download limits Optional download limits stop a transfer from being downloaded more times than you intend.
Hashed IP addresses We store a salted hash of the uploader's IP address for quotas and abuse prevention, not the raw address.
Network protection Cloudflare's network helps protect the Service from denial-of-service attacks, bots and other common threats.
Account security Sign-in is handled by Clerk, a dedicated authentication provider, with email/password or Google sign-in.
Limited access Access to production systems is restricted to the people who need it to run the Service.

2. What our encryption does not cover

We want to be clear about this: Enzonic Send is not end-to-end encrypted.

  • Files are encrypted by the storage provider using keys managed by the infrastructure, not by keys that only you and your recipient hold.
  • This means our systems can technically access file contents, for example to deliver them to recipients or to respond to valid legal requirements. We do not routinely look at files, and we do not scan them for advertising.
  • Anyone who has a transfer's share link, 6-digit code or QR code can access the transfer, unless you also set a password. Six-digit codes are designed to be short and easy to type, so they are best for quick transfers. For anything sensitive, set a password, a download limit and a short expiry.

Tips for sensitive files

  • Encrypt files before uploading, for example with a password-protected encrypted archive (such as 7-Zip with AES-256) or a tool like age or GPG.
  • Send the password or key to your recipient through a different channel from the link or code.
  • Choose the shortest expiry that works and a download limit of 1 where appropriate.
  • Delete the transfer as soon as your recipient has the file.

3. Keeping yourself safe as a recipient

Files are uploaded by users, not by us. Only open files from people you trust, and scan downloads with up-to-date security software. See our Disclaimer. If you receive a suspicious or malicious transfer, report it at https://send.enzonic.com/report.

4. Reporting a vulnerability

We welcome reports from security researchers and users who find vulnerabilities in Enzonic Send.

Email: admin@enzonic.com with the subject line "Security".

Please include:

  • a description of the vulnerability and its potential impact;
  • the affected URL, endpoint, app version or component;
  • clear, step-by-step instructions to reproduce it, with a proof of concept where possible;
  • any relevant screenshots, request/response samples or logs (please remove other people's data); and
  • how you would like to be credited, if at all.

What you can expect from us

  • We will acknowledge your report, usually within 5 business days.
  • We will investigate, keep you reasonably informed of our progress, and let you know when the issue is fixed.
  • We will treat your report confidentially and will not share your personal details without your permission, except where the law requires it.
  • With your permission, we will be happy to credit you publicly once the issue is resolved.

We do not currently run a paid bug bounty program.

5. Rules of engagement

When researching vulnerabilities, please:

  • only test against transfers and accounts you own or have explicit permission to use;
  • do not access, modify, download or delete other users' files or data; if you accidentally access someone else's data, stop, do not keep or share it, and tell us in your report;
  • use the minimum testing necessary to demonstrate the issue;
  • do not degrade or disrupt the Service for other users;
  • keep the details confidential until we have fixed the issue, or until 90 days have passed since your report, whichever comes first, unless we agree otherwise; and
  • comply with all applicable laws.

6. Safe harbour

If you make a good-faith effort to comply with this policy while researching and reporting a vulnerability, we will consider your research to be authorized, and:

  • we will not initiate or support legal action against you, including under the Computer Fraud and Abuse Act, the DMCA's anti-circumvention provisions, or similar laws, for that research;
  • we will treat your research as an authorized exception to the restrictions on security testing and automated access in our Terms of Service and Acceptable Use Policy, to the extent needed for that research; and
  • if a third party brings legal action against you for activity that complied with this policy, we will make it known that your actions were authorized by us.

This safe harbour does not apply to activity that goes beyond what is reasonably necessary to identify a vulnerability, that harms users or the Service, or that breaks the law. We cannot authorize testing of third-party systems, including Cloudflare, Clerk, Google, Apple or Google Play infrastructure; please report issues in those systems to the relevant provider.

7. Out of scope

The following are out of scope and will generally not be accepted as vulnerabilities:

  • denial-of-service or distributed denial-of-service attacks, and load or stress testing;
  • social engineering, phishing or physical attacks against Enzonic, its staff, users or providers;
  • spam, or sending large volumes of transfers or reports;
  • brute-forcing or enumerating share links, 6-digit codes or passwords at scale (you may describe a theoretical weakness without carrying out the attack);
  • findings in third-party services or infrastructure (Cloudflare, Clerk, Google AdSense/AdMob, app stores) that we do not control;
  • the content of third-party ads;
  • reports from automated scanners without a demonstrated, exploitable impact;
  • missing security headers, cookie flags or best-practice configurations without a demonstrated exploit;
  • clickjacking on pages without sensitive actions;
  • self-XSS, or issues that require an attacker to already have full control of the victim's device or browser;
  • CSRF on logout or other actions with no security impact;
  • SPF, DKIM or DMARC configuration on email domains;
  • software version disclosure or banner grabbing;
  • issues affecting only outdated or unsupported browsers, operating systems or app versions;
  • rate limiting on non-sensitive endpoints; and
  • the fact that the Service is not end-to-end encrypted, or that anyone holding a link or code can access an unprotected transfer, which are documented design choices.

8. Contact

Enzonic LLC, Commonwealth of Kentucky, USA Security reports: admin@enzonic.com (subject line "Security") Abuse reports: https://send.enzonic.com/report