Link Security: Passwords, Expiry & GDPR

You email a client a Dropbox link to the unreleased Q3 deck. The client forwards it to a colleague. The colleague pastes it into Slack. Someone screenshots that Slack message. Two weeks later, the deck shows up on a competitor's blog. There was no breach, every step was authorized. The link itself was the security perimeter, and the perimeter was an unguarded HTTPS URL.

This is the unglamorous truth about link security: most exfiltration paths run through links that should never have lived forever, never have been open to anyone with the URL, never have been generic enough to survive sharing. The remedy isn't deeper crypto. It's a small set of mundane controls, passwords, expiration, click limits, applied consistently to anything sensitive.

What confidential link content looks like

Any of these should not live behind a plain short link:

• Client deliverables, work-in-progress assets, signed creative
• Pre-release product screens, beta builds, internal demos
• Pricing and contract drafts shared with prospects
• HR documents, legal contracts, healthcare records
• One-time access codes, reset tokens, internal admin links
• Any URL where leakage would be a real-business problem

The countermeasures aren't expensive or hard to deploy. They're mostly toggles. The problem is that most teams have never turned them on.

The defense-in-depth model

Three layers, applied in order:

1. Make the link unguessable, long destination URLs, branded short links via a domain you control (see custom domains and trust)
2. Authenticate at the redirect, passwords at the link layer, and two-factor authentication on the accounts that manage the links
3. Make the link finite, expiration dates, click limits, manual revocation

Plus a meta-layer: visibility. Flyn's click history tells you when and roughly where a link was opened, which is often the first signal that a link traveled further than intended.

The simplest meaningful control: require a password before the redirect fires. When someone visits a password-protected Flyn short link, they see a clean, branded prompt asking for the password. Enter the right one, the redirect proceeds. Enter the wrong one, nothing leaks, not the destination URL, not the existence of the file, not even whether the password attempt was close.

When to use password protection

• Client deliverables, share a password out-of-band (over the phone, in a separate channel) so even an intercepted email leaks only the link, not the access. A password-protected Dropbox link shortener link is a clean way to gate a shared file or folder exactly like this
• Private event invitations, RSVP links, exclusive content drops
• Internal docs shared externally, knowledge-base articles your partners need but the public shouldn't
• Pre-release content embargoes, press kits, product launches, demo videos
• Confidential URLs in customer support, diagnostic dashboards, account-level admin views

How Flyn stores passwords

Hashed server-side with bcrypt, never stored in plaintext. You can change a password at any time without breaking the link, recipients who haven't accessed yet need the new password. Old passwords are immediately invalidated, and repeated wrong guesses are throttled by a per-link lockout to blunt brute-force attempts.

Setting a password, dashboard and API

From the dashboard: open any link's settings, scroll to Access control, set a password, save. From the API: pass the password field on POST /api/links or PATCH /api/links/:id, see the links endpoint doc for the schema. The password is set in cleartext over the encrypted API connection and immediately hashed.

The companion control to passwords: limit how long a link works. Set an expires_at timestamp; after that moment, the link stops redirecting and serves a clean This link has expired page.

Why expiration is the most underused security control

Passwords protect against unauthorized access by people without the password. Expiration protects against everything else, copy-paste leaks, archived emails, accidental indexing, departed employees with old links, you name it. A link that expired six months ago can't leak today.

Common expiration use cases

• Job postings, automatically stop redirecting when the role closes; saves you from a stale Glassdoor page driving applicants to a 404
• Promotional offers, coupons, sale pages, time-limited landing pages
• Event materials, registration links, schedule PDFs, session recordings (with renewal as needed)
• One-time tokens, password resets, magic links, invitation flows (often combined with a 1-click-limit)
• Healthcare and legal access, short-window access pages, always with the sensitive content gated behind the destination's own authentication

Setting expiration

Dashboard: Access control > Expires at, pick a date and time. API: set expires_at as an ISO 8601 timestamp on POST /api/links or PATCH /api/links/:id. The dashboard timezone is your account timezone; the API uses UTC by default but accepts any offset.

Click-count limits

