🦥 Environment Variable Leaks

Sponsored by

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had a freaky week 😉 

Training Generative AI? It starts with the right data.

Your AI is only as good as the data you feed it. If you're building or fine-tuning generative models, Shutterstock offers enterprise-grade training data across images, video, 3D, audio, and templates—all rights-cleared and enriched with 20+ years of human-reviewed metadata.

With 600M+ assets and scalable licensing, our datasets help leading AI teams accelerate development, simplify procurement, and boost model performance—safely and efficiently.

Book a 30-minute discovery call to explore how our multimodal catalog supports smarter model training. Qualified decision-makers will receive a $100 Amazon gift card.

Book a call

_{For complete terms and conditions, see the offer page.}

Environment Variable Leaks

Let’s talk about a classic universal mistake every programmer makes at least once.

Leaking environment variables.

Sloth what’s an environment variable?

Oh right we have beginners reading!

Environment variables are where we stash our precious secrets.

API keys, database URLs, and other settings that change between environments.

Usually they’ll be stored in what’s called a .env file

Environment variables in a nutshell

// Bad: hardcoded in source code
const API_KEY = "wow_look_at_my_key";

// Good: using an environment variable
const API_KEY = process.env.API_KEY; // This is in a .env file!

These SHOULD NEVER BE PUBLIC.

One mistake and you’ll have a juicy bill coming your way.

Environment variables prevent these secrets from being in the source code, but that doesn’t mean they’re safe!

You can also split them by environment (.env.development, .env.test, .env.production) so you only load what’s necessary and reduce the pain of the leaks.

The Many Ways Secrets Leak

1. Pushing the .env to GitHub

The number one rookie move. You forget to add .env to .gitignore, you hit that sweet git push, and boom your API keys are now public property.

2. Hardcoding Secrets

"I’ll just hardcode the API key in the code for now and change it later"

//TODO: Put this into a env variable
const API_KEY = "wow_look_at_my_key_again";

Six months later…

It’s still there.

3. Front-End Exposure:

Environment variables aren’t magical force fields.

Just because you prefix them with process.env doesn’t mean they’re safe.

In frameworks like Next.js (NEXT_PUBLIC_*) or Vite (VITE_*), any variable that makes it into the build is visible in the browser.

That means if you put a secret there, people can see it if they know how to use the browser’s devtools.

So what is safe in the browser?

The only things that belong in frontend env variables are non-sensitive configuration values like:

• Public API base URLs (e.g., NEXT_PUBLIC_API_URL=https://api.example.com)

• Feature flags for toggling UI elements

• Analytics keys that are meant to be public identifiers

These aren’t really “secrets”. They’re values that the client legitimately needs.

Then why make them environment variables at all?

Good question. Even if the values aren’t secret, using env variables still helps:

• Flexibility: You can swap out values (like staging vs production API URLs) without touching the code.

• Consistency: Both your backend and frontend can read from a unified config system.

• Deployment-friendly: CI/CD pipelines can inject the right values for each environment automatically.

So yeah, you’ll often see env variables in the frontend, but they should never contain passwords, tokens, or API keys with real power.

4. Messing up a Docker container

Whenever you make docker containers, usually you just copy everything.

DON’T do that for environment variables.

# Dockerfile - BAD
COPY .env /app/.env   # stored in image layers forever

If you do this, anyone who can pull your image (including registries, caches, or compromised build logs) can read your secrets.

Docker has a specific command to handle this:

# docker-compose.yml
services:
  app:
    image: myapp
    env_file: .env

Fun Horror Story

Uber had 2 data breaches because they’ve accidentally left secrets public.

Here’s how bad that went:

• 2014: 100k users had their name and drivers license leak.

• 2016: Exposed data of 57 MILLION users (yikes!)

Here’s a good summary of it.

Yeah… be careful with those secrets.

How To Submit Answers

Thanks to everyone who submitted!

Suji-droid, 190-785(cool name), akshaysreekrishna-byte, AspenTheRoyal.

We’ll do an easier challenge this week!

Is It the Same Upside Down?

The number 6090609 has a special property: if you turn the number upside down (imagine rotating your screen 180 degrees), you get 6090609 again.

Write a function that takes a string on the digits 0, 6, 9 and returns true if the number is the same upside down or false otherwise.

Examples

sameUpsidedown("6090609")
output = true

sameUpsidedown("9669")
output = false
# Becomes 6996 when upside down.

sameUpsidedown("9")
output = false

sameUpsidedown("0")
output = true

sameUpsidedown("6090609")
output = true

sameUpsidedown("60906096090609")
output = true

sameUpsidedown("966909669")
output = false
# Becomes 699606699 when upside down.

sameUpsidedown("96666660999999")
output = false

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.