Security

Encryption at rest

Secret values are encrypted with AES-256-GCM before they’re stored - they’re never written in plaintext.

The encryption key comes from the SHIELD360_VAULT_ENCRYPTION_KEY environment variable. If that’s not set, Shield360 falls back to NEXTAUTH_SECRET.

Who can see a secret

Access to a secret depends on how it’s being accessed:

From the Vault page itself, secrets are per-user: only the person who created a secret can view, edit, or delete it there.
Via API key (SDK or REST calls, see Retrieve Secrets), access isn’t scoped to a single creator - any valid API key for your Shield360 instance can retrieve secrets by Key or Tag.

CORS for browser-based retrieval

CORS only matters if your application calls the secret-retrieval endpoint directly from browser JavaScript, from a different origin than your Shield360 instance. It does not apply to server-to-server SDK or REST calls, since CORS is a browser-only mechanism enforced through the Origin header - which server-to-server requests don’t send.

If you do need browser-based cross-origin retrieval:

Add your application’s origin to SHIELD360_ALLOWED_CORS_ORIGINS. Comma-separate multiple origins:
Terminal window
```
SHIELD360_ALLOWED_CORS_ORIGINS="https://app.example.com,https://admin.example.com"
```
Two other environment variables are also checked and merged into the same allow-list, so an origin listed in any of the three is allowed: SHIELD360_ALLOWED_ORIGINS and NEXTAUTH_URL.
Calls made from the exact same origin as your Shield360 instance are always allowed automatically, regardless of the allow-list.
Do not use wildcard origins for secret retrieval.