Protect credentials, tokens, keys, and media
Apply secure defaults to OAuth credentials, API keys, webhooks, uploads, logs, and tenant boundaries.
Keep provider tokens and customer OAuth secrets inside App9 Post, keep App9 API keys server-side, verify signed webhooks, validate media signatures and remote URLs, and enforce brand isolation on every resource. Public clients should receive sanitized resources and short-lived delegated access only.
What this means in practice
Keep provider tokens and customer OAuth secrets inside App9 Post, keep App9 API keys server-side, verify signed webhooks, validate media signatures and remote URLs, and enforce brand isolation on every resource. Public clients should receive sanitized resources and short-lived delegated access only.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Use protected provider-app management for customer-provided credentials.
Store raw App9 Post API keys once and rotate them by workload.
Redact secrets from responses, events, webhooks, traces, and audit metadata.
Validate media bytes, MIME, dimensions, duration, redirects, and network destinations.
Test cross-brand access attempts and fail closed when encryption or auth configuration is unavailable.
Operational details
Sanitized OAuth account records can include status, display name, capabilities, and token expiry without token values.
Webhook signing and event deduplication solve different security and reliability problems.
Least privilege applies to people, API keys, delegated tokens, and provider scopes.
Common mistakes to avoid
- Do not return provider access or refresh tokens through REST, SDK, MCP, logs, or webhooks.
- Do not fetch arbitrary remote URLs from private networks.
- Do not store plaintext credentials when encryption configuration is missing.