Information Security Policy

This policy describes the security controls FlowContent applies to protect customer data, partner data and the credentials entrusted to our platform. It covers our production backend, database, hosting infrastructure and all third-party integrations.

FlowContent is a small organisation. Our controls are implemented directly in the platform and enforced technically rather than through large-scale administrative processes. Every control described below is implemented in production today.

All production infrastructure is hosted within the European Union. Application servers are operated on dedicated hardware in Germany (Hetzner). Our managed PostgreSQL database is operated by Supabase. No production data is stored outside the EU.

In transit. All external traffic is served exclusively over HTTPS/TLS. Certificates are issued and automatically renewed via Let's Encrypt and terminated at our nginx reverse proxy. Plain HTTP is not served for application endpoints.

At rest. All third-party OAuth access tokens and refresh tokens are encrypted at the application layer before being written to the database, using AES-256-GCM with a unique random initialisation vector per encryption operation. AES-GCM provides authenticated encryption, so any tampering with stored ciphertext is detected on decryption. The master encryption key is supplied as an environment variable and is never stored in source code; the application refuses to start in production if the key is absent.

The managed database provides encryption at rest at the storage layer in addition to the application-layer encryption described above.

Tenant isolation. Row Level Security (RLS) is enabled on every table in the production database. Data access is scoped to the authenticated user at the database level, so a query cannot return another tenant's rows even in the event of an application-layer defect.

Authentication. API access requires a signed JSON Web Token, verified server-side on every request through a global authentication guard. Unauthenticated requests are rejected before reaching business logic.

Administrative access. Production servers are reachable only via SSH public-key authentication. Internal services (database, cache, workflow engine, integration gateway) are bound to the loopback interface and are not exposed to the public internet.

Credentials, API keys and client secrets are provided to the application exclusively through environment variables injected at container start. They are never committed to source control and never written to application logs. Error handling is written so that secrets and signature values are excluded from log output; diagnostic logs record header names only, never their values.

• Input validation: all incoming request payloads are validated against typed schemas before processing; unknown or malformed fields are rejected.
• HTTP security headers: enforced through helmet, including Content Security Policy.
• CORS: restricted to an explicit allow-list of our own origins.
• Webhook authenticity: inbound webhooks are rejected unless they carry a valid HMAC-SHA256 signature computed over the raw request body. Signatures are compared in constant time, and a five-minute timestamp window is enforced to prevent replay attacks. Requests without a signature are rejected.
• API request signing: all outbound partner API calls are signed with HMAC-SHA256 as specified by each platform.

Application workloads run in isolated Docker containers. Only the reverse proxy is exposed publicly; application containers listen on loopback-bound ports. Databases, cache and internal tooling are not routable from the internet.

Production changes are deployed through a controlled pipeline: static type checking and build verification run before any release. Deployments use a blue-green strategy — the new release is started alongside the current one and only receives traffic after passing a health check, allowing immediate rollback. A deployment lock prevents concurrent releases.

We request only the API scopes required to deliver the features our users have explicitly enabled. We do not collect, store or process partner platform data beyond what is necessary for the features of our application, and we do not sell or share this data with third parties.

Application errors and integration failures are logged centrally with structured logging and monitored. If a security incident affecting customer data were identified, our process is to (1) contain by revoking the affected credentials and disabling the affected integration, (2) assess the scope from application logs and database audit data, (3) notify affected customers and, where GDPR Article 33 applies, the competent supervisory authority within 72 hours, and (4) remediate the root cause before restoring the service.

Security concerns can be reported to support@flowcontent.io.

Our production subprocessors are Hetzner (infrastructure hosting, Germany) and Supabase (managed PostgreSQL). Access to third-party platforms on behalf of our users is always performed through official OAuth flows; we never ask users for, nor store, their platform passwords.