Security

Credential boundaries, tenant authorization, webhook verification, and redaction rules for Social SDK applications.

Social SDK is a server-side library with explicit security boundaries. This page collects the rules that every integration shares; the linked guides cover each mechanism in depth.

Credentials stay on the server

Platform access tokens, managed-provider API keys, OAuth client secrets, refresh tokens, upload session URIs, and webhook secrets are server secrets. They must never reach a browser bundle, a client component, a public reference, a log line, or a fixture. A browser may send an authenticated request naming content and an application-owned account selection; it must never receive backend credentials or an unrestricted connected-account reference.

Two separate authorization questions

Application authentication answers who the caller is. Social-account authorization answers whether that caller’s tenant may use a specific connected account. The SDK’s references detect routing mistakes between backends and platforms, but the application must map the authenticated tenant to the selected account before every account-scoped operation. Never take an account ID from a request body without that check. See tenant authorization.

No implicit network activity

Importing the SDK performs no network request, telemetry, timer, queue, or background poll. Every external call is one your application makes explicitly, with a bounded retry budget and cancellation. Packed-consumer checks verify the zero-network-at-import behavior for every entrypoint.

Webhooks are verified before parsing

Provider events are verified against the untouched raw request bytes using the provider’s real mechanism: an HMAC-SHA256 signature for Zernio, a shared-secret header for Post for Me. Verification failures return before any parsing. Accepted events resolve every referenced account to authorized tenants; events with no common authorized tenant are quarantined rather than delivered. Payload tenant fields are never trusted. See events.

Errors are redacted

Structured errors never contain credentials, tokens, signatures, media bytes, message content, or private account data. Diagnostics are read-only by default and follow the same redaction rules. Report provider request identifiers and retry-after information instead of raw responses. See the errors reference.

Native access is explicitly unsafe

Typed native modules and social.native(backend, { acknowledgeUnsafe: true }) bypass the client’s tenant-authorization and concurrency middleware. Applications must wrap them in their own authorization policy. See native access.

Uncertain writes are never retried blindly

A lost response after a public write is an unknown outcome, not a failure. Retrying it without reconciliation can double-post. Preserve the delivery reference, reconcile explicitly, and reuse idempotency keys according to the documented policy. See idempotency and retries.