APIs now carry the most valuable data a business has: customer records, orders, payments and pricing. They are also easy to forget, because nobody sees them the way they see a website. The good news is that most API incidents we investigate come from the same handful of gaps, and closing them is mostly a matter of discipline rather than exotic technology.
This guide is written for founders, product owners and technical leads rather than security specialists. The aim is to give you the right questions to ask your development team or agency, and a short list of controls that should be in place before any API handling customer data goes live. None of them is optional for a production system.
Authentication: proving who is calling
Every API request should be able to answer the question “who is this?” For your own web and mobile apps, that usually means OAuth 2.0 or OpenID Connect with short-lived access tokens, typically valid for minutes rather than days, and refresh tokens that can be revoked. For server-to-server integrations with partners, API keys or client credentials work, provided each partner has their own.
Tokens should carry as little as possible. A JSON Web Token can include a user ID and role, but never personal details or permissions that might change, because anything inside it stays valid until it expires. Validate every token on the server for signature, expiry and audience, and reject anything unexpected rather than trying to be helpful.
- Never put long-lived keys inside mobile apps; they can be extracted in minutes.
- Give every client, partner and environment its own credentials, so one leak does not expose everything.
- Use proven identity services such as Auth0, Amazon Cognito, Microsoft Entra ID or Keycloak rather than building your own.
- Consider mutual TLS for high-value links, such as connections to banks or payment providers.
Authorisation: the gap most APIs miss
Knowing who is calling is only half the job. The API must also check, on every request, whether that caller may access that specific record. The most common serious flaw on the OWASP API Security Top 10 is broken object-level authorisation: a logged-in customer changes an order number in a request and sees someone else’s order, address and phone number.
The fix is unglamorous: check ownership in the backend for every resource, write automated tests that try to access other users’ data, and never trust identifiers sent by the app alone. Admin functions deserve separate roles and, ideally, separate endpoints that ordinary tokens simply cannot reach.
Watch what your API returns, too. Many apps receive whole customer records, including phone numbers, internal notes or national ID fields, and simply hide them on screen. Anyone inspecting the traffic can see everything. Return only the fields each screen genuinely needs, and treat the response as public to whoever made the request, because effectively it is.
Logging in proves who you are. It should never prove what you can see.
Rate limits and abuse protection
Without limits, a single misbehaving script can overload your servers, scrape your entire product catalogue or try thousands of passwords a minute. Rate limiting caps how many requests a key, user or IP address can make in a period, returning a 429 status with a Retry-After header when the limit is reached.
Limits should be generous enough for real users and partners, and tighter on sensitive actions. Start with sensible defaults, watch the logs for a few weeks and adjust, rather than guessing once and forgetting. Tell partners their limits clearly in your documentation.
OTP endpoints deserve special attention in this region. Attackers abuse unprotected “send code” buttons to trigger thousands of international SMS messages, and the bill lands with you. API gateways from AWS, Azure and Cloudflare, or tools such as Kong, make these limits straightforward to apply consistently.
Payment endpoints need one more safeguard: idempotency keys. If a customer taps “Pay” twice on a slow connection, or the app retries after a timeout, the same key ensures the charge happens once. Gateways such as Stripe and Checkout.com support this natively, and your own order APIs should follow the same pattern to avoid duplicate orders.
Keeping secrets out of the wrong places
Database passwords, payment gateway keys and partner tokens leak most often through code repositories, shared documents and chat messages. Store them in a secrets manager such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager or HashiCorp Vault, and load them at runtime. Scan repositories automatically with tools like Gitleaks or GitHub secret scanning, and rotate keys on a schedule and immediately after anyone leaves.
Separate your environments properly as well. Development, staging and production should each have their own keys and databases, and real customer data should not be copied into test systems without masking. Many leaks start in a forgotten staging server with production credentials and no monitoring, left running long after the project that needed it.
Finally, log every authentication failure, permission denial and rate-limit hit, and alert on unusual spikes. Regulations such as the UAE and Saudi PDPL expect you to detect and report breaches, which is impossible if nobody is watching. A yearly penetration test focused on your APIs is money well spent.
If your API is built by an agency or freelancer, ask them to walk you through each of these controls before launch and to document where secrets are stored and who can access them. A good partner will welcome the questions; one who cannot answer them clearly is telling you something important.
The bottom line
API security is not a single product you buy; it is a set of habits built into every endpoint. Get authentication, authorisation, rate limits and secrets right from day one, and you avoid the vast majority of incidents we see. Retrofitting them after launch is always possible, but it is slower, costlier and usually prompted by something unpleasant.
