The latest articles on DEV Community by Erick Cruz (@leganux). https://dev.to/leganux https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4085876%2F59ec7363-8b1f-4124-8376-41f83b71d135.png https://dev.to/leganux en Erick Cruz Thu, 20 Aug 2026 03:38:58 +0000 https://dev.to/leganux/why-i-built-a-secret-injecting-proxy-in-nodejs-after-an-api-key-leak-spent-all-our-cloud-credits-11eh https://dev.to/leganux/why-i-built-a-secret-injecting-proxy-in-nodejs-after-an-api-key-leak-spent-all-our-cloud-credits-11eh <p>The Incident<br> It’s the classic startup nightmare: a .env file gets committed by accident, a scraper bot picks it up in under 30 seconds, and you wake up to depleted API credits and surprise cloud bills.</p> <p>After a credential leak burned our DeepSeek credits and threatened our AWS account, I realized that telling developers to "be more careful" is a broken security model. The real architectural fix is simple: Developers and client apps should never possess real production secrets in the first place.</p> <p>Introducing Llavero 🔑<br> To solve this, I built Llavero (Keyring in Spanish), an open-source Credential-Aware Reverse Proxy / Secret Injection Gateway built with Node.js 24, TypeScript, Fastify, and SQLite.</p> <p><code>Application<br> │ Authorization: Bearer llv_dev_xxx<br> ▼<br> Llavero ── validate token ── policy (deny-by-default) <br> │── decrypt credential in-memory (AES-256-GCM) ── apply auth driver<br> ▼<br> External API (OpenAI, Stripe, AWS...)</code></p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F9z37bf5sad4s4gyxye60.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F9z37bf5sad4s4gyxye60.png" alt="Architecture of llavero" width="800" height="533"></a></p> <p>Architecture Highlights<br> In-Memory Decryption: Secrets are encrypted at rest using AES-256-GCM. The master key lives strictly in memory (LLAVERO_MASTER_KEY).</p> <p>Deny-by-Default Policies: Clients must be explicitly granted permission for specific services, paths, and HTTP methods.</p> <p>Pluggable Auth Drivers: Handles complex authentication mechanisms like OAuth2 refresh token caching and AWS SigV4 request signing automatically.</p> <p>Streaming &amp; WebSocket Support: Native proxying for SSE (Server-Sent Events) and WS handshakes without buffering payload.</p> <p>Log Redaction &amp; SSRF Guard: Strict origin validation and automatic redaction of sensitive headers in Pino logs.</p> <p>Join the Project!<br> Llavero is fully open-source under the MIT license. I’m actively looking for feedback, security reviews, and contributions:</p> <p>GitHub: <a href="https://github.com/leganux/llavero-keychain" rel="noopener noreferrer">Go to REPO </a></p> <p>Needs: Security auditing, additional auth drivers, and HA storage adapters.</p> <p>Let me know what you think in the comments below!</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fk1vyhpy67dmt76nmk80y.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fk1vyhpy67dmt76nmk80y.png" alt="A storytime about it" width="800" height="1200"></a></p> selfhosted node security passwords