Managing Secrets and API Keys Safely in Blanca's Builder

Blanca's Builder prioritizes the security of your confidential credentials. All sensitive information, including API keys, database connection strings, and other environment variables considered "secrets," is stored exclusively in server-side environments. This critical distinction means that your secrets are never exposed to client-side code, user browsers, or publicly accessible repositories.

We strictly adhere to the principle of least privilege and isolation. When you integrate third-party services or custom logic requiring API access, all associated keys are processed and utilized within our secure backend infrastructure. This architecture prevents accidental exposure and minimizes the attack surface, ensuring that even if your frontend application were compromised, your backend secrets would remain protected.

During development and deployment, you might encounter variables prefixed with `VITE_`. It is crucial to understand that any variable beginning with `VITE_` is considered public and will be embedded directly into your frontend build. This makes them accessible to anyone inspecting your website's source code or network requests. Therefore, you must never store sensitive API keys, tokens, or any other secrets in `VITE_` prefixed variables.

The `VITE_` prefix is intended for non-sensitive configuration settings, such as public API endpoints, feature flags, or application version numbers. For example, a `VITE_PUBLIC_MAPBOX_TOKEN` (provided it's a publishable token with strict domain restrictions) could be acceptable if its exposure doesn't pose a security risk. However, for any key that grants significant access or has payment capabilities, server-side storage is the only secure option.

For customers requiring an additional layer of security and control, Blanca's Builder supports Bring Your Own Key (BYOK) encryption. This advanced feature allows you to provide your own encryption key to further protect your data. When BYOK is enabled, your secrets are encrypted at rest using your self-managed key, adding an extra layer of confidentiality.

Your BYOK keys are themselves stored securely within a Hardware Security Module (HSM) or a secure key management service, separate from your application data. This setup ensures that only authorized processes can access and utilize your encryption key to decrypt your secrets, even our own administrators cannot access your plaintext data without your explicit key.

Regular key rotation is a fundamental security practice. It limits the window of exposure should a key ever be compromised. Blanca's Builder recommends and facilitates the periodic rotation of all API keys and secrets. While the platform does not automate the external service-side key generation, it provides a straightforward interface for you to update existing keys.

To rotate a key, you typically generate a new key from the respective third-party service provider, update it within your Blanca's Builder project settings, and then deactivate or revoke the old key on the service provider's side. Establishing a rotation schedule (e.g., quarterly or biannually) as part of your security policy is highly recommended to maintain a strong security posture.

Despite all precautions, key leaks can occur. Prompt and decisive action is critical to minimize potential damage. If you suspect or confirm an API key leak, follow these immediate steps:

1. **Revoke the compromised key immediately:** Log in to the service provider where the key originated (e.g., Stripe, AWS, OpenAI) and revoke or delete the compromised key. This is the single most effective step to prevent unauthorized access.

2. **Generate a new key:** Create a brand-new API key on the service provider's platform.

3. **Update Blanca's Builder:** Replace the old, compromised key with the new key in your Blanca's Builder project settings.

4. **Investigate the cause (if possible):** Try to determine how the key was exposed. This might involve reviewing recent code changes, deployment logs, or access patterns. This helps prevent future leaks.

5. **Notify relevant stakeholders:** Inform your team and, if necessary, the administrators of the affected service about the incident. Transparency is key to managing such events effectively.