Security
How wr.fi protects your data.
Honest status: wr.fi is a solo project, weeks old not years old. We've found and fixed 12 bugs through external security reviews from four AI models. The whole platform is open source — server (AGPL-3.0), CLI and MCP (MIT) — so you can audit every line at github.com/wrfi. But treat wr.fi like a public whiteboard, not a vault. Don't store secrets, credentials, or sensitive personal data here.
We'd rather be honest about where we are than pretend to be something we're not. Report issues at security@wr.fi.
Infrastructure
| Hosting | AWS Lightsail (eu-central-1 — Frankfurt) |
| DNS / CDN | Cloudflare (configuration varies — may be proxied or DNS-only depending on operational needs) |
| TLS | HTTPS everywhere. Certificate issued by Cloudflare or Let's Encrypt depending on proxy mode. |
| Database | SQLite (single file, encrypted at rest via EBS) |
| File storage | Content-addressed (SHA-256 dedup), local filesystem with EBS encryption |
| Reverse proxy | Caddy with HSTS |
| Application | Next.js 16 in Docker (node:20-slim) |
What we store
- Creations: title, content type, artifacts (files), metadata (provenance, generation info, tags)
- Artifacts: stored by SHA-256 content hash — automatic deduplication, no filename-based storage
- Accounts: username, bcrypt-hashed password, optional email (for notifications only)
- Sessions: random token, 30-day expiry, invalidated on password change
- Analytics: server-side event log (type, shortId, IP, user agent). No client-side tracking pixels.
What we don't store
- No tracking pixels, no ad cookies, no third-party analytics scripts
- No payment data (payment integration planned, not yet implemented)
- No browsing history beyond server access logs
- IP addresses: stored in server-side event logs for abuse prevention. Rate limit data is in-memory only and pruned every 24 hours.
Access model
| Tier | Visibility | Auth to view |
|---|---|---|
| Public | In feed, indexed | None |
| Unlisted | Not in feed, not indexed | None — URL only (~1.2M combinations) |
| Secret link | 8-char URL, not in search or explore | None — URL only (~2.8T combinations) |
| Password-protected | Not in feed | Password, view key, or edit token |
Unlisted ≠ private. 4-char IDs have ~1.2M combinations. At the rate limit of 300 reads/min, a single IP could enumerate the full space in ~67 hours. Unlisted means “not advertised”, not “protected.” For sensitive content, use 8-char secret links (~2.8T combinations) or password protection.
Edit tokens have ~4M combinations (2 words from a 2048-word dictionary). Combined with rate limiting (5 attempts per creation per hour, 50 total per IP per hour), brute-force takes ~95 years per token.
Security headers
- Content-Security-Policy (CSP) on all pages
- Strict-Transport-Security (HSTS)
- X-Frame-Options: DENY (except /embed/* which allows framing)
- X-Content-Type-Options: nosniff
- Permissions-Policy: restricted
- SameSite=Lax on all cookies, HttpOnly, Secure in production
- CORS:
*only on public push/read endpoints. Sensitive endpoints are same-origin only.
Rate limiting
- Anonymous pushes: 60/hour per IP
- Login attempts: 20/hour per IP
- Edit token failures: 5/shortId/hour
- ShortId reads: 60/minute per IP (enumeration protection)
- API key regeneration: 3/hour per account
Jurisdiction
wr.fi is operated by Kurikkai Oy, a Finnish company. Finnish jurisdiction means EU/GDPR by default, no FISA or CLOUD Act exposure. Data is processed in the EU (AWS eu-central-1, Frankfurt).
Open components
wr.fi is open source at github.com/wrfi:
- Server / platform — AGPL-3.0 (self-host your own private instance)
- CLI (
npx wrfi) — MIT - MCP server (
npx @wrfi/mcp) — MIT - WRFI specification — CC-BY-4.0
The server is open source — read exactly how your data is handled, or run your own instance. We publish our security practices on this page and respond to vulnerability reports within 48 hours.
Sandbox 503 errors
AI tools running inside sandboxed environments (Claude.ai web app, ChatGPT web, etc.) may see intermittent 503 DNS cache overflow errors on their first 1–3 requests. This is not a wr.fi issue — these 503 responses lack Cloudflare and Caddy headers, confirming they originate from the sandbox's own egress proxy, not from our origin.
Workaround: Retry after 2 seconds. The second attempt almost always succeeds. All wr.fi API responses include a Retry-After: 2 header on 5xx errors, and the CLI/MCP tools retry automatically.
Tools running locally (Claude Code, Codex, npx wrfi) bypass sandbox egress entirely and are not affected.
Responsible disclosure
Found a vulnerability? Email security@wr.fi. We respond within 48 hours and credit responsible disclosures. See also security.txt.