SpiceDB 1.57

Apply these rules to self-hosted SpiceDB 1.57 authorization schemas, v1 API clients, server deployment, and optional embedded checks. Authenticate callers in the application and enforce each SpiceDB decision at the protected operation.

Service and client boundary

• Follow SpiceDB's latest official release for security fixes. Resolve the exact release from the official release index during deployment, verify official artifacts, and let an update process refresh any image digest; do not substitute a remembered version or weaken an existing constraint. Audit the client dependencies and the running SpiceDB binary separately.
• When building or embedding SpiceDB, check the tagged go.mod and build with a supported Go toolchain that has current security fixes. Distributed binaries carry their Go runtime; check client SDK runtime requirements independently.
• Keep gRPC, HTTP gateway, dispatch, metrics, and profiling listeners on trusted networks. Use TLS with verified peers, including dispatch and datastore connections, and do not expose an internal SpiceDB credential to a browser or mobile client.
• Supply unique, strong --grpc-preshared-key values through a secret manager or protected environment configuration. Rotate them deliberately and restrict who can read their source; a valid key authenticates a service, not an end user or a tenant.
• Put authenticated principal, method, tenant, resource, and rate-limit checks before every SpiceDB API call. Restrict schema writes, relationship mutation, bulk export, Watch, and diagnostic APIs to separate privileged service paths.