We release patches for security vulnerabilities. The following versions are currently supported:

We recommend always using the latest release for security patches and improvements.

We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.

1. Do NOT create a public GitHub issue for security vulnerabilities
2. Email the maintainer directly at: openpost+security@rgo.pt
3. Include in your report:
   • Description of the vulnerability
   • Steps to reproduce the issue
   • Potential impact
   • Any suggested fixes (optional)

• Acknowledgment: We will acknowledge your report within 48 hours
• Status Update: We will provide regular updates on the progress of addressing the vulnerability
• Disclosure: We will publicly disclose the vulnerability after a fix is available
• Credit: We will credit reporters in the security advisory (unless you prefer to remain anonymous)

• Initial response: Within 48 hours
• Severity assessment: Within 7 days
• Fix development: Varies by complexity (typically 1-4 weeks)
• Public disclosure: After patch is available

When running OpenPost, follow these security practices:

• Never commit .env files to version control
• Use strong, randomly generated secrets (openssl rand -base64 32)
• Rotate secrets periodically
• Use Docker secrets, Kubernetes secrets, or a secrets manager in production
• Restrict access to OPENPOST_ENCRYPTION_KEY: encrypted provider tokens still depend on that key to be decrypted
• Limit read access to the OpenPost runtime user for .env, backup archives, and service configuration files

• Run behind a reverse proxy with TLS/HTTPS
• Configure a proper firewall
• Don't expose the OpenPost port directly to the internet (except for OAuth callbacks)
• For Threads: ensure /media/ endpoint is publicly accessible for media uploads
• Use HTTPS before configuring production OAuth callbacks for X, Mastodon, LinkedIn, or Threads

• Back up your database and media directory regularly
• Back up your .env or secret-management configuration together with the database and media directory
• Store backups in a secure location
• Consider encrypting backups at rest
• Restrict filesystem permissions on the SQLite database, media folder, and backup artifacts

• Regularly review connected accounts
• Rotate OAuth tokens and secrets periodically
• Revoke access for accounts no longer in use

OpenPost includes the following security measures:

• Token encryption: All OAuth tokens are encrypted at rest using AES-256-GCM
• Password hashing: User passwords are hashed with bcrypt
• JWT authentication: Secure token-based session management
• Account MFA: TOTP enrollment and verification for user accounts
• Passkeys: WebAuthn passkey registration and login support
• OAuth PKCE: Twitter authentication uses PKCE for improved security
• No external dependencies: Self-contained binary with no external service dependencies

We regularly update dependencies to address security vulnerabilities. We use:

• Go dependencies (via Go modules)
• Frontend dependencies (via Bun/npm)
• Docker base images from trusted sources

This security policy applies to:

• The OpenPost server application
• The embedded SvelteKit frontend
• OAuth integration with supported platforms

This does not apply to:

• Third-party OAuth providers (Twitter, Mastodon, Bluesky, LinkedIn, Threads)
• Your deployment infrastructure (reverse proxy, firewall, etc.)
• External databases or storage systems you configure