Skip to content

Secrets Management

The practice of keeping API tokens, app secrets and keys in a controlled vault, injecting them at runtime and auditing who can read them.

Also called: Secret management · Secrets storage · Credential management

Reviewed

Interactive lab

Hands on: use the controls to explore. Anything that plays on its own pauses while you are working inside it.

Are your WhatsApp secrets under control?

9/9

ticked

Required
5 / 5
Optional
4 / 4

Secrets under control

Every item ticked.

A working checklist for the credentials behind a WhatsApp integration. Tick what your team already does; the required items are the minimum before a production launch.

Secrets under control. 9 of 9 ticked.

01What is secrets management?

Secrets management is the discipline of controlling the credentials software uses to talk to other software: API keys, access tokens, passwords, signing keys and certificates. Instead of living in source code, config files or a shared spreadsheet, secrets sit in a dedicated store — a self-hosted vault or a cloud provider's secret manager — that encrypts them, decides which identities may read each one and records every read.

A WhatsApp Business Platform integration typically holds several: the system user access token that authorises Graph API calls, the app secret that keys the X-Hub-Signature-256 webhook signature and appsecret_proof, the verify token used in the hub.challenge handshake, the six-digit two-step verification PIN of each business number, plus database passwords and any provider API keys. Each grants a different power — sending as your brand, forging webhooks, re-registering a number — so each deserves its own access rule.

Good secrets management has four parts: storage (encrypted, central, versioned), access (each service reads only the secrets it needs, under its own identity), delivery (injected at runtime into memory or a mounted file rather than baked into an image) and detection (scanning commits, CI logs and chat for leaked values). It answers where secrets live and who can read them; token rotation answers how often they change, and key management covers the encryption keys that protect the store itself.

Key takeaways

  • Secrets management keeps credentials such as access tokens and app secrets in a vault or cloud secret store, never in code or images.
  • Applications fetch secrets at runtime under their own identity, so access can be granted, audited and revoked per service.
  • A WhatsApp integration holds at least three secrets: the access token, the app secret and the webhook verify token.
  • Leak scanning on commits and CI logs catches the most common exposure: a token pasted into a repository or a log.
  • Secrets management decides where secrets live and who reads them; token rotation decides how often they change.

02Why does secrets management matter?

Leaked credentials are one of the commonest ways into a system, and a WhatsApp access token is a valuable one: whoever holds it can send messages in your brand's name, read business phone number details and run up per-message charges. Keeping it in a vault with per-service access means a stolen laptop, an over-shared .env file or a public repository does not hand over the account — and when something does leak, you know exactly where the secret is used and can replace it in one place instead of hunting through servers.

03 · How it works, step by step

How does secrets management work?

  1. Step 1

    Inventory every secret

    List each credential, what it unlocks, which services use it and who owns it. For WhatsApp: access tokens per WhatsApp Business Account or client, the app secret, the verify token and phone number PINs.

  2. Step 2

    Move them into one store

    Create each secret in the vault or cloud secret manager, encrypted with a managed key, and remove copies from repositories, wikis, tickets and CI variables that everyone can read.

  3. Step 3

    Grant access per workload identity

    The sending service reads the access token; the webhook service reads the app secret; humans get no standing read access. Services authenticate with the platform's workload identity (an IAM role or service account) rather than yet another static key.

  4. Step 4

    Inject at runtime

    Fetch secrets when the process starts, or mount them as files, and cache them in memory with a short refresh interval so a rotated value is picked up without a redeploy.

  5. Step 5

    Scan, mask and audit

    Block commits that contain tokens with push protection or a pre-commit scanner, redact secrets in logs, and alert on unusual reads in the store's audit log.

04Secrets management in code

import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
 
const sm = new SecretsManagerClient({}); // authenticates with the service's IAM role
const cache = new Map();
const TTL_MS = 5 * 60 * 1000; // pick up rotated values within five minutes
 
async function getSecret(id) {
  const hit = cache.get(id);
  if (hit && Date.now() - hit.at < TTL_MS) return hit.value;
  const out = await sm.send(new GetSecretValueCommand({ SecretId: id }));
  cache.set(id, { value: out.SecretString, at: Date.now() });
  return out.SecretString;
}
 
export async function sendText(to, body) {
  const token = await getSecret("prod/whatsapp/access-token");
  return fetch("https://graph.facebook.com/v26.0/{PHONE_NUMBER_ID}/messages", {
    method: "POST",
    headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json" },
    body: JSON.stringify({ messaging_product: "whatsapp", to, type: "text", text: { body } }),
  });
}

The token never appears in code, images or environment files; the service's own identity decides whether it may read it.

05Secrets management: key facts and limits

WhatsApp secrets
Access token, app secret, verify token, two-step PIN
Where they belong
A vault or cloud secret manager, encrypted at rest
Never in
Source code, images, front-end bundles, URLs, logs
Access model
Per workload identity, least privilege
Refresh in running apps
In-memory cache, refreshed every few minutes
Detection
Secret scanning on commits, pull requests and CI logs

06 · Common mistakes, and the fix

Common mistakes with secrets management

  • Putting tokens in front-end code or mobile apps

    Anything shipped to a browser or phone can be extracted in minutes. Graph API calls that need an access token belong on your server, behind your own authentication, never in client code.

  • Deleting a leaked secret instead of replacing it

    Removing a token in a later commit leaves it in git history, forks and caches. Treat any exposed secret as compromised: generate a new one, revoke the old one, then clean up the history.

  • One secret shared by every service

    If the same token sits in the sender, the webhook service, analytics and a staff laptop, one leak exposes everything and you cannot tell where it came from. Split secrets by purpose and grant them per service.

  • Logging secrets by accident

    Debug logs that print request headers or whole config objects copy tokens into log storage with far weaker access control. Redact Authorization headers and secret fields in the logger itself.

07Example: Cleaning up after an agency hand-over

A Chennai D2C skincare brand takes its WhatsApp integration in-house from an agency. The audit finds the system user access token in three places: a .env file in the repository's history, a CI variable visible to every contributor and a pinned message in a team chat. The new team generates a fresh token, stores it in their cloud secret manager with read access only for the sending service's role, keeps the app secret in a separate secret readable only by the webhook service, revokes the old token in Business Settings and turns on push protection in their git host, so the next pasted token is blocked before it lands.

08 · Tips from the bench

Best practices for secrets management

  • Name secrets by environment and purpose, such as prod/whatsapp/access-token, so access policies stay readable.
  • Give staging its own WhatsApp app and tokens; never copy production secrets down.
  • Store each business number's two-step verification PIN in the vault too — it is a secret, not a note.
  • Review who can read each secret every quarter and remove anyone who no longer needs it.

09Secrets Management FAQs

Is a .env file good enough for storing API keys?+
For local development, yes; for production, no. A `.env` file is plain text on disk, easy to commit by mistake and readable by anything on the host. Production secrets belong in a secret store with access control and an audit log.
Where should I store my WhatsApp Cloud API access token?+
In a server-side secret store, readable only by the services that call the Graph API. Never put it in front-end code, a mobile app, a URL query string or a shared document.
What is the difference between secrets management and key management?+
Secrets management stores the credentials applications use; key management controls cryptographic keys. A key management service typically holds the master keys that encrypt the secret store, while the store holds tokens, passwords and API keys.
What should I do if I committed an access token to a public repository?+
Assume it is compromised and replace it now. Generate a new token, deploy it, revoke the old one in Business Settings, check the access token debugger and your logs for misuse, then purge it from the repository history.

See InfiQ pricing

From definition to your first message

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms