Skip to main content
This page summarizes PostSider’s security posture for Cloud and self-hosted deployments. It links to the detailed pages below and to the repository’s security policy.

​
In this section

  • Authentication - sign-in methods (password, Google, GitHub, generic OIDC, wallet, Farcaster) and session model.
  • Data and retention - encryption at rest, media retention, and account deletion.
  • OAuth apps - issuing pos_... tokens to third-party applications.
  • Tenant isolation - how organizations stay separated.

​
Key facts

  • Passwords are hashed with bcrypt; sessions are stateless JWTs.
  • Provider credentials, webhook secrets, and API keys are encrypted at rest (AES-256-GCM, keyed by ENCRYPTION_KEY).
  • The application sets security headers (CSP, HSTS, nosniff) and relies on your reverse proxy for TLS. It deliberately does not set X-Frame-Options because the dashboard can be embedded.
  • Outbound webhooks are SSRF-protected and only delivered to public HTTPS endpoints.
  • The public API rate limits to 60 requests per minute per organization and uploads are validated and size-capped.

​
Reporting a vulnerability

PostSider takes security reports seriously. Report vulnerabilities privately to lukasz@postsider.com with the steps to reproduce; you can expect an acknowledgement within 72 hours and disclosure credit. The full policy lives in the repository’s SECURITY.md.

​
Self-hosted hardening

Operators are responsible for the deployment’s transport and network layer. The bundled Compose stack binds published ports to 127.0.0.1 only, so keep your host firewall closed to everything except SSH and the HTTPS port your reverse proxy uses. See the self-hosting and environment pages for the exact guidance.