📚DocumentationSecurity Guide

Vaultrice Security Guide

An in-depth look at our layered security model, designed to give you the flexibility and control to match your application's specific security requirements.

A Layered Approach to Security

Security at Vaultrice is not a single feature but a series of layers you can apply to match your application's needs. Each level builds upon the last, allowing you to move from basic protection to maximum, end-to-end confidentiality. This approach ensures that you have the tools to secure your application, from simple projects to those handling highly sensitive information.

Explore the SDK authentication methods available for your application.

Security Levels at a Glance

Each Security Level includes all features from the levels below it. Higher levels inherit and build upon previous security protections.

Level 0 (starting from Free tier): Basic transport security - SF 0
Level 1 (starting from Startup tier): Client-side protection - SF 0 + SF 1 + SF 2
Level 2 (starting from Scale tier): Enhanced server-side encryption - All previous + SF 3
Level 3 (starting from Corporate tier): Maximum confidentiality - All Features + SF 4
Quick Reference
Click on any security feature in the table to jump directly to detailed explanations and code examples.
Security LevelKey FeaturesBest For
Level 0
🔒
Public data & prototypes
Level 1
🔑
✍️
Controlled access & internal apps
Level 2
🛡️
Enhanced server-side data protection
Level 3
🔐
Maximum confidentiality & sensitive data

This approach ensures that you have the tools to secure your application, from simple projects to those handling highly sensitive information.

Quick Reference
Click on any security feature above to learn more with detailed explanations and code examples.
SF 0

Transport + Default At-Rest Encryption

available on all plans

What It Is

All communication between your application and Vaultrice is encrypted in transit using TLS (HTTPS). Additionally, any data stored on the backend infrastructure is automatically encrypted at rest. This protects against network eavesdropping and provides baseline data protection.

Best For

Public data, proofs-of-concept, or any application where the data itself is not sensitive or personally identifiable.

Configuration

No configuration is needed. This security feature is always active.

Implementation

No special code is required.

NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

// Standard initialization provides SF 0 security by default.
// All communication is encrypted in transit (HTTPS)
// All stored data is encrypted at rest automatically
const nls = new NonLocalStorage({
  projectId: 'your-project-id',
  apiKey: 'your-api-key',
  apiSecret: 'your-api-secret'
}, 'my-public-object-id');

await nls.setItem('page_visits', 150);

Securing Client-Side Applications

Using the SDK or the API directly in the browser requires a careful security strategy. The following two security features work together to protect your application. API Key Restriction acts as a "perimeter defense" to protect your credentials, while Object ID Signature Verification provides "internal access control" to protect your users' data from each other.

SF 1

Restrict API Keys

Security Level 1 and higher

What It Is

Allows you to lock down an API key's permissions by IP address, browser origin (domain), or to read-only/write-only operations. This ensures that even if your API key is exposed, it can only be used from your application's domain.

Best For

All production applications. This is the essential first step to prevent stolen credentials from being used on other websites.

Configuration

In the "API Keys" section of the Management UI, you can add restrictions for "Origins" or "IPs" or "Mode" when editing an API key.

Implementation

No special code is needed in the SDK. The restrictions are enforced by the Vaultrice backend.

NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

// This API key has been restricted to "https://your-app.com" in the UI.
// Even if someone steals this key, they cannot use it from another domain.
const nls = new NonLocalStorage({
  projectId: 'your-project-id',
  apiKey: 'restricted-api-key', // Only works on your domain
  apiSecret: 'your-api-secret'
}, 'my-object-id');

// This request will be rejected if made from any other domain
await nls.setItem('user_data', 'secure');
SF 2

Object ID Signature Verification

Security Level 1 and higher

What It Is

Ensures your backend only interacts with data objects whose IDs have been authorized by your own server. Your server signs an objectId, and the Vaultrice API verifies this signature on every request. This prevents a malicious user on your website from guessing object IDs and accessing data they are not authorized for.

Best For

All multi-user applications. This is crucial to prevent one user from accessing another user's data, even if they are on your website.

Configuration

In the "Classes" settings, enable "ID Signature Verification". You must configure the signature settings, which includes the public key and algorithm configuration.

Implementation

Your client application must get a signature from your backend before initializing the SDK.

NonLocalStorage API
// On your trusted backend server
const objectId = 'user-profile-12345';
const keyVersion = 2;

// You implement this signing logic using your private key
const signature = signDataWithYourPrivateKey(objectId, keyVersion);

// Send the objectId, signature, and keyVersion to your client
return { objectId, signature, keyVersion };

// --- In Your Client-Side SDK ---
import { NonLocalStorage } from '@vaultrice/sdk';

// Get signature from your backend
const { objectId, signature, keyVersion } = await fetchSignatureForUser();

