crontent

API Key Security: How to Store, Scope and Rotate Keys

Crontent
API Key Security: How to Store, Scope and Rotate Keys

Securing an API key comes down to five habits. Keep it out of your code and repositories. Store it in a secrets vault or environment variable. Give each key the smallest permissions that work. Use a separate key for every service and environment. Rotate keys on a schedule, and immediately after any suspected leak. This guide walks through each habit, shows where teams usually slip, and explains when OAuth is the better tool.

Crontent
Publish Consistently Without More Content Work
Crontent helps solo founders and small SaaS teams publish well-researched, source-cited content while keeping their brand voice intact.

TL;DR

  • An API key identifies a project or application, not a person, so its safety depends entirely on where you store it and how narrowly you scope it.
  • Never hardcode keys or commit them to version control. Use a secrets vault or environment variables, and add a pre-commit hook and a secret scanner.
  • Use one restricted key per service, environment and integration, and audit and delete the ones you no longer use.
  • Rotate keys at least every 90 days, following CISA’s guidance, and rotate at once after any exposure.
  • Choose OAuth when you need to know which individual user is acting. Keep API keys for server-to-server access.

Table of Contents

What an API key does, and what it does not

An API key is a unique string that a software application sends with each request so the provider knows which project is calling. IBM describes it as basic identification and authorization that is generally not considered highly secure on its own, and it notes that the real security depends on how and where the key is stored and used.

The second limit matters more. Google’s documentation explains that API keys identify a project, but they do not authenticate individual human users. Whoever holds the string acts as the project. There is no second factor, no user prompt and no expiry unless you build one.

That is why a key left in the wrong place is a real incident. It behaves like a password that never asks who is typing.

What happens if someone gets your API key

Stripe’s guidance is blunt about the outcomes: an unauthorized party holding your key can make unauthorized charges, read customer data or disrupt your integration. The exact damage depends on what the key is allowed to do, which is why scoping (covered below) matters as much as storage.

Three risks of a compromised API key

There is a financial side too. Under its agreement, Stripe states that the account holder is responsible for losses arising from a key compromise. Other providers have their own terms, so read the ones for each service you use. The practical lesson is the same everywhere: a leaked key is your problem first.

Public repositories are the most common route. Google warns that keys committed to version control are frequently scanned by malicious actors, so a key pushed even briefly should be treated as compromised.

Step 1: Keep keys out of your code

The first rule in every provider’s guidance is the same: never hardcode a key in source code. It is also the rule that breaks most often, because the quickest way to test an integration is to paste the key into a file.

Where it goes wrong:

  • A key lands in a config file that was never added to .gitignore.
  • A key sits in an old commit. Deleting the file later does not remove it from history.
  • A key is embedded in front-end code, mobile apps or a public notebook, where anyone can read it.

What to do instead:

  1. Load the key at runtime from an environment variable or a secrets manager.
  2. Add a pre-commit hook that blocks commits containing key-shaped strings. Stripe’s guidance lists pre-commit hooks among the controls that prevent accidental commits.
  3. Run a secret scanner over your source code, configuration files and CI/CD pipelines. Stripe recommends this as a routine audit, since pipelines often hold copies of keys that nobody remembers.
  4. If a key ever reaches a repository, revoke it and issue a new one. Do not rely on rewriting history.

Step 2: Store keys in a vault or environment variables

For local development, environment variables loaded from a file that is excluded from version control are the simplest option. For production, use a dedicated secrets vault and restrict access to the services that need it, as Stripe advises.

A vault earns its place because of what it adds beyond storage. According to the same guidance, it provides an audit log, supports automatic rotation and lets you revoke access without redeploying your application. For a two-person team that last point is the one you will feel: you can kill a key in minutes instead of shipping a release.

Two transport habits are worth building in from the start:

  • Send keys in a header, not the URL. Google recommends using an HTTP header or a client library instead of query parameters, because URLs end up in logs, browser history and analytics tools.
  • Do not share keys over email, chat or support tickets. IBM points out that only authorized systems should hold these credentials, and a message thread is not one.

Step 3: Scope every key to the minimum

A key that can do everything turns every leak into a full breach. Restrictions limit how a key can be used and reduce the impact of a compromise, according to Google.

A workable rule set for a small team:

  • One key per service, environment or third-party integration. Stripe’s notice recommends creating a separate restricted key for each. When one leaks, you know where it came from and what to revoke.
  • Separate development and production keys. A test key in a laptop script should never be able to touch live customer data.
  • Least privilege. If an integration only reads data, give it a read-only key.
  • Audit and delete. Google advises regularly removing unused or unneeded keys to shrink the attack surface. Put a quarterly reminder in your calendar and go through the list.
  • Review logs. Watching usage for suspicious activity is part of the practice Stripe lists. A sudden spike at 3 a.m. is often the first sign of a leak.

