Forem: Beleke Ian

I Accidentally Exposed My API Key to the Entire Internet, Here's What I Learned

Beleke Ian — Wed, 22 Apr 2026 06:22:36 +0000

I've been building apps for a while now. I've deployed projects, shipped features, and even won a hackathon. But last week, while casually poking around the Chrome DevTools Network tab on my own project, I saw something that made my stomach drop.

The project is ChwiiX — a movie streaming discovery app I built with React and Vite. It pulls movie data from TMDB (The Movie Database), a popular third-party API that gives you access to movie listings, posters, ratings, trailers, and more. To use it, TMDB gives you an API key — a unique token that identifies your app and tracks your usage. Think of it like a password for your app.

And there it was, sitting in plain text in every single outgoing request in the Network tab:

https://api.themoviedb.org/3/movie/popular?api_key=sk_XXXXXXXXXXXXXXXX

My TMDB API key. Fully exposed. In the browser. For anyone to see.

The worst part? I thought I had secured it. It was in my .env file. It was in Vercel's environment variable panel. I had done "the right things" — or so I thought.

This post is about what actually went wrong, why it happens, and the correct fix that makes your key truly invisible.

First, How Was ChwiiX Structured?

To understand the problem, it helps to understand how the app was originally set up — because this is a pattern a lot of frontend developers follow without realizing the security implications.

ChwiiX is a Vite + React SPA (Single Page Application). That means the entire app is JavaScript that runs in your browser. There is no backend server of my own. When the app needs movie data, it calls TMDB directly from the browser, like this:

User's Browser → TMDB API

To make those requests, I needed to attach my API key to every call. So I stored it in a .env file at the root of the project:

VITE_BASE_API_KEY=my_secret_tmdb_key
VITE_BASE_URL=https://api.themoviedb.org/3

And in my code, I had a central config file — src/services/api.ts — that exposed those values to the rest of the app:

// src/services/api.ts
export const BASE_URL = import.meta.env.VITE_BASE_URL;
export const API_KEY = import.meta.env.VITE_BASE_API_KEY;

Then every page or hook that needed movie data would import those values and build a URL like this:

// Example: fetching popular movies anywhere in the app
const response = await fetch(`${BASE_URL}/movie/popular?api_key=${API_KEY}`);

This felt clean and organized. The key wasn't hardcoded anywhere in the source. It was an environment variable. I even configured it in Vercel's dashboard so it wouldn't live in my Git history. I thought I was doing everything right.

The Misconception: `.env` ≠ Secret

Here's the trap. When you add a variable to .env or to Vercel's dashboard, it feels secure because it's not hardcoded in your source. But there's one critical question you need to ask:

Where does this code actually run?

In a Vite React SPA, the answer is: the browser. Every file inside your src/ folder gets compiled and bundled into JavaScript files that get shipped to whoever visits your site. There is no server of yours running in the middle — it's just files sent directly to the browser.

Vite has a safety gate for this — it only exposes environment variables that start with VITE_ to the browser bundle. This is intentional. The VITE_ prefix is your explicit declaration: "I want this value available on the client side." Variables without the prefix stay undefined in the browser.

The problem? I used the VITE_ prefix on my API key. I was unknowingly opting into sending it to every visitor's browser. Vite did exactly what I told it to do.

Putting the key in Vercel's env panel just means it doesn't live in my Git history. It still ends up baked into the compiled JavaScript bundle that Vercel serves to the public.

Why the Network Tab Makes It Obvious

Even if the key was buried deep in the bundle, the Network tab removes all ambiguity. Because the browser is calling TMDB directly, every single request URL shows up in DevTools — including the api_key query parameter attached to every URL.

Anyone visiting ChwiiX can:

Press F12 → open the Network tab
Browse any page that loads movies
Click any request going to api.themoviedb.org
Read the full URL — including ?api_key=YOUR_KEY
Copy it and use it however they want That could mean burning through your free tier quota, racking up charges on a paid plan, or — if it's a more sensitive API like a payment or AI service — something far worse.

How Companies Actually Protect Their Keys

