API Security for Mobile Apps and Integrations: The OWASP API Top 10 in Practice

Your mobile app is only the visible part. Behind every order screen, delivery tracker or sales rep app sits an API (application programming interface) that talks to your database, your ERP, your payment gateway and your courier. Attackers skip the app, study its requests and call your API directly. For an Egyptian online store, a Delta distributor with a sales rep app or a clinic booking app, API security decides whether customer data and money stay safe.

The short answer: API security means checking, on the server, who is calling (authentication), what they may touch (authorization for every object and every function), how much they may do (rate and resource limits), and what they send (input validation), while keeping integration keys on the server and logging what happens. The OWASP API Security Top 10 (2023) is the reference list, and this guide explains each item with practical examples and the questions to ask your developer.

Key takeaways

• The first risk in the OWASP API Security Top 10 (2023) is Broken Object Level Authorization: changing an order ID in a request and getting someone else's order.
• Every API request must be authorized on the server for the specific record and the specific action, not only "is the user logged in".
• Anything shipped inside a mobile app can be extracted. Payment, courier, SMS and e-invoice credentials belong on your server only.
• Rate limits and spending caps protect you from bots that abuse OTP, bookings, coupons and fake orders.
• Validate every input against a schema, and treat data from third-party APIs as untrusted too.
• Keep an inventory of every API version and endpoint, and log who accessed what.

The OWASP API Security Top 10 (2023) in plain language

OWASP publishes a separate list for APIs because they fail differently from web pages. The OWASP API Security Top 10 2023 contains:

For the wider web application list, see our guide to the OWASP Top 10 (2025) for business owners.

Broken object level authorization: the order ID example

Imagine a Cairo e-commerce app. When a customer opens "My order", the app calls GET /api/orders/10452. An attacker logs in with their own account, intercepts the request with a free proxy tool, and changes it to /api/orders/10453. If the server only checks that the token is valid, it returns another customer's name, address, phone number and basket. A script can then walk through every order number in minutes.

OWASP's API1:2023 page describes exactly this: attackers "manipulating the ID of an object that is sent within the request". Its prevention advice, in short:

• Implement an authorization mechanism based on user policies and hierarchy.
• Check authorization in every function that accesses a record using an ID sent by the client.
• Prefer random, unpredictable IDs (GUIDs) for records.
• Write tests for authorization and block releases that fail them.

What the fix looks like

The server should fetch the record with the owner in the query, for example SELECT * FROM orders WHERE id = $1 AND customer_id = $2, where the customer ID comes from the verified token, never from the request body. Random IDs make guessing harder, but they are not the fix: an ID can still leak in a shared link or screenshot. The ownership check is the fix.

Same idea for properties and functions

• Properties (API3): return only the fields each role needs. A public product endpoint should never include cost price or stock per warehouse. On updates, accept only an allowed list of fields so nobody can send "isAdmin": true or change their own credit limit.
• Functions (API5): check the role for every endpoint. A distributor's van sales app should call "create order" and "record collection", not "approve discount" or "edit customer balance". Our guide to user permissions and audit logs in ERP and CRM covers role design in detail.

Authentication and tokens for mobile apps

Most business apps use short-lived access tokens such as JSON Web Tokens (JWT) plus a longer-lived refresh token. Good practice:

• Keep access tokens short-lived, and verify the signature, expiry and audience on every request.
• Rotate refresh tokens on each use, store them hashed on the server, and revoke them on logout, password change and when an employee leaves.
• On the phone, keep tokens in the platform's secure storage (Android Keystore, iOS Keychain), not in plain files.
• For the web version of the same system, keep session tokens in HttpOnly cookies so page scripts cannot read them.
• Protect login, OTP and password reset endpoints with rate limits, and offer multi-factor authentication for staff and admin accounts. See our guide to MFA, passwords and passkeys.

If the app signs in through OAuth

If your app signs users in through an OAuth provider or your own authorization server, follow RFC 8252, "OAuth 2.0 for Native Apps" (IETF, 2017). It says public native app clients "MUST implement" PKCE, that native apps "MUST NOT use embedded user-agents" for authorization requests, and that secrets statically included in an app distributed to many users "should not be treated as confidential secrets".

Rate limits, resource limits and business-flow abuse

An API without limits is an invitation. OWASP's API4:2023 page gives a real-world style scenario: an attacker repeatedly called a password-reset endpoint that sends SMS codes, triggering thousands of paid messages and costing the company thousands of dollars within minutes. The same thing happens with OTP sign-up screens in Egyptian apps.

Limits every API should have

• Rate limiting per user, per IP and per endpoint, stricter on login, OTP, password reset and search.
• Maximum page size for lists (for example, a sales rep cannot pull 50,000 customers in one call).
• Maximum upload size and request body size.
• Spending limits and billing alerts on SMS, WhatsApp, email and AI providers.

