Secrets security and limits

Every secret read names a site, an optional app, a key, and a caller. TaruviBase uses these, together with the secret's sensitivity level, to find the secret and decide whether the caller can read its value.

Access model#

Read access depends on the caller, the endpoint, and the secret type's sensitivity level. The read endpoints do not all behave the same way, and they signal a denial differently — a single‑secret read returns a status code, while a batch read omits denied keys.

Who the caller is#

Unauthenticated — a request with no credential.
Site user — a user signed in to the site with a JWT or session; most application end users. See Authentication and authorization for how callers authenticate.
Cloud user or system token — a member of your organization, signed in with a JWT, a session, or their own API key, or code running in a Function through sdk_client, which uses a system token. A site user's API key still reads as a site user.

Single‑secret read — `GET /api/secrets/{key}/`#

Returns the value, or a status code on denial:

Caller	`public`	`private`	`sensitive`
Unauthenticated	`200` value	`401`	`401`
Site user	`200` value	`200` value	`403`
Cloud user or system token	`200` value	`200` value	`200` value

A tags filter that matches none of the secret's tags, or a missing key, returns 404.

Batch read — `GET /api/secrets/?keys=`#

Returns 200 with the secrets the caller may read; a key the caller may not read, or that does not exist, is omitted from the response rather than returning 403. An unauthenticated batch returns only public keys and omits the rest, and returns 401 only when none of the requested keys are readable. A site user receives public and private keys with sensitive keys omitted; a cloud user or system token receives every requested key that exists.

List — `GET /api/secrets/` (no `keys`)#

Requires authentication; an unauthenticated caller is rejected rather than served public values. A site user sees public and private secrets with sensitive excluded; a cloud user or system token sees all.

History — `GET /api/secrets/{key}/history/`#

Requires an organization owner or admin, or another member of your organization; site users get 403 for every secret's history.

An accepted credential does not by itself prove authorization. Confirm the allowed and denied cases for your caller and endpoint before you rely on private or sensitive access.

Write authorization#

You create, update, and delete secrets in TaruviBase Console; the SDKs are read-only. Organization owners and admins, and other members of your organization, can create, update, and delete secrets and secret types. Site users get 403.

App roles don't restrict who can manage secrets; organization membership does.

How values are resolved and cached#

Single and batch reads decrypt the value first, then check whether the caller may see it. If your own policy requires that a value is never decrypted before that check, don't rely on these reads.

Resolved values, including secret values, are cached for up to one hour. The cache is shared by all callers of the same site, scope, and key. Saving or deleting a secret clears the cache, but don't assume every permission change takes effect immediately.

Scope every operation#

In Console, the page you open sets the scope:

the site selected in Console;
site Secrets, or Operate → Secrets inside one app;
the key that names the secret;
the signed-in caller; and
the sensitivity level, inherited from the secret type.

A key locates a secret within its scope. Read access is decided separately from the key by the caller and the sensitivity level.

Encryption at rest#

The sensitivity level chosen on the secret type controls storage:

a public value is stored in a plaintext field;
a private or sensitive value is stored in an encrypted database field.

TaruviBase reads and writes the field that matches the type's sensitivity level and clears the other field on write. Because the level is fixed at type creation, a value's storage field does not change for the life of the type.

TaruviBase manages the encryption keys; you don't need to configure them.

Tenancy#

Secrets are stored per site. The request hostname selects the site, and a request resolves only secrets within that site. Do not treat possession of a key name as authority to read its value across scopes. Report any result that returns a secret from an unexpected site or app as a security issue.

Immutable and protected fields#

A secret type's sensitivity level cannot change after creation.
A secret type's classification (system or custom) cannot change after creation.
A system secret type cannot be deleted.
A secret type in use cannot be deleted until the secrets that reference it are removed.

Protect destructive changes#

Deleting a secret removes it from its scope.

Deleting a secret is permanent

Deletion removes the secret from its site or app scope. The value is not recorded in history, so it cannot be recovered from the audit trail after deletion.

Before you delete a secret:

Confirm the affected resource: the site, the app scope, and the exact key. Deleting a site secret affects every app that resolves that key; deleting an app secret affects only that app.
Treat the operation as irreversible; the value cannot be restored from history.
Only members of your organization can delete secrets, so make sure you are the right person to do it.
Record the current value in your own approved secret store first if you may need to restore it.
Confirm the key from the same site/app Secrets page, then choose Delete.
In Delete Secret, choose Delete, then use Refresh and verify the key is absent.
Recreate the secret from your own approved store if recovery is required; TaruviBase does not retain the deleted value.

Sensitive information#

Do not place credentials, personal data, or infrastructure details in URLs, examples, screenshots, or logs.

Console masks values in cards and detail views initially, but the detail dialog offers Show, Copy, and Copy all values, which reveal the real value. Check the site, app, and key first, avoid screen sharing, and never paste copied values into chat, tickets, or logs.

Limits#

TaruviBase applies these limits:

Limit	Value
Secret key	Up to 255 characters at the API schema and model layer; Console input is narrower
Secret-type name length	100 characters
Batch retrieval keys	100 per request
Secret list page size	Clamped to 100 maximum; 20 default
History page size	1–100, 10 default

A secret value has no separate size limit, but a request body larger than about 2.5 MB is rejected. Secrets has no specific rate limit. If a request is rejected for size or volume, reduce it and try again.

Keep in mind#

Never print secret values in logs.
Store credentials as secrets, not as ordinary site settings.
A deleted secret can't be recovered, so keep a copy of any value you may need.