Version 1.6.1+ | Production Ready | Unreal Engine 5.5+
Security best practices and patterns for production deployments with the Supabase UE5 Plugin.
This page covers security considerations for the Supabase UE5 Plugin, including API key management, key format handling, Row-Level Security (RLS), token security, input sanitization, and session protection.
Starting with v1.6.1, the plugin supports two generations of Supabase API key formats. Understanding how each format is handled is critical for secure deployments.
The original Supabase key format uses long JWT tokens (starting with eyJ...):
| Key | Dashboard Name | Use Case |
|---|---|---|
anon eyJ... |
Project API keys > anon public | Public read operations |
service_role eyJ... |
Project API keys > service_role | Admin/DDL operations (bypasses RLS) |
HTTP Headers -- Legacy JWT keys set both headers on every request:
apikey: eyJhbGciOiJIUzI1NiIs...
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Supabase introduced a new key format with clear separation between client and server credentials:
| Key | Prefix | Use Case |
|---|---|---|
| Publishable Key | sb_publishable_* |
Public operations (replaces legacy anon key) |
| Secret Key | sb_secret_* |
Admin/DDL operations (replaces legacy service_role key) |
HTTP Headers -- New-format keys set only the apikey header:
apikey: sb_publishable_a1b2c3d4...
No
Authorization: Bearerheader is sent forsb_*keys. The plugin detects the key format automatically and applies the correct header logic.
The plugin automatically detects the key format based on the key prefix:
| Detection | Format | Headers Set |
|---|---|---|
Key starts with eyJ |
Legacy JWT | apikey + Authorization: Bearer |
Key starts with sb_publishable_ |
New Publishable | apikey only |
Key starts with sb_secret_ |
New Secret | apikey only |
You do not need to configure header behavior manually -- the plugin handles this for all async operations (AsyncCreateTable, AsyncExecuteSQL, etc.).
Operations that require elevated permissions (DDL, raw SQL) use this fallback logic:
Security Note: If you only configure a
sb_publishable_*key, DDL operations likeCREATE TABLEmay succeed client-side but be rejected by Supabase with a permissions error. Always configure aSecretKeyorServiceKeyfor DDL operations.
struct FSupabaseCredentials
{
FString AnonymousKey; // Legacy anon key (JWT)
FString UserAuthenticatedKey; // User-specific JWT (from login)
FString ServiceKey; // Legacy service_role key (JWT)
FString PublishableKey; // New: sb_publishable_* (v1.6.1+)
FString SecretKey; // New: sb_secret_* (v1.6.1+)
};
sb_publishable_*) for all client-side operations -- They are designed for untrusted environments.sb_publishable_* / sb_secret_* format provides clearer separation between client and server credentials.When rotating keys in the Supabase dashboard:
DefaultEngine.ini or runtime configurationPublishableKey and/or SecretKey fieldsComing soon. This section will provide detailed information about row-level security including code examples, configuration options, and best practices.
Coming soon. This section will provide detailed information about token security including code examples, configuration options, and best practices.
Coming soon. This section will provide detailed information about input sanitization including code examples, configuration options, and best practices.
Coming soon. This section will provide detailed information about ssl/tls configuration including code examples, configuration options, and best practices.
Coming soon. This section will provide detailed information about session protection including code examples, configuration options, and best practices.
This documentation is under active development. Join our Discord community for the latest updates and to ask questions.