Security

Last updated: 2026-08-01How we protect accounts, data and infrastructure — and, just as plainly, what we do not protect and do not claim.

Security

This page describes the technical and organisational measures APERTURESyndicate OÜ uses to protect your account and your data. It is written to be accurate rather than impressive: it lists what we actually do today, and it names the limits of what we can promise.

If you have found a vulnerability, please read Security & Responsible Disclosure — it explains how to report it and what to expect from us.

Accounts and authentication

Passwords are never stored in a readable form. Every password is hashed with bcrypt (cost factor 12) before it is written to the database, and it is verified only by comparing hashes. Nobody at APERTURESyndicate — including administrators — can read your password. If you lose it, it can only be reset, never recovered.

One-time codes sent by email are hashed with argon2id, a memory-hard function, because short numeric codes would otherwise be quick to brute-force.

Two-factor authentication is available on every account and supports:

  • Passkeys (WebAuthn) — the strongest option; the private key never leaves your device and cannot be phished.
  • Authenticator apps (TOTP).
  • Email one-time codes.
  • Recovery codes, for the case where you lose access to the second factor.

Sessions are issued as short-lived access tokens plus a refresh token stored in an HttpOnly cookie, which JavaScript on the page cannot read. Signing out, changing your password or revoking a session invalidates the refresh token immediately across the platform, and every service checks revocation before honouring a token.

Data in transit

All traffic to aperturesyndicate.com and every sub-domain is served over HTTPS; plain HTTP is redirected. Traffic passes through Cloudflare, which provides TLS termination at the edge, DDoS mitigation and a web application firewall, and the connection from Cloudflare to our servers is encrypted as well.

Support requests are protected by TLS in transit and are readable by us — that is what makes it possible to answer them. They are stored in our database the same way as profile text or a post, and only the people handling support see them. We do not offer a private messaging channel between users, so there is no place on the platform where you should expect us to be unable to read what you wrote.

Encryption at rest — what is and is not encrypted

We do not claim blanket application-level encryption of all personal data, and you should be sceptical of any small company that does. What we actually do:

  • Specific high-risk secrets are encrypted with AES-256-GCM before they are written to the database — TOTP seeds for two-factor authentication, and the OAuth tokens for third-party connectors you attach to the AI assistant. If someone obtained a copy of those tables alone, they would not obtain working credentials.
  • Passwords and one-time codes are hashed, not encrypted, as described above — they are never recoverable, by anyone.
  • The rest of the database — profiles, messages, uploads metadata — is stored unencrypted at the application layer, protected instead by network isolation, access control and full-disk security of the host.

Databases, caches and the event bus run on a separate machine that is not reachable from the public internet — the firewall accepts database connections only from our application server's address. Uploaded files that are not meant to be public live in a private object-storage bucket and are served through short-lived signed links rather than public URLs.

Application secrets — signing keys, database credentials, third-party API keys — are held outside the source repository and injected into services at runtime.

Service isolation

The platform is split into separate services (authentication, profiles, access control, billing, chat, music and others). Each service can read only its own database schema and must ask another service over an authenticated internal channel for anything else. A weakness in one product therefore does not hand an attacker the whole database.

Access to administrative tooling is governed by role-based permissions and is additionally gated behind a passkey challenge that issues a separate, short-lived administrative token. To be precise about what this is not: the administrative interface is part of the main web application and is served from the same host and the same service as the rest of the site. It is protected by authorisation and step-up authentication, not by network separation or a distinct admin host. Every administrative action is written to an append-only audit log.

Abuse prevention

Sign-in, registration, password reset, uploads and API endpoints are rate-limited. Deletion in our systems is a soft delete: records are marked as deleted and disappear from the product, which lets us recover from mistaken or malicious deletion. Hard erasure on request is handled by a dedicated process — see GDPR & Your Data.

Backups

The database is backed up off-site to encrypted storage in the EU, with point-in-time recovery. A full backup is taken weekly and a differential backup daily, and the write-ahead log is shipped continuously, which means we can restore the database to any moment within the retention window rather than only to the time of the last backup. In practice the worst case is a few minutes of writes.

The backups are encrypted before they leave the server, with a key held separately from the storage that holds them. Whoever obtains a copy of the backup files without that key obtains nothing readable.

We keep the four most recent weekly full backups, so the window for restoring an earlier state is roughly one month. Older backups are removed automatically, along with the write-ahead log that belonged to them.

Restoration is tested, not assumed. A backup that has never been restored is not a backup, so we periodically restore into a throwaway environment and verify that the data actually arrives intact. The last verified restore was on 1 August 2026. We also run an automated daily check that the backup repository is reachable and that the write-ahead log is genuinely arriving — a silently broken backup chain would otherwise be discovered on the one day it matters.

What this does not cover: backups protect against loss, corruption and mistakes. They are not an undo button for you individually — deleting your own content is governed by Data Retention, and restoring the whole database to recover one person's deleted item is not something we will do.

What we do not claim

We are a two-person company and would rather be honest about the boundaries:

  • We do not currently hold ISO 27001, SOC 2 or comparable certification.
  • We do not operate a 24/7 security team. Reports and incidents are handled during working hours, as fast as two people can.
  • We do not claim to be unbreachable. No online service can.
  • Features still in development may not yet have the full set of protections described here; where that is the case, the product documentation says so.

If we ever suffer a personal-data breach that is likely to affect your rights, we will notify Andmekaitse Inspektsioon within 72 hours of becoming aware of it, and we will notify you directly where the law requires it.

Your part

The strongest account protection we can offer still depends on you: use a unique password, turn on two-factor authentication (a passkey if your device supports one), keep your recovery codes somewhere safe, and never share a one-time code with anyone — we will never ask you for one.

Contact

Security reports and questions: [email protected] (use the subject prefix "SECURITY" so it is triaged quickly).

Security | AS Docs