A simple naming convention helps all of this. Name each key after its service, environment and owner, for example billing-prod-webhook, so an audit takes minutes.

Step 4: Rotate keys without breaking anything

Rotation limits how long a stolen key stays useful. CISA’s guidance recommends rotating API keys at least every 90 days, and notes that rotation disrupts persistence by anyone using a stolen key.

The process, per CISA, is to generate a new key, replace the old one, then revoke and securely delete the old one. The step where teams break production is the middle one. This order avoids downtime:

  1. Create the new key with the same restrictions as the old one.
  2. Add it to your vault or environment configuration.
  3. Deploy or reload so every service reads the new key.
  4. Check logs to confirm that traffic uses the new key and the old one has gone quiet.
  5. Revoke the old key, and delete any copies.

Where your provider supports overlapping keys, keep both live for a short window between steps 3 and 5. If you use a cloud secrets service, automate the schedule. AWS documents automatic rotation through Lambda functions to shorten the window in which a credential is exposed.

Rotate immediately, outside the schedule, when a teammate with access leaves, when a key appears in a repository or log, or when your provider reports unusual activity.

API key or OAuth: which should you use?

The two solve different problems. An API key says which application is calling. OAuth lets a user grant an application limited access, and it issues tokens tied to that user, which are shorter lived and easier to revoke. Because API keys do not authenticate individual people, they cannot answer the question “which user did this?”

Situation Better fit
Your backend calls a third-party service on its own behalf API key, stored in a vault and scoped tightly
A script or integration reads low-sensitivity data API key with read-only restrictions
Your app acts on behalf of a signed-in user OAuth
You need per-user permissions, audit trails or quick revocation OAuth
Code runs in a browser or mobile app OAuth or a backend proxy, never a raw secret key in the client

If you are issuing keys to your own customers, give each customer a key tied to their account, with its own permissions, so one leak does not expose everyone.

A short audit you can run this week

You do not need a security team to get most of the benefit. Set aside an hour:

  1. List every key you hold, with its service, environment and owner.
  2. Delete the ones nobody can explain.
  3. Run a secret scanner on your repositories and CI/CD configuration.
  4. Confirm production and development use different keys.
  5. Replace any key that is older than 90 days or that has been shared by chat or email.
  6. Switch any key passed in a URL to a header.

Keys and the content you publish about them

If you write documentation, tutorials or launch posts for a developer product, the same discipline applies to your drafts. Screenshots, code samples and copied terminal output are a common route for live keys to reach the public. Our piece on what never goes in a prompt covers keeping sensitive material out of AI-assisted drafting, and the guide on content for developer tools shows how to write technical posts that earn trust. If you push content into a CMS through an API, the schema rules in our integration guide help keep that connection stable.

Where Crontent fits

Solo founders and small SaaS teams often have the least time for security hygiene and for content, and both slip together. Crontent is a content automation platform that produces scheduled, research-backed blog posts, LinkedIn posts, X/Twitter posts and short video scripts for SaaS products. Every claim is tied to a linked source, your own takes steer the writing, and nothing is auto-published: a human reviews each draft before it goes out. It supports API and webhook integration and NDA-level content boundary controls, so the material you want kept private stays out of the drafts.

Crontent

If you want a steady stream of credible posts while you focus on shipping and securing your product, see the Starter and Pro plans on the Crontent site.

Our perspective

Security advice and content advice fail for the same reason: people choose speed over the boring step. A key pasted into a file saves a minute. A generic post pushed out unchecked saves an afternoon. Both come back later as a cost.

We built Crontent around the opposite habit. It reads current, full-length sources, asks for your real opinion before drafting, attributes every claim to a linked source, and always requires human review before anything is published. We avoid auto-publishing on purpose, because a person should decide what leaves the building.

The same instinct applies to keys. Scope narrowly, keep secrets out of shared places, and keep a human in the loop. A small team that does these three things will be ahead of most larger ones.

Jose

FAQ

How do I keep an API key secure?

Never hardcode it or commit it to version control. Load it from a secrets vault or environment variable, restrict it to the permissions it needs, and rotate it regularly. Add a pre-commit hook and a secret scanner so mistakes are caught before they leave your machine.

Is OAuth more secure than an API key?

For user-facing access, yes, because OAuth tokens are tied to a user and are easier to revoke. API keys only identify a project and do not authenticate individual people. For server-to-server calls, a well-scoped, vaulted and rotated API key is a normal choice.

How often should I rotate API keys?

CISA recommends at least every 90 days. Rotate right away after a suspected leak, after someone with access leaves, or when a key shows up in a repository or log. Automating rotation through your secrets manager makes this routine.

What happens if someone has my API key?

They can act as your project. Depending on its permissions, that can mean unauthorized charges, access to customer data or a disrupted integration. Revoke the key, issue a replacement, and review your logs for activity you did not initiate.

Sources