The reason you can't find Spotify's or Netflix's API keys in their Network tab is simple: they never let the browser talk to third-party APIs directly. They always put their own server in the middle:

Browser → Your Server (secretly adds the key) → Third-Party API

The browser calls your own endpoint — something like /api/movies/popular. Your server receives that request, quietly attaches the real API key, forwards the request to the third-party API, gets the response, and sends it back to the browser.

The key never travels to the browser at any point.

This pattern is called a proxy. And for a Vercel-deployed app like ChwiiX, the cleanest way to implement one is with a serverless function.

The Fix: A Serverless Proxy

A serverless function is a small piece of server-side code that Vercel runs on its own infrastructure — not in the browser. It has access to real server environment variables that are never bundled into client JavaScript.

Here's how I restructured ChwiiX to use one.

Step 1: Understand the new request flow

Before the fix, every request from ChwiiX went like this:

Browser → https://api.themoviedb.org/3/movie/popular?api_key=SECRET_KEY

After the fix, it goes like this:

Browser → /api/tmdb/movie/popular        (no key — hits your serverless function)
                    ↓
    Vercel Serverless Function            (adds the key server-side)
                    ↓
    https://api.themoviedb.org/3/movie/popular?api_key=SECRET_KEY

The browser only ever sees /api/tmdb/... — your own domain, with no key attached anywhere.

Step 2: Create the proxy serverless function

At the root of your project (not inside src/ — this runs on the server, not the browser), create a file at api/tmdb/[...path].ts:

// api/tmdb/[...path].ts
import type { VercelRequest, VercelResponse } from '@vercel/node';

export default async function handler(req: VercelRequest, res: VercelResponse) {
  // process.env here is server-side — it never reaches the client
  const apiKey = process.env.TMDB_API_KEY;

  // Reconstruct which TMDB endpoint was requested
  // e.g. if browser called /api/tmdb/movie/popular → path = "movie/popular"
  const path = (req.query.path as string[]).join('/');

  // Build the real TMDB URL, injecting the key server-side
  const params = new URLSearchParams(req.query as Record<string, string>);
  params.delete('path');        // remove the internal routing param
  params.delete('api_key');     // strip anything the client might have sent
  params.set('api_key', apiKey!); // inject the real secret key here, on the server

  const tmdbUrl = `https://api.themoviedb.org/3/${path}?${params.toString()}`;

  // Forward the request to TMDB and return the result to the browser
  const response = await fetch(tmdbUrl);
  const data = await response.json();
  res.status(response.status).json(data);
}

The filename [...path].ts is a Vercel catch-all route — this single function handles every TMDB endpoint automatically. Whether the browser requests /api/tmdb/movie/popular or /api/tmdb/search/movie?query=batman, it all routes here.

Step 3: Update the API config to point at the proxy

Back in src/services/api.ts — the central config file — swap the values:

// Before — browser calls TMDB directly, key is exposed in every request
export const BASE_URL = import.meta.env.VITE_BASE_URL;   // "https://api.themoviedb.org/3"
export const API_KEY = import.meta.env.VITE_BASE_API_KEY; // real key, visible in browser

// After — browser calls your proxy, key stays on the server
export const BASE_URL = '/api/tmdb'; // your own serverless function
export const API_KEY = '';           // empty — the proxy handles the key server-side

The best part: every other file in the app stays exactly the same. All the hooks and pages were already building URLs like ${BASE_URL}/movie/popular?api_key=${API_KEY}. They now just hit the proxy instead of TMDB directly, without any other changes needed.

Step 4: Tell Vercel not to intercept `/api` requests

Vercel SPAs have a default catch-all rewrite rule that sends every URL to index.html so React Router can handle navigation. But this would accidentally swallow your /api/tmdb/... requests before they ever reach your serverless function.

Fix it in vercel.json:

{
  "rewrites": [
    { "source": "/((?!api/).*)", "destination": "/index.html" }
  ]
}

The pattern (?!api/) means: "send everything to index.html — except paths starting with api/." Those get routed to the serverless function instead.

Step 5: Fix local development

