API Security Best Practices for Businesses

A junior developer at a logistics company gets a simple assignment: display order details in an internal app. He writes the endpoint GET /api/orders/12345, tests it with his own order number, and everything works smoothly. The app ships. Two months later, an auditor finds something alarming: that endpoint can be called with any number — 12344, 12346, 99999 — and the server obediently returns other people's orders, complete with addresses, phone numbers, and item values. Not a single line of code checks: "does the caller have the right to this order?"

That is API security in one sentence: the security that lives between your systems. An API (Application Programming Interface) is the pipe connecting your website, mobile app, point-of-sale system, ERP, and payment platform. Every time two systems talk, there is an API between them. And every unguarded pipe is an unlocked door.

This article is an API security guide for businesses: why APIs are prime targets, the ten biggest risks according to OWASP, best practices your team can apply, and what it costs in the Indonesian market.

Why APIs Are Prime Targets

In the past, attackers targeted websites or servers. Today, most business data flows through APIs: mobile apps talk to servers via APIs, online stores call payment gateways via APIs, accounting systems pull data from ERPs via APIs. Security reports from various vendors consistently show sharp growth in API attacks year after year — because APIs are the data highways, and many highways have unguarded gates.

Several reasons make APIs favorite targets:

• APIs are direct access to data. Unlike a website page that displays curated data, APIs often expose raw data. A single authorization gap can leak millions of rows at once.
• APIs are easy to find and map. Endpoint names are often guessable (/api/users, /api/orders), and the JSON patterns are readable. Attackers do not need to break anything to start testing.
• APIs are often forgotten in security planning. Websites get WAFs and malware scans; internal APIs often run for years without audits, including old endpoints nobody uses anymore — the so-called zombie APIs.
• Accidental exposure. APIs built for internal systems sometimes go public unnoticed, or their technical documentation leaks into public repositories.

This risk grows with integration: the more systems you connect — and we discuss the trade-offs in our article on custom software vs off-the-shelf packages — the more APIs you must protect.

The OWASP API Security Top 10

OWASP publishes a list of the ten most common and most dangerous API security risks. Here is the 2023 edition, compiled from real incidents:

