Treat a WooCommerce REST API key like a password for a store user. Create one per integration, tie it to a user with the lowest role that works, send it only over HTTPS, keep it out of code and rotate it when staff or vendors change.
How the keys work
The WooCommerce REST API documentation says pre-generated keys can authenticate calls to the API endpoints. You create them in the admin under the REST API settings, add a description and choose the WordPress user the key belongs to. The documentation states that use of the API with those keys conforms to that user's WordPress roles and capabilities. Over HTTPS, you can use HTTP Basic Auth with the consumer key as username and the consumer secret as password. The docs show an example call to the orders endpoint using those credentials.
The consequence: a key tied to an administrator user acts with administrator rights, whatever the integration needs.
A routine for each key
- Create a dedicated user for each integration, with the lowest role that still works. Do not attach keys to a real person's admin account.
- Choose the permission level the integration needs. A reporting tool needs read, not write.
- Write the description so a future reader knows what uses it and who owns it.
- Use HTTPS only. Basic Auth sends credentials with every request, and plain HTTP exposes them.
- Store the secret in a secrets manager or the host's environment settings, never in a repository or a plugin settings field that is visible to others.
- Rotate when a vendor relationship ends or when a person with access leaves.
- Review the key list every quarter and revoke unused ones.
What to watch in logs
Log API calls with the key's user and endpoint. Look for calls at odd hours, bulk reads of customers or orders, and calls from unfamiliar addresses. Customer and order data is what attackers usually want. The OWASP logging guidance lists access to sensitive data and use of shared or default accounts among events worth recording.
Where keys leak
Common places are a public code repository, a vendor's support chat, a screenshot in a ticket, and a front end bundle for a custom storefront. If a key appears in any of these, revoke it and create a new one. Our post on which payment keys belong where uses the same least privilege thinking.
Quick check
Can a read only key still be a risk?
Yes. It can expose customer and order data, so protect it and limit who holds it.
Is Basic Auth over HTTPS acceptable?
The documentation supports it over HTTPS. Plain HTTP is not safe for credentials.
Sources
Safeguard can scan repositories for exposed secrets, and the free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
