1. Our approach
Postalu holds the keys to your social accounts, so security is designed in from the start: least privilege, encryption of secrets, mandatory two-factor sign-in, and an audit trail. This page describes the controls in place and how to report a problem. It complements the Privacy Policy.
2. Security controls
| Area | What we do |
|---|---|
| Authentication | Passwords are stored only as Argon2id hashes. Two-factor sign-in (TOTP) is required for every user. Recovery codes are stored hashed and are single use. Sessions are random, HTTP-only, SameSite cookies that can be revoked, and expire automatically. |
| Authorisation | Role- and permission-based access, enforced on the server for every action. Users can only grant permissions they hold themselves, and the last user manager cannot be removed or disabled. The Admin role requires every permission, and plan and billing changes are limited to Admins. |
| Platform tokens | Access and refresh tokens are encrypted with AES-256-GCM, bound to the account they belong to, with versioned keys so they can be rotated. They are used only by our servers and never sent to browsers. Alert-channel secrets (Slack and Teams webhook addresses) are encrypted the same way and never shown again. |
| Data in transit | HTTPS everywhere through an AWS load balancer with a managed certificate (TLS 1.2 or newer; plain HTTP is redirected). The application runs in private subnets with no public address and accepts traffic only from the load balancer. |
| Media storage | A private Amazon S3 bucket with public access blocked and a separate folder for each account, so one customer's files cannot be read or referenced by another. Uploads use short-lived, single-file signed links issued after a permission check, with size and type validation. Media is removed automatically once the post is live, and anything left behind expires. |
| Application hardening | A strict Content Security Policy with per-request nonces, clickjacking protection, origin checks on state-changing requests, input validation, rate limiting on sign-in and sensitive actions, and generic error messages that do not leak internals. |
| Infrastructure | Defined as code (Terraform), deployed through a controlled pipeline from tagged releases to containers with no interactive server access. Application credentials have least-privilege IAM access; secrets live in encrypted parameter storage, not source code. |
| Staff access | Postalu staff use a separate console that customers cannot reach, sign in with two-factor authentication, and must re-enter their password and a code for sensitive changes. Staff accounts are either read-only or managers: only managers can change a customer's plan or access, reset an authenticator, pause a platform or manage the team. Their actions are written to an audit log, and they cannot read passwords or platform tokens. |
| Backups | The database is backed up to a private, encrypted bucket that is separate from customer media. Backups can be started only by authorised staff after re-authentication, are never downloadable through the application, and expire automatically. |
| Payments | Card payments are handled entirely by Paddle, our merchant of record. Card details never reach Postalu's systems. |
| Monitoring and logging | An audit log of security-relevant events, operational logs with secrets kept out, and optional alerts to Slack, Microsoft Teams or email for failed posts and outages. |
| Dependencies and code | Automated tests and build checks on every change, and dependency updates applied as vulnerabilities are identified. |
3. What you can do
- Keep your password, authenticator device and recovery codes private; never share an account.
- Give team members the narrowest role they need, and disable or delete people who leave.
- Review connected accounts regularly and disconnect any you no longer use; revoke access on the platform if you suspect misuse.
- Watch for phishing: we will never ask for your password or authentication code by email or message.
4. Reporting a vulnerability
If you believe you have found a security weakness in Postalu, please tell us before disclosing it publicly:
- Email legal@postalu.com with the subject “Security report”.
- Describe the issue, the steps to reproduce it, and its impact. Proof-of-concept details help; please do not include other people's data.
- Give us a reasonable time to investigate and fix it (we aim to acknowledge within 3 business days and to keep you updated) before sharing details publicly.
Safe harbour. If you act in good faith, follow this policy, avoid privacy violations, data destruction and service disruption, and only test accounts you own, we will not pursue legal action against you or ask platforms to do so. This is not a licence to attack third-party systems (Meta, Google, TikTok, X, LinkedIn or AWS), which have their own programmes.
Out of scope: denial-of-service or volumetric testing, social engineering of staff or users, physical attacks, automated scanner output without a demonstrated impact, and missing best-practice headers with no exploit path. We do not currently run a paid bounty, but we are happy to credit researchers who want it.
5. If something goes wrong
If we confirm a security incident that affects your information, we will contain it, investigate, and notify affected operators without undue delay, with what happened, what data was involved and what to do next, and we will notify authorities where the law requires. Details of processor commitments are in our Data Processing terms.
Last updated October 12, 2026 · Version 1.2
