A guide to securing API calls in a WordPress environment

Introduction: two directions, two distinct problems

People talk about "API security" as if it were one subject. It is two, and confusing them is the cause of most mistakes:

INBOUND  : what the world can ask of your WordPress   → REST API, webhooks
OUTBOUND : what your WordPress asks of the world      → keys, providers, AI

Inbound is a permissions problem: who can ask for what. Outbound is a secrets problem: where the key lives and who can read it. This article covers both, starting with the one that gets neglected most.

1. Outbound — where the key lives

This is the point that cancels out everything else if you get it wrong.

Never in a version-controlled file. A key in a repository stays in the history even if you delete it afterwards. Revocation is the only real fix: changing the file is not enough.

Never in theme code. A theme gets copied, shared, deployed to staging, sent to a contractor.

Never in client-side JavaScript. A key that reaches the browser is a public key. This mistake is more common than it looks, precisely because it "works" perfectly.

In a server environment variable, or in your host's secret store. And with an organisational rule worth as much as the technical one: one key per client and per use. A shared key makes attribution impossible, and an overrun becomes anonymous.

That last point is also what makes the budget legible — the full reasoning is in optimising your agency's budget with a personal API key.

2. Outbound — what to check on every call

• An explicit timeout. Without one, a slow provider blocks your page. It is the most common cause of "the site went down" when in fact it was waiting for a response.
• A spending cap at the provider, per key. It is a structural guarantee: it holds even if an automated job goes into a loop. No contractual commitment gives you that, because it acts after the fact.
• A rate limit on your side, so that a badly closed loop costs you an incident and not a month of budget.
• No unnecessary data sent. The best-protected data is the data that never left: if the job only needs the text of a product, it does not need the customer's name. That is the principle developed in why data privacy is your best ally.
• No secrets in the logs. An error message that dumps the full request writes your key into a file that is kept, and sometimes sent to a third party.

3. Inbound — the REST API, and what it exposes by default

WordPress exposes a REST API that is active by default. That is not a flaw, but there are three things worth knowing:

1. Some routes are public by design, and a few reveal the site's list of authors — that is, account names usable for a password attack. Restricting that route costs a few lines.
2. Every plugin can add its own routes. Your inbound surface grows with each installation, without anyone looking at it. That is one more argument for auditing your plugins.
3. A custom route without a capability check is open to everyone. It is the classic mistake in bespoke plugin work: you check the nonce and forget the capability. The nonce proves where the request came from, not the right to run it. You need both.

4. Inbound — webhooks

A webhook is a public URL that runs code. Three rules, and none is optional:

• verify the signature sent by the emitter, every time. Without verification, anyone who knows the URL can trigger the job;
• make the job idempotent: the same event received twice must not produce two effects. Providers do resend; that is normal;
• respond fast and work afterwards. A webhook that runs a long job before responding causes resends, and resends cause duplicates.

5. The five mistakes you find everywhere

1. The key on the client side — it works, and it is public.
2. The nonce without the capability — you check the origin, not the right.
3. The key shared across clients — attribution impossible, revocation impossible without affecting everyone.
4. No timeout — the provider's outage becomes yours.
5. The secret in the logs — written once, kept for months.

6. The protocol, on one page

• No key in a version-controlled repository, in a theme, or in client JavaScript
• One key per client and per use, in an environment variable or a secret store
• Spending cap set at the provider, per key, with an intermediate alert
• Explicit timeout on every outgoing call
• Rate limit on automated jobs
• Custom REST routes: nonce and capability check, without exception
• Webhooks: signature verified, job idempotent, fast response
• Logs reviewed: no secrets, no full requests dumped
• Revocation procedure written down — and tested once, not assumed

The last point is the one nobody does and the only one that counts on the day you need it.

Conclusion

API call security does not rest on a tool but on two questions you must be able to answer at any moment: where do my keys live, and who can read them? and what can the world ask of me without identifying itself?

Most incidents do not come from a sophisticated attack, but from a key that was somewhere it should not have been and a route that was not checking what it thought it was checking.

The test: if you had to revoke all your keys tonight, would you know where they are and how long it would take? If you cannot answer, that is the work to do first.

To continue: advanced WordPress hardening, proactive protection against zero-day threats and the GDPR+ approach and the personal API key architecture. Our premium plugins come with a full refund within 14 days: see the catalogue.