Your application may hide the administrator button perfectly.

That does not help if an ordinary account can call the administrator’s API endpoint directly.

APIs carry requests between interfaces, servers, and connected services. Because they expose business operations and data, their security needs to be enforced where those requests are processed.

A useful API security checklist covers authentication, authorisation, input handling, resource limits, configuration, external integrations, monitoring, and repeated testing. Passing a checklist supports security; it does not prove an application is secure.

You might also be interested in: Common Mistakes to Avoid When Starting Out with Tech

1. Know which APIs exist

Record production endpoints, older versions, administrative routes, and external integrations. Assign an owner.

Remove retired endpoints. An abandoned version can remain accessible long after the team stops thinking about it.

2. Separate identity from permission

Authentication establishes who is making a request. Authorisation determines what that identity may do.

Check permissions for each operation, record, and sensitive field. Logging in should not grant access to every customer’s data.

3. Test access between accounts

Create two test users with separate records. Confirm that one cannot read, edit, export, or delete the other’s information.

Random identifiers make guessing harder, but they do not replace permission checks. Object-level authorisation is a central concern in the OWASP API Security Top 10.

4. Validate tokens and protect credentials

Use maintained authentication libraries. Validate token signatures and required claims, including issuer, audience, and expiry.

Keep secret API keys out of browser code and public repositories. Plan how credentials will be rotated or revoked.

5. Require HTTPS

Protect credentials and data in transit. Avoid sending secrets in URLs, where they may enter logs or browser history.

6. Validate inputs and control outputs

Set accepted types, sizes, and values. Use parameterised database queries.

Return only fields the caller is entitled to receive. Reject attempts to update protected properties such as roles or ownership.

7. Limit resource consumption

Apply appropriate request limits, upload limits, pagination, and timeouts.

Pay special attention to endpoints that send SMS messages, generate reports, or trigger other paid operations. A small request can create a large bill.

8. Protect business rules

Check the required sequence of sensitive actions on the server.

For example, an order should not become “paid” because a browser submits that status. Refunds, discounts, and inventory changes also need explicit rules.

9. Treat external services as untrusted

Validate third-party responses and authenticate incoming webhooks. Where relevant, detect duplicate or replayed events.

If an endpoint fetches a user-supplied URL, restrict destinations and block access to internal services. This helps address server-side request forgery.

10. Review browser-facing controls

Configure CORS for intended origins, but remember that it is not an authorisation system. Non-browser clients are not constrained by browser CORS enforcement.

For cookie-authenticated requests, implement appropriate CSRF protection. OWASP provides further guidance on transport, access control, validation, and configuration in its REST Security Cheat Sheet.

11. Keep useful, privacy-conscious logs

Record authentication failures, denied access, privileged actions, and unusual activity. Avoid logging passwords, full tokens, or unnecessary personal data.

Make sure someone receives and investigates meaningful alerts.

12. Repeat security checks after changes

Add permission tests to your normal release process. Review dependencies and configuration, and arrange deeper assessment when the application’s risk warrants it.

A practical place to begin is the action that would cause the most damage if misused: exporting customer records, changing access rights, issuing refunds, or deleting data.

Test that action with the wrong account, missing credentials, and an invalid sequence. Security often becomes clearer when you stop asking whether the feature works and start checking who can make it work.