Security at PlanSend

Our approach

PlanSend holds the keys to its customers' social accounts, so security is a design constraint rather than a feature. We keep the system small, store as little as we can, encrypt what we must store, and check every request against the workspace it belongs to. This page describes what is in place today; we update it as the service changes.

Encryption

• In transit. All traffic to plansend.io uses TLS. Plain HTTP requests are redirected to HTTPS and browsers are instructed to use HTTPS only.
• Channel tokens at rest. Access tokens for connected social accounts are encrypted with AES-256-GCM before they are written to the database. The encryption key lives in the application's environment, separate from the database and its backups, so a copy of the database alone cannot reveal a token.
• Secrets. API keys and review-link tokens are stored only as SHA-256 hashes, and review passcodes as scrypt hashes. Raw values are shown once and never stored.
• Backups and storage. Database backups and uploaded media are encrypted at rest by DigitalOcean.

Sign-in and sessions

• PlanSend uses Google sign-in only. There are no PlanSend passwords to leak, phish or reset, and we ask Google only for your email, name and avatar.
• Google must report the email as verified; unverified identities are rejected, and a new Google identity can never silently take over an existing account with the same email.
• Sessions are stored server-side and referenced by an HttpOnly, SameSite cookie that is regenerated at sign-in and expires after 14 days.
• Every form and state-changing request is protected against cross-site request forgery, and security headers including a Content Security Policy are set on every response.

Workspace isolation

Every workspace is a separate tenant. Every database read and write is scoped to the workspace of the signed-in member or API key, so a post, channel or job from another workspace returns "not found" rather than being disclosed. Roles (owner, editor, reviewer) are enforced on the server, not only in the interface. API keys belong to one workspace and carry a read, write or admin scope that the server checks on every call. The web app, the REST API and the MCP endpoint share one service layer, so the same rules apply everywhere.

Review links

Public review links use long random tokens that are hashed before storage, expire automatically and can be revoked at any time. You can add a passcode so the post content is not shown until it is entered. Review pages are marked noindex and never load analytics. Editing a post revokes its outstanding review links, so a reviewer always sees the exact revision they are approving.

Audit logs

Every meaningful action in a workspace (creating and editing posts, requesting review, approvals, scheduling, API key creation, settings changes and sign-ins) is written to an audit log with the actor, time and details. Publishing jobs keep their own history, including retries and the receipt returned by each network, so a team can trace what was published, when and by whom.

Infrastructure and backups

• PlanSend is hosted in the European Union (Germany). The database, file storage and backups stay in the European Union.
• The database is not exposed to the public internet; only the application and the publishing worker connect to it, over TLS.
• Daily automated backups are kept in the EU and rotate within 30 days.
• Access to production follows least privilege: only the people who operate the service have access, through individual accounts, and secrets are stored in the platform's encrypted configuration rather than in code.
• Dependencies are locked and checked for known vulnerabilities before each release.

Payments

Payments are handled by Stripe, a PCI DSS Level 1 service provider. Card details are entered on Stripe-hosted pages and never touch PlanSend servers; we store only the Stripe customer id, plan and invoice status. Stripe webhooks are signature-verified and deduplicated before they change any subscription state.

Certifications

PlanSend is a small company. We do not yet hold SOC 2, ISO 27001 or similar certifications, and we will not claim them until an independent auditor has confirmed them. What we can offer today is the transparency on this page, a data processing agreement on request, and direct access to the people who build the product.

Responsible disclosure

If you believe you have found a security vulnerability in PlanSend, please email [email protected]. Include the steps to reproduce the issue, the URL or component affected and, if you have one, a proof of concept. We acknowledge reports within 3 working days, keep you informed while we fix the issue, and credit you if you would like. Please give us reasonable time to fix a problem before publishing it, avoid accessing or changing other people's data, and do not run denial-of-service tests. We will not take legal action against researchers who follow these guidelines. We do not currently run a paid bug bounty programme.