Sicherheit bei Lynqu

Wie wir dein Konto, deine Karte und die erfassten Kontakte schützen.

Zuletzt aktualisiert: 2026-07-28

Encryption

Every request to lynqu.com and to the Lynqu API is served over TLS only.

  • HTTPS everywhere. The site is served with HSTS including subdomains, with preload enabled — so compliant browsers refuse to connect over plain HTTP even on a first visit.
  • No cleartext traffic from the apps. The Android app disables cleartext traffic entirely and, in release builds, trusts only the system certificate store — a user-installed root certificate is ignored, so the usual intercepting-proxy setup cannot read app traffic. The iOS app runs under App Transport Security defaults, which require TLS 1.2 or better with no exemptions.
  • Credentials on the device. Access tokens and personal profile data held on a device are stored in the platform keystore — Keychain on iOS, EncryptedSharedPreferences on Android — never in plain application storage.
  • Credentials on the server. Third-party credentials Lynqu holds on your behalf — calendar, CRM, Slack and Teams OAuth tokens, and integration webhook secrets — are encrypted at the application layer before they are written, and are never returned by the API.
Access control and authentication

Authentication is token-based, with short-lived access tokens and refresh tokens issued by an OAuth 2.0 server.

  • Sign-in options. Email and password, or single sign-on with Apple, Google, or Microsoft. Enterprise plans support SAML SSO.
  • Biometric app lock. The mobile apps can require Face ID, Touch ID, or a fingerprint before the app opens, so a lost unlocked phone does not expose your contacts.
  • Rate limiting. Sign-in, registration, one-time-code and other sensitive endpoints carry their own rate limits, applied per account and per source address.
  • Anti-enumeration. Authentication endpoints return the same response whether or not an account exists, so the API cannot be used to discover which email addresses are registered. Password-reset requests always return success for the same reason.
  • Compromised devices. The apps detect jailbroken and rooted devices and warn the user once. Lynqu does not block those devices — the warning is informational.
Who can see your card

Every Lynqu card carries one of three privacy modes, chosen by its owner and enforced server-side on every request — not by hiding a link:

  • Public. Anyone with the link can view the card, and it may be listed for search engines.
  • Secure. Viewers must enter a passcode the owner sets before the card opens. Secure cards are never listed in the sitemap and are served with a no-index directive, so they do not enter search results.
  • Private. Only the owner and the people they have approved can view the card. Everyone else is refused, including signed-out visitors with the exact link, and the page is never indexed.

A card that is deactivated, locked, or not yet published returns 410 Gone rather than 404, so search engines drop the URL quickly instead of retrying it. Organization plans add field-level policies on top, so an administrator can control which lead fields each role is able to read or edit.

Uploads and file handling

Files uploaded to Lynqu — avatars, banners, documents, scan images — pass through a dedicated validation layer before they are stored.

  • Type validation. Both the declared MIME type and the file extension must appear on an allowlist. A mismatch is rejected.
  • Executable content scanning. Uploads are scanned for executable signatures and rejected if found, so a renamed binary cannot be stored as an image.
  • Filename sanitisation. Filenames are sanitised on write, so a crafted name cannot traverse directories or alter the stored path.
  • Private scan images. Source images from AI card and badge scanning are stored on a private disk that is not web-served. Clients receive short-lived signed URLs to view them; the signature is the authorisation.
AI features and your data

Lynqu uses AI for card and badge scanning, contact enrichment, and follow-up suggestions. Two commitments apply to all of them:

  • No training on your data. Scanning and vision features run on OpenAI models under a data processing agreement that prohibits training on customer data.
  • Enrichment is opt-in and reversible. Organization-level auto-enrichment is off by default and must be switched on by an administrator. Enriched values are presented for confirmation before they are written, and an individual can opt out of enrichment entirely at lynqu.com/privacy/enrichment-opt-out — which also adds them to a suppression list checked before any future write.
  • Outbound request safety. Enrichment only fetches over HTTPS, re-validates the destination on every redirect hop, and caps response size, so a malicious source cannot use it to reach internal infrastructure.
Payments

Lynqu never stores card numbers. Web payments are processed by Stripe, iOS purchases by Apple In-App Purchase, and Android purchases by Google Play Billing. Payment credentials are handled entirely by those processors and do not reach Lynqu's servers. Every purchase is verified server-side before entitlements are granted.

Application hardening

The web application ships a set of security response headers on every request:

  • Content Security Policy. Restricts where scripts, styles, and other resources may load from, and blocks plugin content.
  • Clickjacking and MIME protection. X-Content-Type-Options is set to nosniff so browsers cannot re-interpret a response's declared type, and X-Frame-Options is set to DENY on every page except the booking embed — the one surface designed to be placed in your own site's iframe. Your dashboard, your card pages, and the booking funnel itself cannot be framed by another site.
  • Referrer and permissions policy. Referrer information is trimmed on cross-origin navigation, and access to camera, microphone, and payment APIs is restricted at the browser level.
  • Input handling. Submitted content is sanitised of HTML before storage, and API routes use token authentication rather than cookie sessions.
Privacy and compliance

Lynqu is operated by Gravisun Soft Kft. (Budapest, Hungary; VAT HU26708375) and is built to comply with the GDPR, the CCPA/CPRA, and the UK Data Protection Act. You can export or delete your data from your account settings, and deletion cascades to the personal data Lynqu holds about the contacts you captured. If your organization needs a written data processing agreement, start at lynqu.com/legal/dpa.

Reporting a vulnerability

If you believe you have found a security issue in Lynqu, email support@lynqu.com with the details and steps to reproduce. Please give us a reasonable opportunity to investigate and fix the issue before disclosing it publicly. We do not currently operate a paid bug-bounty programme, but we will credit reporters who ask to be credited.