Security

Security, in the database and around it.

Access rules enforced by PostgreSQL, separate keys for separate powers, multi-factor sign-in and limits on every service.

Six pillars

How we protect your production.

Data access

Row-level security in the database

Access rules live next to your data as PostgreSQL policies that use auth.uid(). The database enforces them, not the client.

API keys

Separate keys for separate powers

A public key for your apps and a service role key for your servers. Sensitive operations, like raw SQL, are reserved to the service role.

Sign-in

Multi-factor and revocable sessions

TOTP multi-factor with recovery codes, sessions you can list and revoke, and captcha on sign-up.

Abuse

Rate limits and quotas

Every plan has per-minute rate limits and monthly quotas, enforced by the platform on each service.

Isolation

Dedicated clusters

Enterprise projects run on dedicated PostgreSQL clusters, separate from other organizations.

Hosting

Data hosted in the EU

Our infrastructure is hosted in Germany and Finland.

Further reading

Everything your security team needs.

Trust

Trust Center

What we have, and what we don’t yet, stated plainly.

Operations

Status

Follow the health of the platform and its services.

Questions

Good to know.

How do I report a vulnerability?+
Email security@aurabase.cloud. The same contact is published in our security.txt file. Please give us a reasonable chance to fix an issue before you disclose it.
Does Aurabase hold third-party security certifications?+
Not today. The Trust Center lists our current status openly, so you can weigh it against your requirements.
Where is my data hosted?+
In the European Union, on infrastructure located in Germany and Finland.
Can users bypass row-level security from the client?+
No. Policies run inside PostgreSQL for every request made with a user’s token, whatever the client sends.

Have a security question?

Let’s discuss it before it becomes critical.

Write to our security contact or read the Trust Center.