Enterprise buyer's guide: evaluating Linktary (the security questionnaire, pre-answered)
Enterprise buyer's guide: evaluating Linktary (the security questionnaire, pre-answered)
If you're running a vendor security review, this is the article for the person filling in the spreadsheet. It answers the standard questionnaire against the actual architecture — not the marketing version.
Data flow
Every piece of data Linktary handles moves through one deployment: a single Cloudflare Worker backed by Cloudflare D1, on the single domain linktary.com.
- Link creation. Your browser POSTs the destination to the API over
- Redirect (the click path). Exactly one indexed database read by
- Trust report. Anyone can open
/v/<code>and see the verdict, the - Authentication. Email magic links; no passwords stored anywhere.
TLS 1.3. The Worker encrypts the destination (AES-256-GCM, per-link random nonce), runs the verification engine against the plaintext — the verifier receives the destination blob and a job nonce, never your identity — and stores the encrypted record plus the verdict.
short code, decrypt, increment an aggregate click counter, 302. No verification runs on this path; no per-visitor data is recorded.
chain, the signals, and the check timestamp — HTML for browsers, JSON for agents. This is public by design.
Sessions are token hashes with 30-day expiry; magic-link tokens are single-use with 15-minute expiry.
The full diagram, with the encryption boundaries, is on the /security page.
Retention
| Data | Kept | Deleted |
|---|---|---|
| Link records (encrypted destination, verdict, chain) | While your account exists, or until you delete the link | On delete: soft-deleted immediately (link stops working, returns 410); purged from active queries |
| Account email | While your account exists | On account closure |
| Sessions | 30 days, sliding | Expire automatically; expired sessions are deleted lazily on lookup |
| Magic-link tokens | 15 minutes, single-use | Consumed on use; expired tokens are inert |
| Rate-limit counters | Minutes (sliding windows) | Expire with the window |
| Abuse reports | Until reviewed and resolved | On resolution, per the review outcome |
| Visitor data (IPs, user agents, referrers) | Never collected | Nothing to delete |
Subprocessors
One: Cloudflare — compute (Workers), database (D1), DNS, and TLS termination. There is no analytics vendor, no email vendor beyond the Worker's own MailChannels integration for transactional sign-in email, no error-tracking beacon, no third-party script on any page. When the threat-intel provider seam is activated (a future phase), feeds like Google Safe Browsing will be listed here before they see a single URL.
What we can and cannot see
See The honest crypto design for the full essay; the short version: we encrypt destinations at rest and never log them; we never collect per-visitor data; the verification pipeline is identity-separated. We do not protect against a compromised Cloudflare account — whoever controls it can read the Worker secrets, including the master key. Per-customer key-encrypting keys (enterprise tier) close that gap by putting the key in your hands.
Incident response
- Abuse reports: anyone can file one at
/report-abuse, no account - Security vulnerabilities: report to the contact on the
- Breach posture: because destinations are encrypted at rest,
needed. Reports are reviewed by the team; confirmed malicious destinations are blocked, which also feeds the blocklist that protects every other link.
security page (coordinated disclosure). We commit to acknowledging promptly and to publishing what we fixed once it's fixed.
sessions are hashes, and visitor data doesn't exist, the blast radius of a database-layer compromise is bounded by design. The residual risk is the Cloudflare-account scenario above — which is exactly why the customer-held KEK path exists for the enterprise tier.
DPA posture
The free tier ships without a negotiated DPA — it's a fair-use, minimum-knowledge service where we hold almost nothing about you. The enterprise tier (SSO, audit logs, customer-held encryption keys, SLA) ships with DPA support, because that's the tier where the paperwork has to match the posture. If your procurement process needs a DPA to proceed, talk to us: hello@linktary.com.
How to run a security review of us
You don't need our permission, and you don't need a sales call:
- Create a link. Open its trust report. Verify the verdict, chain, and
- Shorten something hostile and watch the verdict change. The report
- Check what we store about your clicks: create a link, click it from
- Read /security and /privacy, then compare
timestamp match what the engine claims in How Linktary verifies a link.
will tell you exactly which signals fired.
two different networks, and ask us what we recorded. The answer is an aggregate counter.
them against this article. They should agree — if they don't, that's a finding, and we want to hear it.
Vendors who are confident in their architecture hand you the tools to verify it. That's what this guide is.