Designing expiration and deletion

Define the states

A secret may be available, claimed, consumed, expired, or administratively removed. Define which transitions are legal and what the user sees for each. Avoid a soft-delete flag that leaves ciphertext accessible to ordinary application queries indefinitely.

Consume atomically

Two recipients can click nearly simultaneously, and clients retry failed requests. The storage operation should allow exactly one request to change an available record to consumed and obtain its ciphertext. A later request receives only a terminal result. Separate “read” and “delete” operations create a race window.

Use server time for expiry

Make expiry decisions using a trusted server clock. A background sweeper can remove old rows for storage hygiene, but retrieval must also reject an expired record immediately; otherwise a delayed cleanup job extends the promised lifetime.

Understand deletion limits

Database deletion does not erase replicas, backups, caches, logs, or recipient copies instantly. Minimize where ciphertext travels, set cache controls, document backup retention, and avoid logging request or response bodies. Be precise about what “deleted” means operationally.

Keep evidence without the secret

Operators may need to know that an item was created, expired, or consumed. Store minimal event metadata using opaque identifiers, short retention, and controlled access. Do not log decryption keys, full links, plaintext, or notification addresses unnecessarily.

Test clock boundaries, concurrent requests, storage failures, queue delays, restoration from backup, and repeated client retries. The promise users see must match behavior under failure—not only the happy path.

Sources and review basis

This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references:

• OWASP Secrets Management Cheat Sheet
• OWASP Cryptographic Storage Cheat Sheet