// Initialize the SDK with the signature from your backend
const nls = new NonLocalStorage(credentials, {
  id: objectId,
  idSignature: signature,
  idSignatureKeyVersion: keyVersion
});

// The Vaultrice API will now REJECT this request if the signature is invalid,
// even if the API key is correct.
await nls.setItem('username', 'Ada');
SF 3

Automatic At-Rest Encryption

Security Level 2 and higher

What It Is

An additional layer of server-side encryption. Data values are symmetrically encrypted on the Vaultrice server before being stored, preventing plaintext access in the database. This adds an extra layer of protection against a direct breach of the underlying database infrastructure.

Best For

Applications storing sensitive but non-critical data that need an extra layer of server-side protection, such as user preferences or internal application state.

Configuration

In your project's "Classes" settings within the Management UI, enable the "Additional At-Rest Encryption" checkbox for the desired class.

Implementation

No code changes are needed in your SDK. The encryption and decryption are handled automatically and transparently on the server side.

NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

// If SF 3 is enabled in the UI for the 'encrypted-user-data' class,
// data is automatically encrypted with an additional layer on the server.
const userPrefs = new NonLocalStorage(credentials, {
  id: 'user-preferences-123',
  class: 'encrypted-user-data' // The class configured for At-Rest Encryption
});

// This data is encrypted transparently - no changes to your code needed
await userPrefs.setItem('theme', 'dark');
await userPrefs.setItem('api_tokens', 'sensitive-token');
SF 4

End-to-End (E2EE) Encryption

Security Level 3

What It Is

The highest level of data confidentiality. Data is encrypted directly on the user's device using a passphrase and can never be read by the server. This is the highest level of confidentiality, ensuring that no one—not even Vaultrice—can read the content of your data.

Best For

Applications handling highly sensitive, private, or regulated data like private messages, financial data, or health information.

Configuration

In the "Classes" settings, you can define the e2ee salt length. This sets the default byte length for the salt used in key derivation. You can also trigger key rotation to force all connected clients to rotate their keys.

Implementation

Enable E2EE by providing a passphrase during SDK initialization. Before the first operation, call getEncryptionSettings(). The SDK fetches a unique salt from the server to derive the encryption key.

NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

const nls = new NonLocalStorage(credentials, {
  id: 'my-secret-journal',
  passphrase: 'a-very-strong-and-secret-passphrase'
});

// Fetch initial settings. This can override the default salt length.
// If saltLength is omitted, the project's configured e2eSaltLength is used.
await nls.getEncryptionSettings({ saltLength: 16 });

// This value is encrypted on YOUR device before being sent to Vaultrice.
// Even Vaultrice cannot decrypt this data without the passphrase.
await nls.setItem('diary_entry_1', 'This is a top secret message.');
await nls.setItem('financial_data', { account: '***', balance: 50000 });

SDK Authentication Methods

The Vaultrice SDK supports two flexible authentication methods to fit your application's architecture and security model.
Choose the method that matches your risk profile and infrastructure.

🔒

Direct Authentication

apiKey + apiSecret

Simplest setup. SDK manages tokens for you.
Secrets are present in client code.

NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

const nls = new NonLocalStorage({
  projectId: 'your-project-id',
  apiKey: 'your-api-key',
  apiSecret: 'your-api-secret'
}, 'your-object-id');
Tip: Use Origin Restriction (SF 1) for production!
Info: Token refresh is automatic—no manual handling required.
🔑

Short-Lived Access Token

No secrets in client

Backend generates a temporary token.
Maximum secret protection.

// Backend: Generate token
import { NonLocalStorage } from '@vaultrice/sdk';

async function generateTokenForClient() {
  const accessToken = await NonLocalStorage.retrieveAccessToken(
    'your-project-id',
    'your-api-key',
    'your-api-secret'
  );
  return { accessToken };
}
⬇️ Token is passed to the client ⬇️
NonLocalStorage API
import { NonLocalStorage } from '@vaultrice/sdk';

const { accessToken } = await fetchTokenFromMyBackend();

const nls = new NonLocalStorage({
  projectId: 'your-project-id',
  accessToken: accessToken
}, 'your-object-id');
Note: You must refresh tokens manually when they expire.

Handling Token Expiration

The SDK notifies you before a token expires so you can fetch a new one and avoid interruptions.

NonLocalStorage API
nls.onAccessTokenExpiring(async () => {
  console.log('Token is about to expire, fetching a new one...');
  const { newAccessToken } = await fetchTokenFromMyBackend();
  nls.useAccessToken(newAccessToken);
});

Choosing an Approach

OptionToken RefreshSecrets in Client?Example Uses
apiKey + apiSecretAutomaticYesQuick setup, prototypes, client-heavy apps with Origin Restriction
Short-lived accessTokenManualNoEnvironments with a backend, maximum client-side secret protection

Ready to Implement Security?

Choose the security level that matches your needs and start building with confidence.