Click limits (a Pro feature) add the complementary control: clickLimit. The link stops serving its destination after N real human clicks, regardless of date, and sends later visitors to a fallback URL you choose or a clean closed page. Set clickLimit: 1 and the link works exactly once, then dies. Particularly useful for emailed download links to one-off deliverables; the full guide is at links that expire after a number of clicks.

What happens after expiration

The link record remains in your dashboard for analytics reference. Click history is preserved. You can extend or remove the expiration at any time to re-enable the link, or archive it permanently. Expired links are not deleted unless you explicitly archive, they're kept for audit-trail purposes (which matters for compliance reviews).

Click analytics on short links is a privacy minefield if done naively. Most link shorteners log full IP addresses indefinitely, store browser fingerprints, set persistent cookies, and call third-party trackers. Each of those is a GDPR exposure if you operate in the EU or have EU users.

Flyn's analytics are privacy-first by design. Here's exactly what we collect, what we don't, and where the legal lines sit.

What Flyn collects on every click

What this means for GDPR Article 4 personal-data definitions

Because Flyn's click records don't contain anything that, alone or in combination, identifies a natural person, individual click rows are not "personal data" in the GDPR sense. Aggregate analytics over country, device, browser, time are fully usable without consent banners. See Privacy Policy and GDPR notes for the full legal positioning.

Where this gets nuanced

If you add personal identifiers to a link's UTM parameters ([email protected]) or its slug, those identifiers become personal data the moment they're logged. Flyn can't prevent this and the responsibility shifts to you as the controller. The short link safety checker flags links that contain email patterns, names, or session-token-shaped strings.

GDPR Article 15 (right of access) and Article 17 (right to erasure) require operators to provide self-service data export and deletion. Flyn implements both as one-click flows in the dashboard and as authenticated API endpoints.

Data export

From the dashboard: Settings > Data & Privacy > Export my data. Generates a complete JSON archive containing:

• Account profile (email and settings)
• Every link you've ever created with all metadata
• Every click event ever recorded against your links
• Folders and tags
• Custom domains
• API key names and creation dates (never the plaintext keys)
• Webhook configurations

The export downloads as a single JSON archive. For automation, the same export is available via GET /api/account/export, see the docs index.

Account deletion

From the dashboard: Settings > Data & Privacy > Delete my account. Requires you to type your account email to confirm. Once submitted, the deletion is irreversible and processes immediately:

• All links stop redirecting (existing short URLs return a generic "not found" page)
• All click history is purged
• API keys are revoked
• Custom domains are unverified (you should also remove the CNAME at your DNS provider)
• Billing records are retained only as long as applicable tax law requires

Granular data deletion

If you don't want to nuke the whole account but need to remove specific data, delete individual links: DELETE /api/links/:id or the dashboard delete button removes a link, and its click history goes with it. Pro accounts can select multiple links and bulk-delete them in one action. If you want the data on record before removing it, run the export first.

Individual link controls protect content. Workspace-level controls protect operations, who can create links, who can see analytics, who touches billing. Here is what Flyn actually ships for teams, and, just as important, what it does not.

Workspace roles

Flyn team workspaces ($4 per seat per month) use four roles: owner (billing and the workspace itself), admin (manage members and shared resources), member (create and edit links), and viewer (read-only access to links and analytics). The people who can change where money and domains point stay a much smaller set than the people who can make links, which is the property that matters: on any link platform, whoever controls the branded domain configuration can effectively repoint every short link on that domain.

Account security

Sign-in is email and password or Google sign-in, with optional TOTP two-factor authentication (any standard authenticator app). Enable 2FA on every account that has dashboard access; a leaked password on an account that manages your public links is a supply-chain incident waiting to happen.

Abuse protection built into the redirect

Two protections run whether you think about them or not. Every destination is checked against Google Safe Browsing when a link is created or edited and re-scanned on a recurring schedule, so a destination that turns malicious after the fact gets caught and the link disabled. And password-protected links carry a brute-force lockout: repeated wrong guesses are throttled per link, so an attacker cannot grind through a password list against your client deliverable.

What Flyn does not offer (on purpose, for now)

