Security model

What is protected

• Files are encrypted client-side before upload.
• Encryption uses AES-GCM through the browser Web Crypto API.
• The decryption key is generated in the sender's browser.
• The key is included after # in the share URL.
• URL fragments are not sent in HTTP requests.
• Recipients decrypt files locally in their browser.

What the server can see

SecureTransfer needs limited operational data to run transfers. The server may see or store:

• Encrypted file blobs.
• Transfer metadata such as size, expiry, file count, view count, download count, and download limits.
• Sender and recipient email addresses if email notifications are used.
• Payment metadata for paid transfers.
• Operational and security logs.

The server should not receive file contents, decryption keys, plaintext text shares, or plaintext key/value shares.

Security controls

• Strict-Transport-Security (HSTS).
• Content Security Policy (CSP).
• X-Content-Type-Options: nosniff.
• X-Frame-Options: DENY.
• Strict origin referrer policy.
• Rate limiting on upload, download, view, notify, read, and delete endpoints.
• Automatic expiry cleanup and download limits.
• Static route path traversal protection for served files.

Limitations

• Anyone with the full share URL, including the #key= fragment, can decrypt the transfer.
• A compromised browser or device can expose files before or after encryption.
• Recipients can copy, save, or re-share files after download.
• Email notifications reveal sender and recipient email addresses to the service.
• Encryption does not automatically make a workflow compliant with regulatory requirements.
• Send links through trusted channels and treat full links as sensitive.

Responsible disclosure

To report a vulnerability, contact Clevero AB through clevero.se.