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.
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.
Each Security Level includes all features from the levels below it. Higher levels inherit and build upon previous security protections.
SF 0
SF 0
+ SF 1
+ SF 2
All previous
+ SF 3
All Features
+ SF 4
Security Level | Key Features | Best 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.
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.
Public data, proofs-of-concept, or any application where the data itself is not sensitive or personally identifiable.
No special code is required.
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);
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.
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.
All production applications. This is the essential first step to prevent stolen credentials from being used on other websites.
In the "API Keys" section of the Management UI, you can add restrictions for "Origins" or "IPs" or "Mode" when editing an API key.
No special code is needed in the SDK. The restrictions are enforced by the Vaultrice backend.
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');
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.
All multi-user applications. This is crucial to prevent one user from accessing another user's data, even if they are on your website.
In the "Classes" settings, enable "ID Signature Verification". You must configure the signature settings, which includes the public key and algorithm configuration.
Your client application must get a signature from your backend before initializing the SDK.
// 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');
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.
Applications storing sensitive but non-critical data that need an extra layer of server-side protection, such as user preferences or internal application state.
In your project's "Classes" settings within the Management UI, enable the "Additional At-Rest Encryption" checkbox for the desired class.
No code changes are needed in your SDK. The encryption and decryption are handled automatically and transparently on the server side.
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');
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.
Applications handling highly sensitive, private, or regulated data like private messages, financial data, or health information.
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.
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.
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 });
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.
Simplest setup. SDK manages tokens for you.
Secrets are present in client code.
import { NonLocalStorage } from '@vaultrice/sdk';
const nls = new NonLocalStorage({
projectId: 'your-project-id',
apiKey: 'your-api-key',
apiSecret: 'your-api-secret'
}, 'your-object-id');
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 };
}
import { NonLocalStorage } from '@vaultrice/sdk';
const { accessToken } = await fetchTokenFromMyBackend();
const nls = new NonLocalStorage({
projectId: 'your-project-id',
accessToken: accessToken
}, 'your-object-id');
The SDK notifies you before a token expires so you can fetch a new one and avoid interruptions.
nls.onAccessTokenExpiring(async () => {
console.log('Token is about to expire, fetching a new one...');
const { newAccessToken } = await fetchTokenFromMyBackend();
nls.useAccessToken(newAccessToken);
});
Option | Token Refresh | Secrets in Client? | Example Uses |
---|---|---|---|
apiKey + apiSecret | Automatic | Yes | Quick setup, prototypes, client-heavy apps with Origin Restriction |
Short-lived accessToken | Manual | No | Environments with a backend, maximum client-side secret protection |