Flyn does not currently offer SAML SSO, SCIM provisioning, customer-facing audit logs, or IP-allowlisted API keys. If your procurement process requires those certifications and controls, an enterprise-focused platform is the honest recommendation today. For teams whose real needs are role separation, 2FA, scanned destinations, and per-link access controls, the stack above covers the practical threat model at a fraction of enterprise pricing.

If you operate under HIPAA, GDPR, SOC 2, CCPA, or similar regimes, this checklist covers the controls auditors will look at. Treat it as a Monday-morning review template for your link library.

The 10-point quarterly review

1. No PII in slugs, tags, or UTM parameters. Run the link safety checker against your link library to find anything that smells like email, name, or session token. Migrate offenders to non-PII alternatives.
2. Password protection on every confidential link. Default to off, opt-in for sensitive content. Don't rely on "long random slug" as the only access control.
3. Expiration on temporary access. Job postings, time-limited promos, one-time access tokens, set expires_at on creation, not "later when I remember".
4. API keys scoped and rotated. Minimum necessary scopes, rotated quarterly or on personnel change. The API guide covers the rotation flow.
5. Link library reviewed quarterly. Spot check for links that should have expired, passwords that should have rotated, and analytics that show a private link traveling further than intended.
6. Two-factor enabled. Flyn supports TOTP 2FA; turn it on for every account with dashboard access, especially owners and admins.
7. Processor documentation done. EU controllers should record Flyn in their processor register and review the privacy policy and GDPR notes for what is and is not collected.
8. Data retention windows documented. If you need shorter retention than default, configure it explicitly. See the retention section below.
9. Custom domain certs in good standing. SSL is auto-provisioned, but verify your DNS-verification record hasn't drifted.
10. Departed-employee access revoked. Check the team member list, remove former members, and revoke any API keys they created from Settings.

Mapping to specific frameworks

• SOC 2: items 4, 5, 6, 9, 10 map to the Common Criteria; items 1, 7, 8 are typically Confidentiality criteria (note this maps your controls; Flyn itself is not SOC 2 certified)
• HIPAA: do not share PHI via short links at all; Flyn does not sign BAAs, so PHI belongs inside a HIPAA-compliant system end to end
• GDPR: items 1, 7, 8 are the high-frequency findings in EU audits
• ISO 27001: most items map to A.9 (access control) and A.12 (operations security)

The most overlooked compliance failure in link management isn't a misconfigured setting. It's the absence of a quarterly review. Click history is forensic; control of the future requires showing up to look at the library every three months and ask "is this still right?"

GDPR Article 5(1)(e) (storage limitation) and similar provisions in CCPA, LGPD, and PIPEDA require organizations to define and enforce retention limits for personal data. For link analytics, this means deciding how long click event data is kept and how long links live before archival.

Default retention behavior

• Click events: 30 days of history on the Free plan, unlimited retention on Pro
• Link records: retained for the lifetime of the account; never auto-deleted

Enforcing a shorter window yourself

Flyn does not offer configurable auto-deletion windows today. If your data-minimization policy requires one, enforce it operationally: export your data on your schedule (the JSON export includes every click event), then delete the links whose history has aged out; deleting a link removes its click records with it. On Free, the 30-day retention window effectively acts as a short retention policy by default.

Deactivation vs deletion

For links themselves, the recommendation is to deactivate rather than delete links that are no longer active. The clean way to switch a link off without losing its record is to set its expiration to now (or a past date): it stops redirecting, visitors see the standard expired page, the record and click history stay in your dashboard, and you can remove the expiry at any time to bring it back.

Permanent deletion via DELETE /api/links/:id or the dashboard delete button removes the record and its click history entirely, use it when you have a documented retention-policy reason. Pro accounts can bulk-select and delete many links in one action.

API patterns for compliance automation

Pull click data on your own schedule via the clicks endpoint and store it in your warehouse under your retention policy. Webhooks fire on link.create, link.update, and link.delete, useful for keeping an external inventory of what links exist and when they changed. See the webhooks doc for delivery and verification details, and the API guide for the larger pattern.