Here's a catch that trips people up: Vite's dev server (npm run dev) doesn't run Vercel serverless functions. So if you run ChwiiX locally after this change, requests to /api/tmdb would hit nothing and movies wouldn't load.

The solution is Vite's built-in proxy feature. It runs in Node.js (server-side, just like the serverless function) and handles the key injection the same way. Add this to your vite.config.ts:

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/api/tmdb': {
        target: 'https://api.themoviedb.org/3',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api\/tmdb/, ''),
        configure: (proxy) => {
          proxy.on('proxyReq', (proxyReq, req) => {
            // This runs in Node.js — the key injection never reaches the browser
            const url = new URL(req.url!, 'http://localhost');
            url.searchParams.set('api_key', process.env.TMDB_API_KEY!);
            proxyReq.path = `${url.pathname}${url.search}`;
          });
        },
      },
    },
  },
});

Then create a .env.local file in the project root (Vite already adds this to .gitignore by default):

TMDB_API_KEY=your_actual_tmdb_key_here

Notice: no VITE_ prefix. Without that prefix, Vite will never bundle this value into the browser — it stays in Node.js only.

Here's how the security model looks across both environments:

Environment	Who handles `/api/tmdb`?	Where is the key?
`npm run dev`	Vite proxy (Node.js)	`.env.local` — never reaches the browser
Vercel production	Serverless function	Vercel env vars — never reaches the browser

Open the Network tab after these changes. Every movie request goes to /api/tmdb/movie/popular — your own domain, no key visible anywhere.

Clean Up Your Vercel Environment Variables

Go to your Vercel project → Settings → Environment Variables:

Add TMDB_API_KEY = your actual key (no VITE_ prefix — keep it server-side)
Remove VITE_BASE_API_KEY and VITE_BASE_BASE_URL — they are no longer needed and shouldn't exist Redeploy. Done.

The Mental Model to Take Away

Every time you write import.meta.env.VITE_*, ask yourself: "Am I okay with every visitor to my site seeing this exact value?" If the answer is no — if it's an API key, a private endpoint, a payment credential — it does not belong in client-side code. Full stop.

The rule is simple:

Secrets belong on servers. Browsers are public.

A serverless proxy adds about 30 minutes of work. It's the correct architecture, and it scales well — when you eventually want to add caching, rate limiting, or authentication to your API layer, your proxy function is exactly where that logic belongs anyway.

One last thing: if you've already deployed an app with an exposed key, rotate it immediately. Go to your API provider's dashboard, invalidate the old key, and generate a new one. Assume it was seen from the moment you first deployed.

ChwiiX taught me more about security architecture in one afternoon than months of reading docs. Sometimes the best lessons come from your own mistakes.

[Boost]

Beleke Ian — Sun, 08 Feb 2026 21:37:29 +0000

The Software Engineer's Guide to Man–Machine Symbiosis

Beleke Ian ・ Feb 8

#ai #softwareengineering #softwaredevelopment #devlive

The Software Engineer's Guide to Man–Machine Symbiosis

Beleke Ian — Sun, 08 Feb 2026 21:21:37 +0000

The AI revolution is the final filter for the modern developer: it will either expose you as a replaceable cog in a horizontal machine or empower you as the sovereign architect of a new monopoly.

While many fear replacement, the strategist sees something different. We have reached the end of the era of stagnant replication. True progress is no longer incremental — it is vertical.

AI is not coming for your job.

It is coming for your toil.

And it is leaving you with the far more difficult task: thinking.

The Contrarian Truth of Software Development

The mark of a systems architect is the ability to see what others don’t.

In the age of generative models, we must ask:

What important truth do very few people agree with you on?

The consensus view:

Software costs are going to zero → therefore engineers are becoming less valuable.

The contrarian truth:

Full automation of implementation does not commoditize engineers. It places a premium on the human ability to discover secrets — technological truths that no LLM can discover by averaging the past.

AI generates from patterns.

Innovation comes from what has never existed before.

Vertical vs Horizontal Progress

Most development today is horizontal progress — doing more of what already exists.

The future belongs to vertical progress.

