What is API Key Security?

An API key is a unique string identifying the calling app to an API; API key security is the discipline of scoping and protecting it. Precision first, because most definitions blur it: a key identifies the application, provides only weak authentication (it’s a bearer credential — whoever holds it, is it), and carries coarse authorization (whatever scope was attached at creation). Users are authenticated by tokens; apps are identified by keys — and no RFC defines the API key at all. It is a convention, which is exactly why its security is your configuration, not a standard’s guarantee.

Key takeaways

The request, and the two kinds of keys

GET /v1/search?q=espresso HTTP/1.1
Host: api.example.com
X-Api-Key: pk_live_7f2c…      ← in a HEADER — URLs end up in logs,
                                 history, and referrers

Two different animals share one name:
publishable key   ships in web/mobile bundles · identifies the app,
                  meters usage · designed knowing it WILL be extracted
secret key        server-side only · password-class bearer credential ·
                  anyone holding it is you

The publishable model in practice — keys that ship because security lives elsewhere:

// JavaScript / Node.js — Back4app JS SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(APP_ID, JS_KEY); // both ship in your bundle — by design
Parse.serverURL = 'https://parseapi.back4app.com';
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request

// The one key that never ships: the Master Key bypasses every ACL and CLP.
// Server-only (Cloud Code / trusted backend), read from env or secret manager.

// Flutter / Dart — Back4app Flutter SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
await Parse().initialize(
  appId, // ships in the app — by design
  'https://parseapi.back4app.com',
  clientKey: clientKey, // publishable, extractable, NOT a secret
);
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// iOS / Swift — Back4app Swift SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
ParseSwift.initialize(
    applicationId: appId,  // ships in the IPA — by design
    clientKey: clientKey,  // publishable, extractable, NOT a secret
    serverURL: URL(string: "https://parseapi.back4app.com")!
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// Android / Kotlin — Back4app Android SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId(APP_ID) // ships in the APK — by design
        .clientKey(CLIENT_KEY) // publishable, extractable, NOT a secret
        .server("https://parseapi.back4app.com")
        .build()
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

API keys vs. tokens vs. JWTs

The comparison collapses into one sentence worth memorizing: keys identify apps; tokens authenticate users. Using a key where a user’s identity matters rebuilds authentication badly; using per-user tokens for anonymous app metering is machinery without a purpose.

Where keys live: the storage ladder

Hardcoded — never. Source code is copied, forked, and committed; git remembers forever, and secret-scanning bots find keys in public commits within minutes. Environment variables — the baseline, with the caveat the OWASP cheat sheet is blunt about: env vars leak through error logs, process dumps, and container definitions; they keep secrets out of git, not out of trouble. A secrets manager — the team standard: encrypted at rest, access-controlled per service, audited per read, rotatable centrally (open-source options include Vault, SOPS, and Infisical). Add the hygiene that makes leaks survivable: keys generated cryptographically random, prefixed (sk_live_…-style) so scanners recognize them, hashed at rest on the provider side like passwords, one key per app per environment — and secret scanning (gitleaks, trufflehog) wired into CI so the commit that leaks a key fails before it lands.

The client-side problem, honestly

Every explainer says “don’t put secret keys in client code”; almost none says the second half: your bundle is public. Web JavaScript is readable by definition; mobile binaries are unpacked and string-dumped routinely; obfuscation raises the effort from minutes to hours, once. Two consequences follow. First, the only keys that belong in clients are publishable ones — designed to identify, not to protect, with real authorization enforced server-side per request. Second, when a client must use a secret-keyed third-party service, the secret stays behind your own backend — the proxy pattern:

When a key leaks: the runbook

The clock matters — bots monitor public repositories and exploit committed keys in one to five minutes. In order: 1 · Revoke the key at the provider — before investigating, before the standup. 2 · Replace — issue the new key and deploy it through config, not code. 3 · Purge — remove from source and git history; a deleted line lives on in every clone. 4 · Audit — provider logs for the leak window: what was read, created, spent. 5 · Widen — anything co-located with the key (the same .env, the same repo) is presumed burned; rotate it too. And the caveat that separates real response from ritual: revocation stops future use — it does not un-exfiltrate data. What was taken during the window is an incident, not a rotation.

Rotation without downtime

Rotation caps the value of undetected leaks — a stolen key with 60 days left is a different asset than one valid forever. Risk-based cadence: 30–90 days for broad-scope or externally shared keys, up to a year for narrow internal ones, immediately on suspected exposure or departure of anyone who held it. The zero-downtime move is the dual-key overlap: issue the new key while the old stays valid, migrate deployments at leisure, then revoke the old — the same trick refresh-token systems formalize. Compliance regimes increasingly require the calendar; the security case never needed it.

Common use cases

• Server-to-server integration — the key’s native habitat: one service identifying itself to another.
• Usage metering and billing — the key as the unit providers count, throttle, and invoice.
• Publishable client identification — app bundles carrying keys built for exposure, with authorization elsewhere.
• Environment separation — test and live keys keeping staging accidents out of production data.
• Abuse containment — per-key rate limits and revocation as the blast-radius controls.

Which credential should you use? A decision matrix

Limitations and trade-offs

• Keys can’t prove possession. A bearer string offers no cryptographic binding to the caller; for high-assurance service auth, mutual TLS and signed requests exist for a reason.
• Static credentials age badly. No expiry means every leak is open-ended until noticed; rotation is the manual substitute for the lifecycle tokens get for free.
• Coarse scopes overshare. One key with broad permissions is a skeleton key; granular scoping costs administration and pays in blast radius.
• Keys identify, not authenticate. Building user-level trust on app-level identification is the broken-authentication pattern auditors look for first.
• Inventory drift is real. Unused keys from old integrations stay valid until deleted — the zombie-credential cousin of zombie endpoints.

API keys on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its key model is the client-side section made concrete: the Application ID and client keys ship inside your apps by design — Back4app’s own docs are explicit that client keys are not security mechanisms — because authorization never depends on them: every request is checked server-side against class-level permissions and ACLs, so an extracted key grants an attacker exactly what an anonymous user gets. The one true secret is the Master Key, which bypasses every ACL and CLP: it lives server-side only — Cloud Code, trusted backends, env or secrets manager — and never in a bundle. The code tabs show the split in practice; the runbook applies to the master key alone, which is the point: one secret to guard is a security posture, forty is a spreadsheet.