Security

Last updated: July 7, 2026

Our security model

Clippy uses a link-as-secret model: knowing the URL is the primary access control for anonymous clips. For sensitive content, use PIN protection or client-side end-to-end encryption.

Transport security

In production, Clippy should be deployed behind a reverse proxy that terminates TLS (HTTPS). We set secure cookies when HTTPS is detected and recommend always accessing the service over encrypted connections.

Access controls

• PIN protection — optional per-clip PIN, stored as a bcrypt hash. Five failed attempts trigger a 15-minute lockout per IP.
• Unlock cookies — after PIN entry, an httpOnly HMAC-signed cookie grants access for 24 hours.
• End-to-end encryption — AES-256-GCM in the browser; the server never sees plaintext or the decryption key.
• Team clips — registered users can restrict team-owned clips to team members.

Data lifecycle

• Default TTL: 24 hours, configurable per clip
• Burn-on-read: optional single-read deletion via API
• Background cleanup: expired clips and orphan files are permanently deleted
• View limits: optional cap on API reads (1, 3, 10, or unlimited)

Abuse prevention

• Per-IP rate limits on API requests and clip creation
• File upload size limits
• Content size limits on API and WebSocket updates
• Webhook URL validation to prevent server-side request forgery

HTTP security headers

We send Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers on all responses.

What we do not claim

• We do not encrypt data at rest in the database by default
• We do not guarantee protection against someone who already has your link
• Self-hosted deployments are the operator's responsibility to harden

Responsible disclosure

If you discover a security vulnerability, please report it to security@example.com. We appreciate responsible disclosure and will work to address confirmed issues promptly.