How to Secure an API: Authentication, Authorization, Token Lifetime, Rate Limiting and Monitoring Guide

You have a dealer portal, a mobile app and three marketplace connections. All of them walk through the same door, the API (application programming interface), to reach your data. When that door is built wrong once, the problem does not show up on one screen but across the whole system: someone else's order becomes visible, a leaked key goes unnoticed for months, an attacker keeps guessing passwords for hours. API security is the work of designing that door up front: who can open it, for what, for how long and within which limits.

In this guide we explain what API security is, the difference between authentication and authorization, how token lifetime narrows risk, how rate limiting slows brute-force guessing, input validation, webhook signatures, logging and monitoring, endpoint risk scoring and a pre-release checklist. The example figures are illustrative; they are not measurements of a real system or an industry average.

What Is API Security and Why Treat It Separately?

API security protects the interface through which applications exchange data with each other and with clients against unauthorized access, data leaks and abuse. It is treated apart from web page security because APIs return the data itself: a screen design does not hide them, and an attacker can skip the browser and send the request directly.

We covered what an API is and how integrations are built in our API integration guide. Here the subject is how to keep an API, built or about to be built, sound. Most security problems come not from sophisticated attacks but from ordinary mistakes such as missing permission checks, responses that return too much data and leaked keys; the OWASP API security list collects these common weaknesses and works well as a checklist.

We recommend reading: Our integration service: marketplace, e-invoice and shipping

What Is the Difference Between Authentication and Authorization?

The two are often confused. Authentication answers "who is sending this request?" and authorization answers "is this person allowed to do this?" If every authenticated user can see every record, the system is unsafe, and this is the most common API weakness.

The choice should match the risk: an API key may be enough for an internal report endpoint, while an endpoint returning customer data needs a short-lived token and scope checks. No method solves the permission problem on its own; permission rules are written separately.

Which Layers Does a Secure API Request Pass Through?

Sending every request through the same ordered gates stops security from depending on one person's attention. Order matters: traffic is encrypted first, then identity is verified, then permission is checked, input is matched to a schema, rate and size are limited and the result is written to the log.

Collecting these gates in a shared layer, for example an API gateway, instead of rewriting them on each endpoint reduces both mistakes and maintenance. When a new endpoint is added, the layers apply automatically and no gate is forgotten.

How Is Authorization Built Correctly?

Authorization works at two levels. At the role and scope level the question is "can this user read orders?" At the object level it is "does this order belong to this user?" When the second is forgotten, a user can change the order number in the address bar and see someone else's order; this is the most common form of API flaw.

• Deny by default: Anything not explicitly allowed is refused.
• Check object ownership on every request: Query by the identity in the token, not by a value sent from the client.
• Keep scopes narrow: "Read orders" and "create orders" are separate scopes; a reporting tool is not given write access.
• Separate admin endpoints: Administrative actions sit behind a separate path, role and extra verification.
• Limit the response: Return the fields the client needs, not the whole database object.

Writing role and permission design during requirements is far cheaper than adding it later; we cover the approach in our software requirements analysis guide.

How Does Token Lifetime Narrow the Risk?

A stolen token acts as an identity for its holder until it expires. That is why access tokens are kept short-lived; for a long session a separate refresh token is used, and that token is stored only in a safe place.

Example (illustrative): when a 24-hour token leaks, the attacker looks authorized for a whole day. With a 15-minute token the same leak is useful for a quarter of an hour at most, and once the refresh token is revoked no new token can be obtained. The price of a short lifetime is that the client renews the token more often; this happens automatically and the user does not notice.

Keys should be rotated regularly and revoked immediately when an employee leaves or a leak is suspected. A key accidentally written into a source repository counts as leaked even if deleted, because it stays in history, and it is replaced.

How Does Rate Limiting Slow Brute-Force Guessing?

Rate limiting caps how many requests a client can send in a given time. It makes guessing attacks such as password or verification-code guessing expensive, and it stops a misbehaving client from flooding the server.

Example (illustrative): a 6-digit numeric verification code has 10⁶ = 1,000,000 possible values. If 1,000 requests per second can be sent, every combination is tried in 1,000,000 ÷ 1,000 = 1,000 seconds, about 16.7 minutes. When the same endpoint is limited to 100 requests per minute, the time grows to 1,000,000 ÷ 100 = 10,000 minutes, about 6.9 days. Add an account lock and an alert after 5 failed attempts and the guessing ends at 5 tries.

• Limit per key and per address: A limit by address alone is not enough against a distributed attack.
• Be stricter on sensitive endpoints: Login, password reset and code verification need low limits.
• Inform with a 429 response: Tell the client when to retry so legitimate clients can wait.
• Limit request size too: Very large bodies can exhaust memory.

Why Are Input Validation and Output Limiting Needed?

