You will be able to store an API key in environment settings and explain why it must never reach client code.
Priya works in operations at a logistics firm in Jurong. Last month she built a small web page that summarises customer feedback for her team, and it worked on the first afternoon. To get it running quickly, she pasted her API key straight into the page's JavaScript. Two weeks later her provider sent an email about unusual usage on her account. Someone had opened the page, read the key out of the code, and used it to run their own requests on her bill.
Nothing about that was clever hacking. It is what happens by default when a key ends up in the wrong place, and it is the most common mistake people make on their first build. This lesson is about where the key goes instead.
When a browser loads a web page, it downloads every file the page needs: the HTML, the styles and the JavaScript. Those files sit on the user's computer. Anyone can open the browser's developer tools, look at the sources or the network tab, and read them line by line. Minifying the code, splitting the key into pieces or encoding it does not change this. The browser has to put the key back together to use it, so a curious user can too.
Mobile apps work the same way. The app package is a file on the phone, and there are free tools that unpack it and list the text inside. If your key is in the app, assume it is public.
So the rule is simple. A secret can only stay secret on a machine you control. Any copy of your code that reaches a user's device is not a machine you control.
The key belongs in an environment variable: a named value that the operating system or hosting service hands to your program when it starts, kept outside the code itself. Your code asks for it by name, something like reading `process.env.MODEL_API_KEY` in JavaScript or `os.environ["MODEL_API_KEY"]` in Python, and the actual value never appears in any file you write.
On your own machine, people usually keep these values in a file called `.env` in the project folder. That file is convenient and also dangerous, because it is exactly the kind of file that gets committed to git by accident and pushed to a public repository. Before you create it, add `.env` to your `.gitignore` file, the list of files git should never track. Then check that git really is ignoring it. Running `git status` should not show the env file as a new file to add.
When you deploy, you do not upload the `.env` file at all. Hosting services have a settings page for environment variables or secrets, and you paste the key there. Larger teams use a secrets manager, a service that stores keys, controls who can read them and records each access. Either way, the code is identical in every environment. Only the value it is handed changes.
Now the obvious question. If the browser cannot hold the key, how does Priya's page call the model at all?
It does not call the model. It calls Priya's own server. The browser sends the feedback text to a route on her server, say an address ending in `/api/summarise`. The server reads the key from its environment, sends the request to the model provider, gets the reply and passes only the summary back to the browser. The key travels between Priya's server and the provider and nowhere else.
This arrangement has other benefits beyond hiding the key. Your server is the one place where you can check what users send, cap the length of their input, limit how many requests each person makes and log what happened. Lesson 6.5, Ship a small working app, comes back to those limits, because they are what stop one enthusiastic user from spending your monthly budget in an afternoon. If you have built flows in Automate your work with AI and no-code tools, the automation platform played this role for you. It held your keys on its servers. Now you are building that layer yourself.
Mistakes happen, so decide now what you will do when one does. A key can leak through a commit, a screenshot in a team chat, a support ticket or a page like Priya's.
The first move is to open the provider's console, revoke the key and create a new one. Do that before anything else, before you clean up the code and before you work out how it happened. Then put the new key in your environment settings and redeploy.
People often try to fix a leak by deleting the commit or the file. That is not enough. Git keeps history, so an old commit can still be reached, and anything pushed to a public repository may already have been copied. Automated scanners search public code for strings that look like keys, so assume a leaked key has been seen. Revoking it is the only step that makes the leaked copy useless.
After that, check the usage page for requests you did not make, and look at the spending limit you set in lesson 1.1. That limit is what kept Priya's surprise to an annoying email rather than a large bill.
In the activity below you will move your key into an environment variable and prove to yourself that it is not sitting in any file you might share.
Set your key as an environment variable on your machine and confirm it is not inside any file you would share or commit.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).