Trust

Security

A Page token is the key to a business’s audience. Here is exactly how we look after yours — in enough detail that a reviewer at Meta or Google, or your own IT person, can check it.

Last updated 21 October 2026 · Questions or reports: [email protected]

1. Encryption at rest

  • Every secret the service holds — Facebook Page tokens, Google OAuth tokens, X keys, your own OpenRouter key, Telegram bot tokens, platform credentials — is encrypted with AES-256-GCM before it is written to the database. Each value gets its own random nonce and an authentication tag, so a tampered record fails to decrypt.
  • The encryption key is a 32-byte random key kept in a file on the server with owner-only permissions, outside the database and outside backups of the database. A copy of the database alone cannot reveal a token.
  • Secrets are never sent back to a browser. The app shows only that a secret is set and its last four characters.
  • API keys for AI clients and session tokens are not stored at all — only a SHA-256 hash of them (section 5).

2. Encryption in transit

  • All traffic to https://smm.flowmind.digital uses HTTPS (TLS 1.2+) with HSTS enabled; plain HTTP is not served.
  • Calls to Meta, Google, X, OpenRouter, Stripe, Resend and Telegram are made over HTTPS from the server; browsers never hold platform tokens.
  • Responses carry a strict Content-Security-Policy (scripts only from our own origin, no inline scripts, framing denied), X-Content-Type-Options: nosniff, a strict referrer policy and a restrictive permissions policy.

3. Accounts and sessions

  • Passwords are hashed with scrypt and a per-user salt; we never see or store the password itself. Sign-in attempts are throttled per account and per IP address.
  • Email verification, password-reset and invitation links use single-use random tokens that expire.
  • Sessions are random tokens stored hashed, delivered in an HttpOnly, SameSite=Lax cookie with the __Host- prefix over HTTPS, valid for 30 days. Changing your password or resetting it signs out every other session.
  • Every state-changing request must come from the app’s own origin (an Origin check on top of SameSite cookies), which blocks cross-site request forgery.

4. Roles and least privilege

  • A workspace owner has every permission. Everyone else acts through a role — Admin, Manager, VA, Viewer, or a custom role — which is an explicit list of permissions: view content, plan and publish, act in the inbox, change assistant settings, connect accounts, manage the team, manage roles, manage billing, change workspace settings, manage API keys, view the activity log.
  • A member can only grant permissions they hold themselves, so nobody can escalate by inviting a colleague.
  • Every API route checks the permission it needs server-side; the interface only hides what you cannot do, the server enforces it.
  • Platform credentials (our Meta app, Google client, OpenRouter key, Stripe keys) are held by the platform operator only; customers never see or handle them.

5. API-key scopes

  • API keys (fms_…) are generated from 24 random bytes and shown once. We store only a SHA-256 hash and the first characters as a label.
  • Each key has a scope: read (look at pages, content, comments, chats, knowledge; try a reply without posting) or act (also publish, send replies and messages, approve drafts, change knowledge). Read keys cannot see or call act tools.
  • Each key is limited to the pages you choose, or to the whole workspace. A key cannot reach another page, another workspace, your team, billing or settings.
  • Keys are rate-limited per minute, more tightly for actions than for reads, and can be revoked in one click. Every call is logged under the key’s name (section 6).
  • A reply sent through a key passes the same guard as the assistant’s own replies: anything that would leak a link, phone number, email address, device or the names of the people behind the page is refused.

6. Activity log

Each workspace has an append-only activity log: sign-ins, posts created, published or deleted, replies and messages sent (by a person, by the assistant or through an API key — labelled “MCP · key name”), roles and members changed, API keys created or revoked, payments, settings changes. Each entry records who, what, when and from which IP address. Members with the activity.view permission can read and search it.

7. Platform integrations

  • We request the minimum Facebook permissions and Google scopes for the features you use; each is listed with its purpose in the privacy policy.
  • Webhooks from Meta are verified with the app secret signature; Facebook data-deletion callbacks are verified as signed requests; Stripe webhooks are verified with Stripe’s signing secret and a timestamp window. Unsigned or stale calls are rejected.
  • OAuth callbacks are fixed, registered URLs, and connection flows carry a state token bound to your session.
  • Disconnecting a page deletes its token immediately; you can also revoke access from Facebook or Google at any time.

8. AI processing

Model requests leave the server with only the text needed to answer: the comment or message, the post, the matching knowledge passages and your instructions. They never include tokens, email addresses, payment data or account identifiers. Requests go through OpenRouter to the model provider over HTTPS; we do not train models on your data. Details are in the privacy policy.

9. Backups and deletion

  • The database and uploaded media are backed up regularly. Backups are encrypted, stored separately from the server and rotated within 30 days; the token-encryption key is not stored with them.
  • When you disconnect an account, delete a page, a workspace or your account, the data is removed from the live system immediately and leaves the backups on the 30-day rotation.
  • Uploaded files are stored per workspace and per page on the server; every file path is checked to stay inside its page’s folder before it is read or written.

10. Incident handling

  • If we find or are told about a security incident, we contain it first (revoke affected sessions, keys or tokens, block the vector), then assess what data was involved.
  • We notify the owners of affected workspaces by email without undue delay and within 72 hours of confirming a breach of personal data, with what happened, what was affected, what we did and what you should do (for example, reconnecting a page).
  • Where a platform requires it (Meta and Google both do), we also notify them.
  • We keep an internal record of incidents and publish a post-mortem for anything that affected customers.

11. Responsible disclosure

If you have found a vulnerability in Flowmind Social, please tell us before anyone else: email [email protected] with the subject “Security report”, the steps to reproduce it and, if you like, a way to credit you.

  • We acknowledge reports within 2 working days, keep you informed, and aim to fix confirmed issues quickly — critical ones within days.
  • Please test only against your own workspace and accounts, do not access or modify other people’s data, do not run denial-of-service tests, and give us reasonable time to fix the issue before disclosing it.
  • We will not take legal action against researchers who follow these rules in good faith. We do not run a paid bounty programme at this time, but we credit researchers who want it and send a thank-you.