Every value from the client is untrusted. Field type, length, format and the allowed range are defined in a schema, and a request that does not match is rejected before processing. This also filters out malicious input that is trying to slip into a database query.

• Run queries with parameters: Never paste user input directly into query text.
• Reject unexpected fields: A client must not be able to send and change fields such as "role" or "amount" itself.
• Keep error messages plain: Details such as stack traces and database names are not shown outside; they go to the log only.
• Limit file uploads: Type, size and content are checked, and the file is not stored in an executable location.

The output side needs the same care. If a product list endpoint also returns internal fields such as cost and supplier, a dealer can see them. Defining and testing response fields per role prevents this kind of leak; we describe the testing approach in our software testing guide.

How Are Webhooks and External Connections Secured?

With webhooks the roles reverse: an external system sends a request to your API. If you do not verify that the request really comes from the expected source, anyone can send a fake order or payment notice.

First-attempt success and duplicate records with external systems are also tied to security; the approach that prevents processing the same event twice is described under duplicate invoice prevention in our e-invoice integration guide.

How Do Logging and Monitoring Catch an Attack Early?

An attack with no record goes unnoticed. For every request, time, identity, endpoint, result code and client address should be recorded; passwords, tokens and personal data themselves must not be written to the log. Once you know normal behavior, the records are used to spot the abnormal.

Example (illustrative): an API receives about 20,000 requests a day and normally about 1% of them return an unauthorized (401) result. If one day 1,200 requests return unauthorized, the rate is 1,200 ÷ 20,000 = 6%, six times normal. This could be brute-force guessing or a leaked client; an automatic alert should go out when the threshold is crossed.

• Indicators to measure: Unauthorized response rate, number of requests hitting the rate limit, error rate per endpoint, traffic at unusual hours.
• Alert thresholds: Defined as multiples of the normal rate and tuned over time with real data.
• Protect the logs: Limit write access and store them so they cannot be altered.
• Retention period: The period for logs that contain personal data is set according to the relevant regulation; consult a legal adviser for details.

We recommend reading: What is business intelligence (BI)? From indicators to decisions

Which Endpoint Should You Secure First?

Not every endpoint carries the same risk. To spend effort on the riskiest ones first, scoring likelihood and impact on a 1–3 scale and multiplying gives a good first ranking.

In the example the login and order endpoints come first with 9 points; rate limiting, object-level access and monitoring go there first. The scoring is updated over time: a new feature or a new type of attack changes the ranking.

What Is the Pre-Release API Security Checklist?

Tick the items below at every major release. Every item answered "no" is a hole to close.

• Is all traffic encrypted with a current TLS version, and is plain connection closed?
• Does every endpoint have authentication, and are open endpoints open by a deliberate decision?
• Is object ownership checked on every request against the identity in the token?
• Is the token lifetime short, and can the refresh token be revoked?
• Are secrets kept out of source code and logs, in a secrets manager?
• Do login, password reset and code verification endpoints have a rate limit and account lock?
• Is input validated against a schema, and do responses return only the necessary fields?
• Are webhook requests verified with signature and timestamp?
• Is every request logged, and are alerts defined for unusual rates?
• Are security tests and permission tests part of the release flow?

What Are Common Mistakes in API Security?

• Leaving permission to the interface: Hiding a button does not block access; checks are made on the server.
• Taking identity from the client: Trusting the user ID in the request opens the door to someone else's data.
• Writing keys into source code: A secret that enters the repository counts as leaked.
• Issuing tokens that never expire: A key that leaks once stays valid forever.
• Leaving an old version open: An unused old endpoint gets no security updates and becomes the weakest link.
• Exposing error details: A stack trace gives an attacker hints about the system.
• Postponing monitoring: Without records an incident cannot be investigated afterward.

Security is a design decision, not a post-release task; recovering data after an attack is a separate subject covered in our data backup guide.

Recommended reading: What is microservices architecture? Monolith difference, cost and decision guide

Recommended reading: What Is Role-Based Access Control (RBAC)?

Recommended reading: Cloud vs On-Premise Software

Building Secure APIs and Integrations with İnovabil

At İnovabil we write APIs and integrations specifically for your business: marketplace, e-invoice, shipping and ERP connections, dealer portals and mobile app back ends. We write the security requirements, meaning role-based permissions, audit logs and secure hosting, into requirements analysis from the start and proceed with incremental development and acceptance testing.

We built a shipping system for Kredili Kargo, a purchasing system for İZBAN and a CRM, purchasing and mobile app for Avcılar İnşaat, and delivered logistics, warehouse and dispatch solutions for Karyak, Sleepy and Bofigo. If you want to review the security of an existing API or build a new integration securely, describe the flow in a few sentences; we first put the risk list and priorities in writing.

We recommend reading: Our software development process: from analysis to release

Frequently Asked Questions