How to Secure Business APIs

Consider a multi-location salon and gym chain with one central booking API behind its staff app, its customer app and a partner integration. Before any specific control, list every endpoint, the data each one touches and the category of caller meant to reach it, plus a named owner for each. Unlisted endpoints stay unprotected.

Forgotten endpoints are a classic weak spot: an old app version or a testing build leaves one exposed long after everyone stopped using it. Retire what nobody uses.

Draw the trust boundary on that list. Mark callers inside your control, such as the staff app, and callers outside it, such as the customer app, because outside callers get the strictest checks.

Authentication asks who is calling. Authorisation is a separate, later question: may this authenticated caller see or change this specific record, or only records belonging to their own branch? A receptionist at one branch, correctly logged in, must not be able to pull another branch’s customer list by editing an ID in the request.

The gap is named broken object level authorisation, and OWASP ranks it first in its 2023 API Security Top 10, ahead of authentication failures. Every endpoint that accepts an ID and returns or changes data tied to it needs an explicit check that this caller may touch that particular record. Being logged in is not enough. Sequential booking numbers invite enumeration: someone changes one number to the next and reads a stranger’s appointment, and random UUIDs slow that guessing without replacing the ownership check.

Validate every value that arrives from outside, whether it is a booking date, a branch ID or a search term, against what the endpoint expects. Trust no value because of the session. Prefer an allowlist of accepted values, such as the branch codes that exist, over a blocklist of known bad ones, because a blocklist is always one step behind.

Keys and secrets must never ship inside a browser or mobile app, because anything delivered to a client device can eventually be extracted. Keep them server-side in a secrets manager or environment configuration, rotate them when staff leave, and revoke any that appear in a code repository. Rate limiting caps what one account can request in a period, which contains a compromised login or a scraping bot without anyone watching a screen. It also slows brute-force guessing.

Keep error messages plain. A response that prints a database error or file path hands an attacker a map, so show callers a message and keep the detail in the server log.

Logs help you diagnose faults. Redact them before writing. They must never record card numbers, passwords or other sensitive fields in plain text, because log files are often guarded less carefully than the main database. Set a retention rule too. Old logs full of customer details are a liability, so decide how long they are kept, who may read them and when they are deleted for good.

A pentest probes the API with hostile input, and it belongs only on a system designated for testing, with written authorisation from the business that owns it. Never test live production without sign-off.

An API sits on frameworks and libraries that receive security patches, and a known flaw in an outdated dependency is a common way into an otherwise sound system. Treat patching as a monthly job with a named owner, because a task nobody owns after launch week quietly stops happening while old libraries pile up.

Write the plan early. It covers how a suspected breach is detected, who is told first, and how keys and sessions are revoked or rotated quickly. This is implementation guidance, not a substitute for a security or compliance review specific to your industry, so involve a qualified adviser whenever regulated data is involved.