Securityat Fynlink

Customer email addresses and similar account data are stored using field-level encryption with a searchable ciphertext approach. The only other personal field we store is the name field, which is encrypted with AES-256-CBC.

Short URL targets, tags, notes, and related link metadata are encrypted in the browser before they reach our servers. By design, those values cannot be read by our employees from the application layer. Our architecture page explains the broader design that supports this model.

The database is designed so that raw database access alone has limited value: the sensitive link payload is stored in encrypted form, and the separate keys and browser-side context needed to interpret it are not stored alongside that data.

Analytics are anonymized. We do not store IP addresses in our analytics flow, and the data that is used for reporting is limited to operational attributes such as country, browser, and device data.

Our servers and databases are hosted in the EU, with most infrastructure located in Germany. We use Cloudflare for CDN and DDoS protection, which means redirect traffic is served from the nearest edge location available across Cloudflare’s global network.

We do not currently offer customer-selectable data residency controls or country-level storage restrictions. Customer data is stored and processed within our standard operating environment.

Sensitive account and payment-related data also lives with our service providers, including Stripe for payments.

Access to information systems that process customer data is restricted on a need-to-know basis. Internal access is limited, and administrative access is protected with mandatory multi-factor authentication and password manager use across the organization.

Role-based access control is enforced where practical across our internal systems and service providers so employees only reach the systems they need for their work.

We do not currently support customer-facing SSO through SAML or OAuth inside the product. MFA is supported for customer accounts, where we strongly recommend enabling it.

Customer data is not logically or physically segregated into dedicated per-customer infrastructure. Instead, link data is stored in a common database for ease of maintenance and operation, while the sensitive link payload remains end-to-end encrypted.

The operational data that must remain readable for the service to function, such as link IDs and timestamps, is stored alongside that encrypted data in the shared environment. That design keeps the platform manageable while still keeping the protected link content unreadable to us.

We do not currently publish a formal standalone SAST/DAST program or fixed public scan calendar. Our posture is to continuously monitor the platform, keep systems on auto-update paths, and perform periodic third-party security testing and internal review on relevant systems so findings are addressed as they arise.

Security of a short URL still relies on the person creating it. Our platform can encrypt the data, protect the infrastructure, and limit internal access, but it cannot undo a poor sharing decision or a link that is created without sufficient care.

The creator determines the destination, the lifetime of the link, whether it is private, and how guessable the slug is. Those choices directly affect the security of the resulting short URL, especially when the target contains sensitive, temporary, or regulated information.

For sensitive use cases, we recommend short expiration windows, random slugs instead of meaningful words, private links where appropriate, and a custom domain if you want to reduce exposure on the public default domain. Our shared responsibility page expands on the practical steps customers should follow.

We keep our servers on auto-update paths and continuously watch for threat signals and security issues. When vulnerabilities are identified, we prioritize remediation based on severity and exposure.

We have also performed third-party security testing and continue to monitor the platform internally so security gaps can be tightened as they are discovered.

We do not publish a fixed remediation SLA today, but urgent issues are handled immediately and lower-risk items are addressed as part of our ongoing maintenance cycle.

We take regular automatic backups as part of normal operations. Link data in those backups remains end-to-end encrypted, while only limited operational metadata such as link IDs, timestamps, and similar fields may remain in plain text to keep the system functioning.

In addition, we perform occasional manual offline device backups for extra caution and recovery resilience. Backup handling is intentionally conservative: we aim to keep restoration options available without increasing the amount of exposed data or introducing unnecessary copies.

Company devices are primarily Macs, kept current with the latest operating system updates. We use industry-standard endpoint protection tooling, including software from Objective-See and Malwarebytes, to reduce malware and host-level risk.

Our approach is simple: keep systems updated, keep device protection active, and reduce the number of places where sensitive data is exposed in the first place.

Security awareness is part of our operating rhythm. Employees are reminded about security obligations, privacy handling, and emerging threats multiple times a year.

We use a password manager, enforce MFA where possible, and keep access tightly scoped. The team is expected to treat security and privacy as part of normal operations, not as a separate layer added after the fact.