Stop Hardcoding Secrets: How to Share API Keys and Environment Variables Securely

There is a phrase that terrifies any Engineering Manager or DevOps leader: "Hey, can you send me the AWS Secret Key via Slack?".

In modern software development, Secrets Management is one of the most critical points. Despite advanced tools like Vault or AWS Secrets Manager, the problem persists in the "last mile": human-to-human communication.

When a new developer joins the team (Onboarding) or when you need to debug production quickly, the temptation to paste a credential in the chat is high. But doing this is equivalent to "hardcoding" the secret in the logs of a third-party platform.

In this post, we'll see how to avoid disasters in git secrets safety and what the hygienic flow is for sharing environment variables.

The Danger of "Ghost Secrets" in Slack and Git

The problem with sharing an API Key via chat or email is not just that someone sees it now. The problem is persistence.

• Git History is eternal: If you make the mistake of committing a .env file to your repository (even private), that secret lives in the Git history forever, unless you rewrite history (BFG Repo-Cleaner), which is painful and dangerous.
• Slack/Teams are not vaults: Chats have search engines. If an attacker enters your Slack a year later and searches for "password", "key", or "secret", they will find all the credentials your team shared "quickly" months ago.

Real-World Incidents: What Happens When Secrets Leak

Secret leaks are not theoretical risks. They happen every day, to organizations of every size. Here are three well-documented incidents that illustrate the real consequences of poor secrets management.

GitHub's Secret Scanning Reveals the Scale

In 2023, GitHub reported that its secret scanning feature detected over 12 million exposed secrets across public repositories in a single year. These included API keys, database connection strings, OAuth tokens, and cloud provider credentials. Many of these secrets were committed accidentally by developers who forgot to add .env to their .gitignore, or who hardcoded credentials during local testing and pushed them without realizing.

GitHub now blocks pushes that contain known secret patterns by default for public repositories. But this safety net only catches secrets in well-known formats. Custom API keys, internal tokens, and database passwords often slip through undetected.

Uber Breach (2022): Slack Credentials as the Entry Point

In September 2022, an 18-year-old attacker gained access to Uber's internal systems through a social engineering attack. After obtaining a contractor's VPN credentials, the attacker found hardcoded credentials in a PowerShell script shared on an internal Slack channel. These credentials provided access to Uber's Privileged Access Management (PAM) platform, which in turn gave the attacker access to AWS, Google Workspace, and internal dashboards.

The lesson here is clear: secrets shared in Slack don't just sit there for convenience. They become attack vectors. An attacker with even minimal access to your chat history can escalate privileges rapidly when credentials are lying in plain sight.

CircleCI Incident (January 2023): Rotate Everything

In January 2023, CircleCI disclosed a security breach that required all customers to immediately rotate every secret stored in the platform. An attacker had compromised an engineer's laptop through malware, then used a valid SSO session to access internal systems and exfiltrate customer environment variables and keys.

The fallout was massive. Thousands of engineering teams across the industry had to stop what they were doing and rotate API keys, database passwords, cloud credentials, and signing keys. For many teams, this meant days of work because they had no inventory of which secrets were stored where.

The Right Flow: "Generate, Share, Destroy"

To solve the problem of how to send env variables to team without risks, we need an ephemeral intermediate layer.

This is where Nurbak acts as a security buffer. Instead of exposing the secret, you expose a temporary link.

The Secure Workflow for Developers

Suppose you need to pass the STRIPE_SECRET_KEY to a colleague.

❌ The Lazy Way (Incorrect):

• Copy the key.
• Open Slack/Discord.
• Paste: STRIPE_KEY=sk_live_51Mz...
• Result: The key is recorded on Slack servers and in push notifications on your colleague's devices.

✅ The Secure Way with Nurbak (Correct):

1. Copy the key.
2. Go to Nurbak.
3. Paste the key and configure: 1 Visit / 10 Minutes life.
4. Generate the link.
5. Paste the link in Slack: "Here is the Stripe key for local".
6. Result: Your colleague opens the link, copies the key to their local .env, and the link explodes. If someone checks the chat history tomorrow, the link will be dead (404 Not Found).

Code Examples: The .env Workflow

A proper .env workflow is the foundation of secrets management in any project. Here is the pattern every team should follow.

Step 1: Create a .env.example Template

Your repository should always contain a .env.example file with placeholder values. This file is committed to Git and serves as documentation for which environment variables the project requires.

# .env.example - Commit this file to your repository
# Copy this file to .env and fill in the real values

# Application
NODE_ENV=development
PORT=3000
APP_URL=http://localhost:3000

# Database
DATABASE_URL=postgresql://user:password@localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379

# Third-party APIs
STRIPE_SECRET_KEY=sk_test_replace_me
STRIPE_WEBHOOK_SECRET=whsec_replace_me
SENDGRID_API_KEY=SG.replace_me

# AWS
AWS_ACCESS_KEY_ID=your_access_key_here
AWS_SECRET_ACCESS_KEY=your_secret_key_here
AWS_REGION=us-east-1
S3_BUCKET=myapp-dev-assets

Step 2: Add .env to .gitignore

This is the most important line in your entire .gitignore. Without it, one careless git add . and your secrets are in the history forever.

# .gitignore

# Environment variables - NEVER commit the real .env
.env
.env.local
.env.production
.env.*.local

# Keep the template
!.env.example

Step 3: Load Environment Variables in Your Application

Most languages have a library for loading .env files into environment variables. Here are the two most common setups.

Node.js (using dotenv):

// Install: npm install dotenv

// Load at the very top of your entry file (app.js or index.js)
require('dotenv').config();