Horizontal Progress (1 → n)	Vertical Progress (0 → 1)
Replication: More of the same	Innovation: Something new
Scaling existing CRUD systems	Inventing new paradigms
Boilerplate, wrappers, repetitive testing	Autonomous systems, new architectures
Competition and price pressure	Creative monopolies and high value

If you’re still writing boilerplate in the age of LLMs, you are choosing to be a typewriter in the age of the word processor.

Use AI to eliminate horizontal work — and reclaim time for vertical thinking.

Man and Machine: The Logic of Symbiosis

The future does not belong to machines.

It does not belong to unaugmented humans.

It belongs to human–AI symbiosis.

Human and machine teams work because their strengths don’t overlap.

Machine Strengths (Engine of Iteration)

Processing massive amounts of data instantly
Recognizing patterns across large codebases
Generating syntactically correct implementations
Rapid iteration at scale

Human Strengths (Architect of Secrets)

Independent thinking
Identifying unseen opportunities
Navigating ambiguity and edge cases
Defining purpose, vision, and tradeoffs

AI builds faster.

Humans decide what is worth building.

Escaping the Ideology of Competition

The biggest trap for developers is competing on commodities.

We compete:

For grades
For prestigious companies
For mastery of popular frameworks

This is a race to the bottom.

1. Reject Functional Conformity

If your value is defined by a common skill (React, LeetCode, etc.), you are interchangeable.

2. Use AI to Build a Monopoly

A monopoly isn’t a giant company.

It’s something so good that no close substitute exists.

Use AI to handle the routine so you can build something 10× better.

3. Find Technical Secrets

LLMs learn the average.

They cannot discover secrets.

A secret is:

A new system design
A novel architecture
A better abstraction
A hidden inefficiency no one noticed

That’s where long-term value lives.

The Architect’s Leverage

AI shifts the developer’s role upward.

Code Implementation

AI handles syntax and boilerplate.

If this is where most of your time goes, your leverage is low.

Feature Design

Use AI to explore multiple versions quickly.

Iteration becomes cheap.

System Architecture

Your job: ensure the system fits a coherent long-term vision.

Market Innovation

This is maximum leverage.

Use AI to:

Prototype unconventional ideas
Validate opportunities quickly
Discover problems others ignore

This is how you build a word processor in a world of typewriters.

Conclusion: Building the Bold Future

If we use AI only to do the same things faster, the future will be stagnant.

Growth — for your career and for society — depends on vertical innovation.

Your task is not to fear the machine.

Your task is to:

Escape the crowd
Reject conventional thinking
Search for hidden opportunities
Build something uniquely valuable

The future belongs to engineers who use AI not to compete faster —

but to think bigger.

Go from 0 to 1.

Architect the unprecedented.

Build a future that is fundamentally better than the present.

I Built a Streaming Aggregator for Practice. Then 5 Continents Showed Up (And the Ad Wars Began)

Beleke Ian — Wed, 21 Jan 2026 12:10:19 +0000

Last week, I soft-launched ChwiiX as a personal project to shake off some coding rust. I expected maybe a few curious clicks from friends. Instead, I'm now serving users across 5 continents with a 33% bounce rate.
Cool story? Sure. But here's the real talk: I'm currently losing a war against third-party ad providers, and I need your collective brain.
**
The Problem: Aggressive Iframe Hijacking**
Third-party media sources are incredibly aggressive with redirects. Here's what's happening:

User clicks "pause" on the video player
The iframe content intercepts the click event
User gets redirected to a spam/ad page
My app's UX is completely hijacked

It's not just annoying—it's killing trust with users who think I'm the one serving these redirects.

**
What I've Tried (So Far)**
Attempt 1: Iframe Sandboxing
<iframe src={streamUrl} sandbox="allow-scripts allow-same-origin" referrerPolicy="no-referrer" allow="autoplay; encrypted-media" />

Result: Partially effective. Blocks some redirects but breaks legitimate player functionality. The allow-same-origin is necessary for the player to work, but it also opens the door for the redirects.
Attempt 2: User Activation Detection
`let lastUserInteraction = Date.now();

document.addEventListener('click', () => {
lastUserInteraction = Date.now();
});

// In the iframe wrapper
iframe.addEventListener('beforeunload', (e) => {
const timeSinceInteraction = Date.now() - lastUserInteraction;

// If redirect happens within 500ms of click, likely hijacked
if (timeSinceInteraction < 500) {
e.preventDefault();
console.warn('Potential hijack blocked');
return false;
}
});`

