Secrets and Keys, Plainly
What a Key Actually Is
When your app uses an outside service — an AI service, an email sender, a database, a payment provider — it needs to prove it is you. It does that with a key, often called an API key. A key is a long string of characters that works exactly like a password, except software uses it rather than a person typing it. Anyone holding that string can do everything you can do with that service, billed to your account, with no further check. There is no second factor, no login screen, no confirmation email. That is the whole concept, and it is enough to understand why the rest of this lesson matters. A key is a password lying around in plain text, and the service treats it as unquestionably you.
- A key is a password used by software instead of a person
- Anyone holding it can act as you, billed to you, with no second check
- There is no additional verification step protecting it
- Treat any string labelled key, token or secret as a password in the open
Where They Must Never Be
Two places cause almost all real incidents. First, written directly into your code. Code gets copied, shared, pasted into chats and uploaded, and the key travels with it invisibly. Second, in a public repository — a repository being the online folder that holds a project's code. People run automated searches across public repositories constantly, hunting for exposed keys. Exposure is measured in minutes rather than days. The correct home for a key is your platform's environment settings or secrets store. You paste it in once, the running app can read it, and it never appears in a file. If a tool asks you to paste a key into code "for now", that is precisely the shortcut that becomes permanent.
- Never write a key into your code — the code travels and the key goes with it
- Public repositories are scanned automatically and constantly
- Use the platform's environment variables or secrets store instead
- Beware anything that suggests pasting a key inline "just for now"
If One Gets Out
Assume a key that has been exposed is compromised, even if nothing has obviously happened yet. The response is simple, and it should be immediate. Go to the service, revoke that key, create a new one, and put the new one in your platform's secrets store. This takes a few minutes. Deleting the file or the message it appeared in does not help. It may already have been read, and in a version-controlled project the old content usually still exists in the history. Then check the service's usage and billing for anything you did not do. There is no embarrassment worth delaying this over. Every experienced engineer has done it, and the only bad version is the slow one.
- Revoke and replace immediately — assume it was seen
- Deleting the file does not help; the history and any copies remain
- Check usage and billing on that service for unfamiliar activity
- Everyone does this eventually; only a slow response makes it costly
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.