AES-256 Encryption for API Keys: Why We Don't Trust Client-Side Storage

TL;DR: Storing high-privilege LLM API keys in browser local storage or as plaintext in a database is a massive security vulnerability. Frugal secures user API keys by encrypting them at rest using server-side AES-256-GCM, ensuring that even in the event of a database breach, attackers cannot access the raw credentials.

What Is AES-256 Encryption for API Keys?

AES-256 (Advanced Encryption Standard with a 256-bit key) is a military-grade symmetric encryption algorithm used to scramble plaintext API keys into unreadable ciphertext before storing them in a database, requiring a secret master key to decrypt them back into a usable format.

Why It Matters

If you build an AI application and store user OpenAI keys as plaintext strings in your Postgres database, a single SQL injection vulnerability or leaked database backup will expose every single key to attackers. Since these keys are often tied to credit cards with limits in the tens of thousands of dollars, the resulting liability for your startup would be catastrophic. Proper encryption at rest is not just a best practice — it is an existential requirement.

How It Works

The LocalStorage Fallacy

Many lightweight AI tools ask users to paste their key, which is then saved in the browser's localStorage. This is highly vulnerable to Cross-Site Scripting (XSS) attacks. If a malicious script runs on that page, it can scrape localStorageand silently exfiltrate the keys to an attacker's server.

Server-Side AES-256-GCM

In Frugal, when a user provides an API key, it is immediately sent to a secure backend endpoint via HTTPS. The server generates a unique Initialization Vector (IV) and encrypts the key using crypto.createCipheriv with a 256-bit ENCRYPTION_SECRETstored purely in the server's environment variables. The resulting ciphertext, the IV, and the auth tag are stored in the database. The plaintext key is immediately purged from memory.

The Decryption Phase

When the Frugal polling worker runs, it retrieves the ciphertext from the database. The worker uses the master ENCRYPTION_SECRET to decrypt the key into memory just long enough to authenticate the request to OpenAI or Anthropic, before destroying it again.

Practical Steps for Securing Keys

1. Never Trust the Client: Avoid localStorage for anything more sensitive than a UI theme preference.
2. Use GCM Mode: Always use authenticated encryption modes like AES-256-GCM. GCM provides an authentication tag that prevents tampering with the encrypted payload.
3. Separate Secrets: Keep your database credentials and your ENCRYPTION_SECRET completely isolated. If the database is breached, the ciphertext remains secure unless the application environment variables are also compromised.

Common Mistakes

The most egregious mistake engineers make is attempting to “hash” API keys like passwords using bcrypt. Hashing is a one-way function. If you hash an API key, you can verify it, but you can never reconstruct the original text to actually send a request to OpenAI. You must use two-way symmetric encryption.

FAQ

What is AES-256 encryption?

AES-256 is a symmetric encryption standard that uses a 256-bit key to lock and unlock data. It is currently approved by the NSA for top-secret information.

Why shouldn't I store API keys in browser local storage?

Local storage is directly accessible by JavaScript. If your website suffers an XSS attack, a malicious script can easily read and steal the stored API keys.

Why can't we hash API keys like we do passwords?

Because hashing is irreversible. You need the plaintext key to make authenticated requests to third-party providers. Encryption is reversible; hashing is not.

What is an Initialization Vector (IV) in encryption?

An IV is a random string added to the encryption process to ensure that even if you encrypt the exact same API key twice, the resulting ciphertexts look completely different, preventing pattern analysis.

Does Frugal store my OpenAI key in plaintext?

No. Frugal encrypts all API keys using AES-256-GCM before they are written to the database. The keys are only decrypted ephemerally in server memory during polling jobs.

Conclusion

Handling third-party API keys is a massive responsibility. By moving storage away from the vulnerable client side and implementing strict, authenticated AES-256 encryption at rest, you create a defense-in-depth architecture that protects your users even if your primary database is compromised.