Secure your data

Securing CloudBase PostgreSQL requires identity, permissions, network access, and secret management. Frontend access should rely on RLS, while server-side access should rely on least-privilege accounts and controlled APIs.

Access boundaries

Source	Recommended method	Security focus
Mini Program / Web frontend	SDK or HTTP API	Configure RLS to prevent unauthorized access
Cloud Functions / CloudBase Run	PostgreSQL direct connection or server SDK	Store secrets in environment variables and restrict database accounts
Administrators	DMC or console	Use separate accounts and avoid shared admin passwords
Third-party systems	HTTP API or backend proxy	Use short-lived tokens, signatures, or backend authentication

Frontend access and RLS

Frontend requests come from untrusted environments. Do not use table names, filters, or client parameters as authorization. Enable RLS on database tables and use auth.uid() to identify the current user.

alter table public.todos enable row level security;

create policy "Users can read own todos"
on public.todos
for select
to authenticated
using (user_id = (select auth.uid()));

For complete examples, see Basic permissions.

Server-side access

Server-side access is suitable for admin tasks, complex business rules, cross-user aggregation, and batch jobs. Servers can connect with database accounts, but those accounts must not be exposed to clients.

Create separate database accounts for services and grant only the required schema, table, and function permissions.

grant usage on schema public to app_server;
grant select, insert, update on public.orders to app_server;
grant usage, select on all sequences in schema public to app_server;

Secret management

• Store database passwords, AccessTokens, and private keys in environment variables or secret management systems.
• Do not commit .env files, connection strings, or console screenshots to the repository.
• Use different accounts and passwords for development, staging, and production.
• Rotate high-privilege passwords regularly and revoke accounts after personnel or permission changes.

SQL injection protection

Always use parameterized queries on the server. Do not concatenate user input into SQL.

await pool.query(
  "select id, title from public.todos where user_id = $1 and done = $2",
  [userId, false]
);

SQL identifiers such as table names and column names cannot be passed through normal placeholders. If dynamic identifiers are required, use an allowlist mapping.

Least privilege

In production, separate admin operations from business reads and writes. Business accounts should only keep required permissions to avoid accidental schema changes, deletes, or sensitive reads.

If you need to expose admin operations, wrap them in Cloud Functions or CloudBase Run and perform authentication, parameter validation, and audit logging on the server.

Launch checklist

• Frontend-accessible tables have RLS enabled.
• Policies cover expected select, insert, update, and delete behavior.
• Server-side connection information exists only in controlled environment variables.
• Database account permissions follow least privilege.
• Important writes have logs, backups, or rollback plans.