1. Security approach
PostBod applies layered controls across the web application, API, stored provider credentials, connected-account lifecycle, and operational configuration. Controls vary by deployment environment; production deployments require strong secrets, HTTPS callback URLs, managed infrastructure, monitoring, and provider-approved applications.
2. Identity and access
- Signed application sessions and authenticated API routes.
- Role-aware administration and tenant-aware workspace authorization.
- OAuth authorization state and provider callback validation for supported integrations.
- Scoped provider permissions and explicit account or page selection where supported.
- Credential refresh, identity verification, disconnection, and revocation flows.
3. Data protection
- Connected-service access and refresh tokens are stored as secrets and encrypted with AES-GCM when a production encryption key is configured.
- Production configuration requires dedicated secrets and HTTPS OAuth redirect URLs.
- Data is limited to the workspace and provider scopes needed for the requested workflow.
- Deleted workspaces remove associated stored connection secrets from active application data.
Transport encryption and infrastructure encryption depend on production hosting and database configuration and must be enabled by the deployment operator.
4. Application and API safeguards
- Request IDs support diagnostic traceability.
- API responses set content-type, framing, referrer, permissions, and HTTPS transport security headers.
- Request bodies are size-limited and APIs apply rate limiting.
- Billing and inbound integration webhooks use signature verification where supported.
- Error handling is designed to avoid exposing provider secrets in client-facing messages.
5. Social and storage integrations
Provider tokens remain on the server and are used only for authorized API operations. PostBod records permission and connection status, verifies identity where supported, refreshes expiring credentials, and requires reconnection when authorization cannot be refreshed. Platform restrictions still apply; for example, publishing and analytics capabilities may require provider review or specific account types.
6. Production operations
A secure production deployment requires secret management, database backups, restore testing, dependency patching, centralized monitoring, incident response ownership, least-privilege infrastructure access, environment separation, and regular access review. These are operational responsibilities shared by PostBod and the deployment operator until a managed production environment and assurance scope are formally documented.
7. Customer responsibilities
Use unique accounts, strong authentication, appropriate workspace roles, minimal provider permissions, and prompt offboarding. Review generated content and publishing destinations, secure devices, protect downloaded assets, and report suspicious activity. Do not place credentials, payment data, private keys, or unnecessary sensitive information in prompts or uploaded documents.
8. Report a vulnerability
Email security@postbod.app with the affected URL or feature, reproduction steps, impact, and safe supporting evidence. Do not access data that is not yours, degrade service, use social engineering, publish sensitive details before remediation, or perform destructive testing. We will acknowledge good-faith reports and coordinate next steps.
9. Assurance and status
PostBod does not currently represent on this page that it is SOC 2, ISO 27001, PCI DSS, HIPAA, or other independently certified or attested. If an audit, certification, penetration test, or formal assurance report is completed, its scope and date will be listed here. Payment-card processing, when enabled, is delegated to the configured payment provider rather than handled directly by PostBod.