1. API1: Broken Object Level Authorization (BOLA) — a caller can access objects belonging to others by changing an ID. This is the "change 12345 to 12344" gap from the opening story.
2. API2: Broken Authentication — login mechanisms that can be bypassed, tokens that never expire, or guessable credentials.
3. API3: Broken Object Property Level Authorization — a caller can read or modify data fields they should not touch (for example, changing a user's role).
4. API4: Unrestricted Resource Consumption — APIs without rate limits and quotas, so requests can flood in until the server collapses or cloud costs balloon.
5. API5: Broken Function Level Authorization — admin functions callable by regular users because authorization is only hidden in the menu, not checked on the server.
6. API6: Unrestricted Access to Sensitive Business Flows — sensitive business flows (like reservations or promo claims) abused at scale by bots.
7. API7: Server Side Request Forgery (SSRF) — the API is forced to send requests to internal addresses that should be closed off.
8. API8: Security Misconfiguration — overly permissive CORS, overly detailed error messages, missing security headers, or unnecessary HTTP methods still enabled.
9. API9: Improper Inventory Management — undocumented endpoints, old versions still alive, or staging environments exposed publicly.
10. API10: Unsafe Consumption of APIs — your system consumes third-party APIs without validating their data, letting malicious data flow in.

Of these ten, the three most often found in Indonesian business systems are BOLA, weak authentication, and misconfiguration. All three can be prevented without expensive technology — just technical discipline.

Authentication and Authorization: Two Different Things

Many teams conflate authentication and authorization, but they are different. Authentication answers "who are you?"; authorization answers "what are you allowed to do?". A secure API must have both, and both must be checked on every request.

Proper Authentication

• Use established standards (OAuth 2.0, OpenID Connect) instead of inventing your own login scheme.
• If you use JWTs (JSON Web Tokens): sign with a strong algorithm, verify the signature on every request, set a short expiry (15-60 minutes), and use revocable refresh tokens.
• Never put secret keys in mobile apps or frontend code — anything downloaded to a user's device can be unpacked.
• Rotate credentials periodically: replace API keys, do not use secrets forever.

Authorization at Every Endpoint

This is the heart of API security. Every endpoint must check two layers:

• Function level: is the caller's role allowed to call this endpoint? (for example, only admins can delete users)
• Object level: does the requested object actually belong to the caller? (for example, only the order owner can view order details)

These checks happen on the server, not in the frontend. A hidden menu is not security; attackers do not care about menus.

Other Best Practices You Must Apply

Input Validation at Every Layer

Treat all API input as untrusted. Validate data types, lengths, and formats on the server side; do not trust frontend validation. Unvalidated input is the source of SQL injection, command injection, and XSS. Use allowlists (lists of permitted values) rather than denylists.

Rate Limiting and Quotas

Limit requests per user, per API key, and per IP address. This protects against brute force, bot abuse, and ballooning cloud costs. Also enforce payload size limits — an API accepting giant files is an open door to resource exhaustion attacks.

HTTPS Everywhere

There is no excuse for APIs running without TLS in this era. Free SSL certificates are available, and all communication — including between internal systems — must be encrypted. APIs that accept plain HTTP should refuse it outright.

Manage Your API Inventory

Create a list of all endpoints: which are used, who uses them, and which versions are still active. Turn off unused endpoints. Apply versioning (/api/v1/, /api/v2/) so changes do not silently break old systems. You cannot secure an endpoint you do not know exists.

API Gateway and WAF

An API gateway sits in front of your APIs: centralized authentication, rate limiting, logging, and access control. Options range from open source (free to self-host) to managed services. An API-focused WAF filters common attack patterns before they reach the application.

Logging and Monitoring

Record every API request: who, when, from where, and the outcome. Without logs, you are blind. Monitor anomalies — request surges, odd access patterns, a flood of 401 (failed authentication) responses — and set up automatic alerts. Logs are also mandatory for incident investigation.

Secure Your Webhooks

If your system receives webhooks (API calls from other systems, such as payment notifications): verify the signature of every payload, validate the source, and handle retries idempotently — one notification must never process a payment twice.

Proper CORS Configuration

CORS controls which websites may call your API from a browser. The * (allow all sites) configuration is a habit that must stop; list only the domains you actually control.

Common Mistakes That Leave APIs Vulnerable

• Credentials in client code. API keys in mobile apps or frontend JavaScript can be extracted by anyone.
• Tokens without expiry. Tokens that last forever are time bombs.
• Error messages that are too honest. "Wrong password" vs "user not found" helps attackers map accounts; show generic messages.
• Leaked API documentation. Never upload Postman collections, Swagger files, or internal docs to public repositories.
• Public staging environments. Development environments reachable from the internet often hold test data resembling real data.
• Trusting third-party APIs. Data from external APIs must be validated like any other input — other APIs can be hacked too.

A Secure Development Lifecycle

API security is cheapest when applied from the start, not patched after an incident:

1. Design: define the authentication model, the endpoint list, and who is entitled to what — before writing code.
2. Development: implement authorization at every endpoint, validate input, and use maintained libraries.
3. Testing: beyond unit tests, run automated security scans and penetration testing aimed specifically at APIs — including attempts with manipulated IDs.
4. Release and operations: gateway, monitoring, and an incident response plan.
5. Maintenance: periodic audits, credential rotation, and cleanup of legacy endpoints.

This pattern aligns with the process we run at Kartech. — Frame, Shape, Build, Operate — where security is not a separate stage but part of every stage. If you are designing a new system or modernizing an old one, our cloud migration guide and website security guide round out the bigger picture.

Choosing an API Authentication Approach

"Use a token" sounds simple, but several approaches have different strengths:

Rule of thumb: APIs serving mobile apps use OAuth 2.0 with short-lived tokens; internal system APIs can use API keys or client credentials; payment-handling APIs deserve mTLS consideration. Whatever you choose, never build your own authentication scheme — self-made cryptography and protocols are a classic source of gaps.

APIs for Partners and Third Parties

APIs you open to partners — marketplaces, payment providers, distributors — expand your attack surface. Manage them with discipline:

• Separate credentials per partner. Each partner gets its own key with limited access scope. If one partner has a problem, you revoke one key without disturbing the others.
• Rate limits per partner. Cap request volume per key, so a compromised partner cannot flood your system.
• Written contracts and agreements. State data usage limits, the partner's security obligations, and responsibility if a leak happens on their side.
• Audit logs per partner. Record who calls what — these logs become investigation tools during abuse.
• Revoke access when the partnership ends. It sounds obvious, but many partner accesses stay alive for years after contracts expire.

APIs and the Personal Data Protection Law

APIs are often where personal data moves — and the Personal Data Protection Law regulates that movement:

• The minimization principle. APIs should return only the data the caller needs. An endpoint that sends the entire user profile "just in case" is both a bad habit and legal risk.
• Consent and purpose. Data sent through APIs to partners must match the purpose communicated to data owners. Sending data to third parties without a legal basis is a violation.
• Data subject rights. Users have the right to request copies and deletion of their data. Your internal APIs must be able to fulfill these requests — not just from the database, but from every system that received data through APIs.
• Record keeping and audits. Documented data flows between systems make it easy to answer "where did this data go?" — a question that will definitely come up during an incident.

APIs for Mobile Apps

APIs are the backbone of mobile apps: nearly all data shown on a phone screen comes from an API. Because user devices cannot be fully trusted, API security determines the app's security itself. A few things to note: tokens are stored in the device's secure storage (Keychain on iOS, Keystore on Android), not in plain text files; the app verifies the server certificate — certificate pinning is worth considering for critical APIs; and all authorization decisions stay on the server, not in the app code. An app that looks secure on screen can leak through its API, and vice versa. The two sides cannot be separated: a mobile app's security is ultimately decided by how secure the APIs behind it are.

Pre-Release API Security Checklist

Before an API goes public or serves production systems, make sure your team can answer these ten questions:

1. Do all endpoints check authorization, including at the object level?
2. Does authentication use established standards, not a homegrown scheme?
3. Do tokens have a short expiry and can they be revoked?
4. Are there no credentials in client code, public documentation, or repositories?
5. Does all communication use HTTPS?
6. Is there rate limiting and a payload size limit?
7. Is input validated on the server side for all parameters?
8. Is the endpoint inventory complete and versioning managed?
9. Is logging enabled, without recording sensitive data?
10. Have security scans and pentests been run, with critical findings fixed?

This checklist can become part of the "done" definition for every new API release. An API that passes all ten questions is far harder to break into — and far easier to account for during audits.

How Much API Security Costs

For comparison: one leaking endpoint — like the story at the start — can expose thousands of customers' data within hours, with recovery and reputation costs that no table can capture.

Audit Questions for Your Own Systems

Answer honestly:

1. Does every endpoint check object-level authorization, not just function-level?
2. Do tokens have an expiry and can they be revoked?
3. Are there credentials in mobile app or frontend code?
4. Do all APIs run over HTTPS?
5. Is there rate limiting on public APIs?
6. Do you have a complete list of active endpoints — including unused ones?
7. When were your APIs last security-tested?

If most answers are "no" or "I don't know," you are not alone — but you are also sitting on measurable risk. Closing these gaps is clear technical work that can be done incrementally, and if your internal team has never done it, an IT consultant can guide you from audit to remediation.

The Kartech. team in Bandar Lampung builds and secures APIs for websites, mobile apps, and internal systems — from authentication design to pre-release testing. If your systems are already running and have never been audited, we can start with a short assessment to map the most urgent risks. Reach us through our contact page or explore our services.

APIs are the digital nervous system of your business. Every piece of data in motion — orders, payments, customer data — passes through them. Protecting your APIs means protecting the trust you have built, one endpoint at a time.