Protecting sensitive business flows (API6)

Some abuse uses your API exactly as designed, just at scale: booking every appointment slot at a clinic in Alexandria, or creating hundreds of cash-on-delivery orders with fake addresses. Defences include limits per phone number and device, verification before high-cost actions, and business rules such as one coupon per verified phone.

Input validation, CORS and error handling

• Validate every request on the server against a schema, for example with Zod: types, lengths, formats, allowed values, and reject unknown fields.
• Use parameterized queries or a well-used ORM so input is never executed as SQL.
• Recalculate money on the server: prices, discounts, shipping and totals must never be trusted from the app.
• Configure a strict CORS policy for browser clients. CORS controls which websites may call your API from a browser; it is not authentication and does not stop scripts or mobile apps.
• Return generic errors to clients and keep stack traces in server logs only.

Integrations: payment gateways, couriers and e-invoicing

Business systems in Egypt connect to many external APIs: payment gateways such as Paymob and Fawry, courier companies for shipping and cash collection, SMS and WhatsApp providers, and the Egyptian Tax Authority's e-invoice and e-receipt systems. The rule is simple: the app talks only to your API, and your server talks to the partners.

Keys stay on the server

• Never put a payment secret key, courier API key, SMS credentials or the e-invoice integration credentials inside the mobile app or front-end code. Apps can be decompiled.
• Keep secrets in environment variables or a secret manager, not in the code repository, and give each key only the permissions it needs.
• The e-invoice digital signature (USB token or HSM) and its signing service belong on a controlled server, not on staff laptops.

Verify what comes back

• Payment callbacks: verify the gateway's signature before marking an order as paid. For example, Paymob's documentation explains that its callbacks "rely on HMAC authentication to verify Accept's identity and integrity of its data", calculated with SHA512 and the HMAC secret from your dashboard.
• Amounts and status: compare the paid amount and currency with the order on your side, and make the update idempotent so a repeated callback does not ship twice.
• Courier and partner responses (API10): validate them like user input, use timeouts, and fail safely when a partner is down.

For store-specific payment risks, see online store security beyond HTTPS.

Inventory, versions and logging

Know every endpoint you expose (API9)

Old app versions stay on customers' phones for months, so old API versions stay online too. Keep a written inventory of every API host, version and endpoint, set a retirement date for old ones, and apply the same checks to all versions. Staging APIs must not be reachable from the internet with real data.

Log for investigation, not for leaks

• Log who called which endpoint, for which record, from where, and the result, in a structured format such as Pino produces.
• Do not log passwords, tokens, full card numbers or unnecessary personal data.
• Alert on spikes: many 403 errors from one user (a sign of ID guessing), bursts of OTP requests, or unusual exports.

Logs answer "whose data was exposed?" after an incident. Our guide to breach notification within 72 hours explains the response.

API security checklist: what to ask your developer

Before launch, an independent test focused on the API is worth considering for apps that handle payments or personal data; see penetration testing vs vulnerability scanning.

How Nilex helps

Nilex designs REST APIs for web and mobile apps with these controls built in: ownership and role checks, schema validation with Zod, rate limiting, short-lived JWT access tokens with rotating refresh tokens, a strict CORS policy, and server-side payment and courier integrations where the keys never reach the app. We can also review an existing API against the OWASP API Security Top 10 and fix what we find.

Frequently asked questions

What is API security?

API security is the set of controls that protect the interfaces your apps and partners use to read and change data. It covers authentication, authorization for each record and action, rate limits, input validation, secret handling and logging. It matters because attackers can call your API directly without using your app.

What is the most common API vulnerability?

Broken Object Level Authorization is first in the OWASP API Security Top 10 (2023). It happens when the server returns or changes a record based only on the ID in the request, without checking that the record belongs to the caller.

Is it safe to put API keys in a mobile app?

No, not for secret keys. Anything shipped inside an app can be extracted, and RFC 8252 states that secrets included in an app distributed to many users should not be treated as confidential. Keep payment, courier and SMS keys on your server and let the app call your own API.

Does HTTPS protect my API?

HTTPS protects data in transit, but it does not check whether a logged-in user may see a specific order or call an admin function. Most serious API flaws are authorization and logic problems.

How do I stop bots from abusing OTP and sign-up?

Limit requests per phone number, device and IP, add cooldowns between OTP sends, set spending caps with your SMS provider, and alert on unusual volumes. OWASP lists this under API4:2023, Unrestricted Resource Consumption.

Building a mobile app or connecting your system to payment gateways, couriers or e-invoicing? Ask for an API security review or a free consultation through our contact page.