// Now access your variables
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

console.log(`Server running on port ${process.env.PORT}`);

// Pro tip: validate that required vars exist at startup
const requiredVars = ['DATABASE_URL', 'STRIPE_SECRET_KEY', 'AWS_ACCESS_KEY_ID'];
for (const varName of requiredVars) {
  if (!process.env[varName]) {
    console.error(`Missing required environment variable: ${varName}`);
    process.exit(1);
  }
}

Python (using python-dotenv):

# Install: pip install python-dotenv

import os
from dotenv import load_dotenv

# Load .env file
load_dotenv()

# Access your variables
database_url = os.getenv('DATABASE_URL')
stripe_key = os.getenv('STRIPE_SECRET_KEY')

# Validate required variables at startup
required_vars = ['DATABASE_URL', 'STRIPE_SECRET_KEY', 'AWS_ACCESS_KEY_ID']
for var in required_vars:
    if not os.getenv(var):
        raise EnvironmentError(f'Missing required environment variable: {var}')

The key principle: the real .env file never enters version control. When a new developer needs the actual values, you share them through an ephemeral link (not through Slack, email, or a shared document).

Onboarding of New Developers

One of the most vulnerable moments is when a new dev joins the project. "Pass me the .env" usually results in a text file sent via email.

Best Practice: Copy the full content of your .env.example (or the real development values), paste them into Nurbak, and send a single link. This ensures that master development credentials don't stay floating in inboxes.

Security Comparison: Plain Text vs. Ephemeral Link

Secrets Management Tools Compared

If your team is growing beyond a handful of developers, you will eventually need a dedicated secrets management solution. Here is how the most popular tools compare.

The reality is that most teams benefit from a combination of these tools. A secrets manager like Vault or Doppler handles the long-lived secrets your applications need at runtime. But for the human-to-human transfer (onboarding a new developer, sharing a one-off credential, rotating a key), you still need an ephemeral sharing mechanism. That is where Nurbak fits in: it is not a replacement for a secrets manager, but a complement for the moments when a human needs to send a secret to another human.

The Cost of a Leaked Secret

When a secret leaks, the immediate instinct is to rotate it and move on. But the true cost goes far beyond the five minutes it takes to generate a new API key.

• Credential rotation time: Depending on how many services depend on the leaked key, rotation can take hours or days. Every service, CI/CD pipeline, and deployment configuration that references the old key needs to be updated and tested.
• Incident response hours: Your security team needs to investigate the scope of the breach. Was the key used by an attacker? What data was accessed? How long was the key exposed? These questions take time to answer and often involve multiple team members.
• Compliance audit findings: If your organization is subject to SOC 2, ISO 27001, HIPAA, or PCI DSS, a secret leak becomes an audit finding. You will need to document the incident, your response, and the remediation steps. Auditors will scrutinize your secrets management practices more closely going forward.
• Potential fines and legal liability: If the leaked secret leads to a data breach affecting customer data, your organization may face regulatory fines (GDPR fines can reach up to 4% of annual global revenue), class-action lawsuits, and reputational damage that takes years to recover from.

Conclusion: Digital Hygiene in Code and Chat

You wouldn't git commit your passwords (or so we hope). You shouldn't "commit" your secrets to Slack history.

Using a tool to share API keys securely takes no more than 5 extra seconds, but saves you hours of credential rotation and explanations to security auditors.

Make the use of ephemeral links part of your engineering team's culture. For a comprehensive approach, check out our guide on secret key management best practices for small teams. And if you want to understand how the encryption actually works, read about client-side vs. server-side encryption.

Frequently Asked Questions

What is the difference between a Secrets Manager and an ephemeral link?

A Secrets Manager (like HashiCorp Vault, AWS Secrets Manager, or Doppler) is a long-term storage solution for secrets that your applications need at runtime. It handles access control, audit logging, and automatic rotation of credentials that services consume programmatically. An ephemeral link (like those generated by Nurbak) solves a different problem: the one-time, human-to-human transfer of a secret. It is designed for the moment when one person needs to send a credential to another person securely. The link self-destructs after being read, leaving no trace. In practice, most teams need both: a Secrets Manager for application-level secrets and an ephemeral sharing tool for developer-to-developer transfers during onboarding, key rotation, or debugging.

Should I use a .env file in production?

Generally, no. While .env files are excellent for local development, production environments should inject secrets through more secure mechanisms. Most cloud platforms (AWS, GCP, Azure, Heroku, Vercel, Railway) provide native environment variable management through their dashboards or CLI tools. Container orchestration platforms like Kubernetes have their own Secrets objects. CI/CD pipelines have built-in secret stores. The risk of using a .env file in production is that it is a plain text file sitting on a server. If an attacker gains filesystem access, or if a misconfigured web server serves the file publicly, every secret is exposed at once. Use .env files for local development, and rely on your platform's native secrets management for staging and production.

How often should I rotate API keys?

The answer depends on the sensitivity of the key and your compliance requirements, but here are general guidelines. Immediately if you suspect the key has been compromised (committed to a public repo, shared in plain text over chat, or involved in a security incident). Every 90 days is a common baseline recommended by frameworks like NIST and SOC 2 for high-privilege keys (cloud provider credentials, payment processor keys, database passwords). Every 6-12 months for lower-risk keys used in development or internal tooling. The most important practice is to have a rotation plan before you need one. Document which keys exist, where they are used, and who is responsible for rotating them. When a rotation is needed, you can use ephemeral links to securely share the new credentials with team members who need them.

Need to pass an environment variable NOW?

Don't paste it in the chat. Generate a secure and self-destructing link in seconds.