API Security Checklist for Business Applications

By Grocito13 October 2026

API security means making sure only the right people and systems can call your APIs, and that each call can only do and see what it is allowed to. The essentials are strong authentication, an access check on every request, input validation, rate limiting, encryption in transit, careful secrets handling, logging, an inventory of every API and regular testing by qualified people.

Key takeaways

APIs expose your data and actions directly, so attackers target them heavily.
Authentication proves who is calling; authorisation decides what they may do. Both must be checked on every request, at the object and function level.
Limit what each token can do, rotate secrets and never put keys in code or logs.
Return only the data a client needs, and rate limit to blunt abuse.
Know every API you run, including old and forgotten ones, and retire what you no longer need.
Test regularly, and treat the OWASP API Security Top 10 as a useful reference list.

Why APIs are a prime attack surface

An API is a front door for software. It is documented, predictable and often reachable from the internet, which makes it convenient for developers and for attackers. Mobile apps, websites, partner integrations and internal tools all rely on APIs, so one weakness can expose customer records or let someone trigger actions such as refunds or account changes.

Unlike a web page, an API often returns raw data and trusts the caller to ask for sensible things. Security therefore has to be built into the API itself, not assumed from the interface in front of it.

Authentication and authorisation

These two words are often mixed up.

Authentication answers: who is this caller?
Authorisation answers: what is this caller allowed to do?

Object-level access checks

This is broken access control in plain words: a logged-in user changes an identifier in a request, for example from their own order number to someone else's, and the API returns the other person's order because it only checked that the user was logged in. Every request that touches a specific record must confirm that this caller is allowed to access that record.

Function-level access checks

Some actions are for administrators only, such as exporting all users or issuing refunds. The API must check the caller's role for each function, not rely on the admin button being hidden in the interface.

Good practice

Use established standards and well-maintained libraries rather than inventing your own login scheme.
Require multi-factor authentication for administrative access.
Give tokens short lifetimes and a way to be revoked.
Deny by default: if no rule permits it, refuse it.

Input validation

Treat every input as untrusted, including data from your own mobile app and from partners.

Define what each field may contain: type, length, format and allowed values.
Reject anything that does not match rather than trying to repair it.
Use safe database access methods so inputs cannot alter queries.
Limit the size of requests and uploads.
Validate on the server. Checks in the browser or app are a convenience, not a defence.

Rate limiting and abuse prevention

Without limits, an attacker can try thousands of passwords, scrape your whole catalogue or overwhelm the service.

Apply rate limits per user, per key and per address.
Use stricter limits on sensitive endpoints such as login and password reset.
Add lockouts or delays after repeated failures.
Watch for unusual patterns, like one client requesting thousands of different record numbers.
Consider limits on expensive operations such as search and exports.

Transport encryption

All API traffic should use HTTPS with a current, properly configured certificate. Redirect or block plain HTTP, and keep certificates renewed. Encryption in transit stops others on the network from reading or altering requests. Also consider encryption of sensitive data at rest.

Secrets management and key rotation

API keys, tokens, passwords and certificates are the keys to the building.

Never store secrets in source code, shared documents or chat messages.
Use a secrets manager or the secure configuration features of your hosting platform.
Use a separate secret for each environment and each integration.
Rotate secrets on a schedule and immediately if one might have leaked.
Remove access promptly when someone leaves or an integration ends.
Scan code repositories for accidentally committed secrets.

Least-privilege tokens and scopes

A token should carry only the permissions needed for its job. A reporting tool that reads orders should not be able to edit them. Use scopes or roles to express this, and create separate credentials per application so that a leak affects as little as possible. The same principle applies when connecting AI tools to your systems, as discussed in our guide to connecting AI models to your CRM safely.

Excessive data exposure and over-fetching

A common mistake is returning an entire database record and relying on the client to display only part of it. Hidden fields such as internal notes, other users' details or password hashes can be read by anyone inspecting the response.

Return only the fields each client needs.
Define explicit response formats rather than dumping whole objects.
Mask sensitive values such as full card or identity numbers where they are not required.
Review responses for fields that should never leave the server.

Logging and monitoring

You cannot respond to what you cannot see.

Log authentication events, access denials, errors and administrative actions.
Include who, what, when and from where, but never log passwords, tokens or unnecessary personal data.
Send logs to a central place that attackers cannot easily alter.
Set alerts for spikes in failures, unusual volumes and access to sensitive endpoints.
Decide in advance who responds to alerts.

Versioning and deprecating old endpoints

Old API versions often lack newer protections but remain reachable. Version your API, announce retirement dates to consumers, monitor who still uses old versions and switch them off when ready. An endpoint that nobody maintains is a liability.

Keep an inventory of all APIs

You cannot protect what you do not know exists. Shadow APIs are endpoints built quickly and never documented. Zombie APIs are old ones that should have been retired. Keep a living list of every API, who owns it, what data it handles, which environments expose it and when it was last reviewed. Include test and staging systems, which are often less protected but may hold real data.

Third-party API risk

Your application depends on other providers, such as payment, email and mapping services, and their security affects yours.

Review what data you share and whether you need to share it all.
Store third-party keys carefully and limit their permissions.
Validate data returned by third parties before trusting it.
Plan for outages and handle their errors gracefully.
Read the provider's security documentation and incident notifications.

Testing: reviews, scans and penetration tests

Combine several approaches.

Code and design reviews that look specifically at access checks and data exposure.
Automated scans for common weaknesses and outdated components.
Penetration testing by qualified people who try to break in as an attacker would, carried out with written permission and an agreed scope.
Regression tests for access rules, so a later change cannot silently remove a check.

The OWASP API Security Top 10 is a widely used list of the most common API weaknesses and is a helpful reference when planning reviews and tests. Your own website needs similar care, covered in our website security checklist for business owners.

The checklist

Every request is authenticated and authorised, at object and function level.
Access is denied by default.
Inputs are validated on the server.
Rate limits and lockouts protect sensitive endpoints.
All traffic uses HTTPS.
Secrets live in a secrets manager and are rotated.
Tokens have narrow scopes and short lifetimes.
Responses contain only the fields needed.
Security events are logged without sensitive data, and alerts are monitored.
Old versions are retired on a published timetable.
There is a current inventory of every API.
Third-party integrations are reviewed.
Reviews, scans and expert testing happen on a regular basis.

A worked example

Imagine a company with a customer portal and a mobile app that share an orders API. A tester logs in as one customer, changes the order number in a request and receives another customer's order. The API checked login but not ownership. The fix is an ownership check on every order endpoint, along with a regression test. While reviewing, the team also finds that the response includes internal staff notes, an old version of the API that is still reachable and a long-lived key stored in a configuration file. They trim the response, retire the old version, move the key to a secrets manager and rotate it. None of these steps needed new products, only attention and discipline.

FAQ

What is API security?

It is the set of practices that protect an API from misuse, such as verifying callers, limiting what they can do and see, validating inputs, encrypting traffic and monitoring activity.

What is broken object level authorisation?

It happens when an API lets a user access another user's data by changing an identifier in a request, because it did not check ownership. It is one of the most common and serious API weaknesses.

How often should APIs be tested?

Test during development, after significant changes and on a regular schedule. Exact frequency depends on the sensitivity of the data and any requirements that apply to your sector.

Do small businesses need API security?

Yes. Any application with an API holds customer data or business actions worth protecting, and automated attacks do not choose targets by size.

Next steps

Start by listing every API you run and picking the one that handles the most sensitive data. Review its access checks, responses and secrets this month. If you want help designing or reviewing secure integrations, see our API services or contact us.