1. Encryption at Rest
TempClip encrypts every clip payload on our servers using AES-256-GCM before it is written to the database. Encryption and decryption are performed with a master key held only in our secured server environment and never exposed to the client or stored alongside your data.
The practical result: the raw rows in our database contain only ciphertext. A clip is decrypted on demand strictly to deliver it to an authorized recipient (and, where required, for the limited moderation purposes described below).
1.1 Encryption in Transit
Every connection is served over TLS 1.3. Your clip travels over an encrypted channel to our servers, is encrypted again at rest, and is only decrypted server-side when it is retrieved.
1.2 Content Moderation
Because we hold the encryption key, TempClip can decrypt a specific clip when necessary to investigate abuse reports or comply with a valid legal request. We do not read clips for advertising or analytics, and access is limited to authorized administrators acting on a report. See our Terms of Service for the acceptable-use rules this enforces.
2. Private File Storage (Cloudflare R2)
Files are stored in a fully private Cloudflare R2 bucket with no public access. Uploads use a short-lived S3 presigned PutObject URL so your file goes straight from your browser to R2, bypassing our server memory entirely.
- Downloads are served via a presigned
GetObjectURL that expires in 5 minutes. - Links cannot be hotlinked or shared permanently — each access is freshly authorized.
- No object is ever publicly addressable.
3. Burn-on-Read Mechanics
Burn-on-read clips are destroyed the instant they are successfully retrieved. Retrieval and deletion happen inside a single atomic database operation, so a clip can never be served twice even under concurrent requests.
- The recipient requests the clip by PIN.
- An atomic update marks the record as burning and collapses its expiry, preventing race conditions.
- The encrypted record is shredded and queued for permanent deletion.
4. Automatic Expiry & Row-Level Security
Independent of burn-on-read, every clip carries a hard expiry enforced at the database layer. Row-Level Security policies ensure a clip can only be fetched while expires_atis still in the future — expired records are invisible to the API and swept from storage.
5. Abuse Prevention & Rate Limiting
PINs are short for convenience, so we apply strict, IP-based rate limiting at the edge using Upstash Redis. Clip creation is capped at 10 requests per minute, and PIN entry is limited to 5 failed attempts per minute to make brute-force guessing impractical. Exceeding a limit returns an HTTP 429 and a brief cooldown.
6. Responsible Disclosure
We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@tempclip.dev with details so we can investigate and respond quickly.