---
title: Security
description: 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](/concepts/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](/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](/reference/errors).

## 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](/concepts/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](/concepts/idempotency).