API Security Checklist: Auth, Rate Limits and Logging

Most API breaches are not clever. A user changes an order number in a request and sees someone else's invoice. A login endpoint accepts a million password guesses. A debug log quietly stores access tokens. If you are building or inheriting an API, a practical API security checklist helps you close these gaps before a customer, a partner or an attacker finds them.

This guide follows the structure of the OWASP API Security Top 10 (2023) and turns it into checks your team can run: authorisation, authentication, rate limits, input handling, configuration and logging. It ends with a checklist table you can paste into your release process.

What is API security, and why do APIs get attacked?

API security is the set of controls that make sure only the right callers can read or change the right data through your API, at a rate and in a shape you expect. APIs are attacked often because they expose business logic directly, they are documented by design, and a mobile app or website shows attackers exactly how to call them.

Three facts shape how you should approach it:

• Your frontend is not a security layer. Hiding a button does not stop someone from sending the request by hand.
• The API is the product's real boundary. Web, Android, iOS and partners all go through it.
• Security bugs are usually logic bugs. Missing ownership checks cause far more damage than exotic exploits.

Are you checking authorisation for every object?

Check on the server that the logged-in user is allowed to access the specific record in every request. OWASP lists broken object level authorisation as API1:2023, and describes it as endpoints that take an object ID without verifying the caller's right to that object.

This is the single highest-value check on the list. Make sure you cover three levels:

• Object level: can this user read invoice 1042? Check ownership or membership, not just that they are signed in.
• Property level: can this user change this field? A customer should not be able to send "role": "admin" or "price": 1 in an update body.
• Function level: can this role call this endpoint at all? Admin and internal routes need their own checks.

OWASP also warns that comparing the user ID in a token with an ID in the request is not enough on its own, because it covers only a small set of cases. Build one reusable policy layer, such as middleware in Node.js or policies in Laravel, and write automated tests that try each role against each route. Using unguessable IDs reduces enumeration but does not replace the check.

How should you handle authentication and tokens?

Use proven libraries and standards for authentication, and validate every token fully on every request. OWASP's broken authentication risk covers weak passwords, no brute-force protection, tokens in URLs and unvalidated tokens.

A solid baseline looks like this:

1. Never put tokens or passwords in URLs. They end up in logs, browser history and referrer headers. Send them in headers or secure cookies.
2. Validate JWTs strictly. RFC 8725 says applications should specify the algorithms they accept, tie each key to one algorithm, and reject tokens that fail any cryptographic check. Also check the issuer, audience and expiry.
3. Keep access tokens short-lived and use refresh tokens that can be revoked when a device is lost or a user logs out everywhere.
4. Treat password reset and OTP as login. OWASP advises applying brute-force, rate limiting and lockout protections to credential recovery too.
5. Store passwords with a slow, salted hash such as Argon2id or bcrypt, never with plain hashing, and check new passwords against known weak ones.
6. Offer multi-factor authentication for admin and finance roles at minimum.

For OTP flows common in India, cap OTP attempts per number and per device, expire codes quickly and never reveal whether a mobile number is registered.

How do you apply rate limits and resource caps?

Limit how often and how heavily each client can call every route, and set the strictest limits on authentication and anything that costs you money. OWASP calls this unrestricted resource consumption: requests need bandwidth, CPU, memory and storage, and paid services such as SMS and email are billed per request, so abuse can mean downtime or a large bill.

Apply limits in layers:

When a client goes over the limit, return 429 Too Many Requests with a Retry-After header, as defined in RFC 9110, so well-behaved clients know when to retry. Behind a load balancer, make sure your limiter reads the real client IP and not the proxy's.

How should you validate input and shape responses?

Treat every incoming value as untrusted, accept only what you expect, and return only what the client needs. This closes injection bugs and the excessive data exposure that comes from returning whole database rows.

• Validate against a schema for every request: types, lengths, formats and allowed values. Your OpenAPI contract is a good source for these rules.
• Use an allow-list for writable fields. Never pass a raw request body to your database layer, which is how mass assignment bugs happen.
• Use parameterised queries or your ORM's safe methods, never string-built SQL.
• Return explicit response fields. Do not send password hashes, internal IDs, flags or other users' data because the model happened to contain them.
• Check outbound calls. OWASP also flags server-side request forgery and unsafe consumption of third-party APIs, so validate URLs you fetch and treat data from partners as untrusted.

If your API design is still in progress, our guide to REST API design best practices covers contracts, error formats and pagination, all of which make validation simpler.

What belongs in configuration, secrets and inventory?

Keep secrets out of code, lock down defaults and know every API you run. OWASP lists security misconfiguration and improper inventory management as separate risks, because forgotten test endpoints and old API versions are common entry points.

1. Store secrets in environment variables or a secrets manager, rotate them, and never commit them to Git.
2. Force HTTPS everywhere and set a strict CORS list instead of allowing all origins.
3. Turn off debug mode, stack traces and verbose errors in production.
4. Keep an inventory of every API host, version and owner, and retire old versions on a published date.
5. Separate environments. Staging should not hold real customer data or production keys.
6. Update dependencies on a schedule and run an automated vulnerability scan on every release.

What should you log, and what should you never log?

Log enough to reconstruct what happened, and never log secrets. Good API logs answer who called what, when, from where and with what result, without becoming a second place where sensitive data leaks.

Log these for every request: a request ID, timestamp, authenticated user or client ID, route, status code and duration. Always log login failures, permission denials, rate-limit hits, password and role changes, and admin actions.

Never log passwords, full tokens, OTPs, card numbers or full request bodies containing personal data. Return the request ID to the client in error responses, so support can find the exact failure without exposing internals.

Logs only help if someone looks at them. Set alerts for spikes in 401, 403 and 429 responses, and rehearse an incident once: who is told, who can revoke keys, and how do you contact affected users. The Digital Personal Data Protection Rules, 2025 notified in November 2025 require data fiduciaries to take reasonable security safeguards and to report personal data breaches, with obligations phasing in over eighteen months. Logs and a rehearsed process make that reporting realistic. Confirm exact dates and duties with a legal adviser.

API security checklist you can reuse before every release

Use this table in your pull request template or release checklist:

If you are still choosing a stack for these controls, our comparison of Node.js vs Laravel for backends shows how each handles authentication, validation and background jobs.

How Arham Technology approaches API security

Our backend development service builds security into the design instead of adding it at the end. For each project we follow the same steps:

1. Domain and threat sketch: we map entities, trust boundaries and the abuse cases that matter for your product, such as one customer reading another's data.
2. Contract first: OpenAPI or an equivalent contract is agreed, including auth requirements and error formats.
3. Core services build: authentication, authorisation and primary workflows ship with automated tests around the rules that must never break.
4. Integration and load checks: third-party adapters use retries and idempotency, and key paths are exercised under expected load.
5. Runbook handover: deploy steps, logging notes and incident basics are documented for your team.

We build in Node.js and Laravel. If you are handling subscriptions, customer accounts or multiple tenants, our SaaS development service applies the same controls to tenant isolation and billing flows.

Next step

If you already have an API in production, start with an authorisation review of your ID-based endpoints and a check of your login rate limits. If you are planning a new product, agree the security rules before the first endpoint is written. Learn more about our backend development service or contact us with your endpoint list, and we will suggest a practical plan.