Result: Doesn't work consistently. The beforeunload event doesn't fire reliably for iframe navigation, and even when it does, preventDefault() is often ignored by the browser.

Attempt 3: Pointer Event Overlay
const IframeWrapper = styled.div
position: relative;

&::before {
content: '';
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
z-index: 1;
pointer-events: none;
}

&:hover::before {
pointer-events: auto;
}
;

Result: Blocks clicks entirely, which defeats the purpose. Users can't interact with the player controls.

*What I'm Considering Next
*

Proxy Layer: Route all third-party streams through a backend proxy that strips aggressive scripts (heavy lift, potential legal gray area)
Content Security Policy Headers: More aggressive CSP rules, but I'm worried about breaking too many legitimate sources
Source Reputation System: Build a database of "clean" vs "aggressive" sources and auto-switch users to better options
User-Controlled Overlays: Give users a toggle to enable a click-protection layer when they're not actively using controls ** The Bigger Picture** This started as a learning project. Now I'm learning way more than I bargained for about:

DOM security models and their limitations
The Wild West of third-party media streaming
Why companies like Netflix build everything in-house
**
What's Next for ChwiiX**
Once I win (or at least survive) this ad battle:
Global CDN/Image Optimization: My users in South America and Asia deserve better load times
Persistent Watchlists: Moving from localStorage to a proper backend
Smart Source Switching: Automatically serve the cleanest available stream based on reputation scoring
**
I Need Your Experience**
Have you dealt with aggressive iframe redirects? I'm especially interested in:
Techniques that actually worked
Legal considerations I should be aware of
Libraries or tools you'd recommend
Creative solutions I haven't thought of

From Rusty to Release: How an Infinite Loop Taught Me to Respect React DevTools

Beleke Ian — Mon, 12 Jan 2026 08:06:21 +0000

There is a huge difference between having a tool and knowing how to use it. I own a socket wrench set, but that doesn't mean I should be allowed near a car engine. Similarly, I’ve had the React DevTools extension installed on Chrome for years.

Did I use it? Sure. I used it to hover over parent-child components, nod sagely, and then go back to console.log('here') debugging. That changed this week.

After some time away from coding, I felt my web dev muscles atrophying. I decided the only way to fix it was to build something substantial. Enter ChwiiX, a streaming platform I designed to help me rekindle my relationship with React.

It was going well until I hit The Wall.

The Loop of Doom

Yesterday, my application decided to enter an infinite render loop. A collision between my data-fetching hook and a useEffect dependency array was making the app unusable. My browser fan sounded like it was preparing for takeoff.

I was lost in my own logic, guessing at which variable was triggering the re-render. I wasted hours changing true to false and hoping for a miracle.

Moving from Guessing to Learning

I decided to stop "guessing" and started "learning." I went back to the basics with Kyle Cook's guide on the Profiler and Components tabs. I finally stopped treating the DevTools like a passive observer and started using them as a surgical instrument.

In minutes, I saw what took me hours to look for:

