Your mobile app, your web front end and your partner integrations all talk to APIs. Attackers know that the user interface is just decoration: the API is where the data lives. Here are the flaws we find most in API security tests.
1. Broken object-level authorization (BOLA / IDOR)
The flaw: the API checks that you are logged in, but not that the record you asked for is yours. Change /api/orders/1045 to /api/orders/1046 and you are reading someone else's order.
Why it's so common: developers test the app through its interface, where you can only click your own records. Attackers call the API directly.
The fix: check ownership or permission on every request, on the server, for every object. Use unpredictable identifiers as an extra layer, never as the only protection.
2. Weak authentication and token handling
The flaw: tokens that never expire, JWTs signed with weak or default secrets, signature checks that can be skipped, API keys embedded in mobile apps, or password-reset flows that can be abused.
The fix: use proven libraries rather than custom code, short-lived access tokens with refresh tokens, strong secrets stored outside the code, and strict validation of every token.
3. Returning far more data than the screen needs
The flaw: the app shows a name and a profile picture, but the API response also contains the email, phone number, date of birth and internal flags, and the app simply hides them. Anyone watching the traffic sees everything.
The fix: design responses for what each client needs, and filter data on the server, never in the app.
4. No rate limiting
The flaw: nothing stops a script from trying thousands of passwords, OTP codes or coupon codes per minute, or from downloading your whole customer list one record at a time.
The fix: limit requests per user, per IP address and per sensitive action, lock or slow down repeated failures, and alert on unusual volumes.
5. Mass assignment
The flaw: the API accepts whatever fields the client sends and writes them to the database. Add "role": "admin" or "balance": 100000 to a profile update and the server happily saves it.
The fix: explicitly define which fields each endpoint may change (an allow-list), and never bind requests directly to database models.
Honorable mention: forgotten APIs
Old versions (/v1/ still running next to /v3/), test endpoints and undocumented admin APIs often have none of the protections added later. Keep an inventory of every API you run, and retire what you don't need.
Building it right from the start
Every one of these flaws is cheaper to prevent than to fix. Our secure development team designs authorization in from day one, and our API testing finds what slipped through, role by role and endpoint by endpoint. Ask us about testing your APIs.