I could see exactly which component was triggering the re-render (it wasn't the one I blamed).
I saw the frequency of the "Commits."
I identified the exact hook causing the collision.

If you haven't touched the Profiler tab yet, you are debugging on hard mode. Stop it.

Deployment and Feedback

Fixing that bug gave me the momentum to cross the finish line. I spent the rest of the week polishing the UI and taking the project from a local directory to a live Vercel deployment.

I’m happy to say the rust is gone. But code doesn't exist in a vacuum.

I have built ChwiiX, and I am proud of it, but I need eyes on it. I have added a review form directly on the site.
**
Here is my ask:**
Visit chwiix.vercel.app. Click around. Break things. Then, use the form to tell me about it. Whether you think the UX is smooth or the color palette hurts your eyes, I want to hear it.

Now, if you'll excuse me, I have some Profiler stats to obsess over.

Mastering React DevTools: A Comprehensive Guide to Efficient Debugging

Beleke Ian — Sun, 11 Jan 2026 19:08:41 +0000

In the dynamic ecosystem of modern web development, React remains a dominant force. However, as applications grow in complexity, managing component states, props, and performance can become a daunting task. Enter React DevTools — a browser extension that serves as a surgical instrument for frontend developers. This article explores the basics of React DevTools and articulates why it is a non-negotiable asset for professional development.

Introduction

Debugging is often the most time-consuming aspect of software engineering. While standard browser developer tools allow us to inspect the DOM, they fall short when dealing with React’s Virtual DOM. React DevTools bridges this gap, providing a window into the internal logic of your application without requiring you to sift through compiled code.

The Components Tab: Your Component Tree

The core feature of the extension is the ‘Components’ tab. Unlike the flat structure of HTML elements seen in standard inspectors, this view preserves the hierarchy of your React components.

Inspecting Props and State: By selecting a component in the tree, you can view its current props and state in the side pane. This eliminates the need for excessive console.log statements.
Live Editing: The most powerful feature for UI testing is the ability to edit these values in real-time. You can toggle booleans, modify strings, or adjust numbers to instantly see how your UI responds to different data states.
Source Traceability: The tool also allows you to jump directly to the source code of the component, streamlining the navigation of large codebases.

The Profiler: Optimizing Performance

Performance is a key metric for user retention. The ‘Profiler’ tab is designed to record the performance information of your application. When you record a session, the Profiler gathers data on each render phase.

It generates a ‘Flame Graph’ — a visual representation of your component tree where the width of each bar represents the time taken to render. This allows developers to spot ‘expensive’ components that are taking too long to load. Furthermore, it helps identify unnecessary re-renders, where components update even when their data hasn’t changed, allowing for optimization via React.memo or useMemo.

Visualizing Updates

Another subtle but effective feature is the ability to ‘Highlight updates when components render.’ Found in the settings, this option draws a colored border around any component in the browser view the moment it re-renders. This visual feedback is invaluable for spotting cascading render issues that might otherwise go unnoticed until the application scales.

Conclusion

React DevTools is more than a convenience; it is a necessity for scalable development. By moving beyond basic debugging and utilizing the Profiler and Component inspection tools, developers can write cleaner, faster, and more reliable code. If you haven’t integrated a deep dive of these tools into your workflow, now is the time to start.

Forem: Beleke Ian

I Accidentally Exposed My API Key to the Entire Internet, Here's What I Learned

First, How Was ChwiiX Structured?

The Misconception: .env ≠ Secret

Why the Network Tab Makes It Obvious

How Companies Actually Protect Their Keys

The Fix: A Serverless Proxy

Step 1: Understand the new request flow

Step 2: Create the proxy serverless function

Step 3: Update the API config to point at the proxy

Step 4: Tell Vercel not to intercept /api requests

Step 5: Fix local development

Clean Up Your Vercel Environment Variables

The Mental Model to Take Away

[Boost]

The Software Engineer's Guide to Man–Machine Symbiosis

Beleke Ian ・ Feb 8

The Software Engineer's Guide to Man–Machine Symbiosis

The Contrarian Truth of Software Development

Vertical vs Horizontal Progress

Man and Machine: The Logic of Symbiosis

Machine Strengths (Engine of Iteration)

Human Strengths (Architect of Secrets)

Escaping the Ideology of Competition

1. Reject Functional Conformity

2. Use AI to Build a Monopoly

3. Find Technical Secrets

The Architect’s Leverage

Code Implementation

Feature Design

System Architecture

Market Innovation

Conclusion: Building the Bold Future

I Built a Streaming Aggregator for Practice. Then 5 Continents Showed Up (And the Ad Wars Began)

From Rusty to Release: How an Infinite Loop Taught Me to Respect React DevTools

The Loop of Doom

Moving from Guessing to Learning

Deployment and Feedback

Mastering React DevTools: A Comprehensive Guide to Efficient Debugging

The Misconception: `.env` ≠ Secret

Step 4: Tell Vercel not to intercept `/api` requests