Nov 21, 2025 – Jeremy Snyder – Hackers preparing to launch a DDOS attack on a vulnerable server‍OWASP API Security Top 10 3-5Article 2 of 4 see this article for the first in the series‍We can admit it, security gets in the way of software development pretty often. It can get in the way of your organization’s mission. Good security practices will help you avoid damage to reputation, and maintain a consistently secure & smooth experience for your users. But on the other hand, it can also make it feel as if solving your customers’ problems must include jumping through circus hoops just to check the boxes required by this compliance standard or that. At the developer’s level, and within the context of an API, security best practice recommends the use of a contract. You, the developer, describe how your API works, and customers or users consume that API according to what is defined in your contract.Allow me to illustrate my point with a little scenario about the following example endpoint: /api/users/{userId}/bookmarks/{bookmarkId}A junior backend developer is tasked with handling a new property to store a new rideshare app’s user bookmarked addresses, which are usually their home and their work addresses.The frontend team has already developed the mechanism by which a user can save those properties in-app, and users can see their saved addresses when they look to book a ride.Now, if an API contract were being enforced, the backend would state the exact conditions under which that data could be manipulated and returned to the frontend: (a) when the user creates or modifies the saved address data with a POST, or PATCH call, or (b) when the user requests this data with a GET call because they’re about to book a ride in the app.There should be no other scenario in which this personal identifiable information (PII) should be returned to the front end.Our app and junior backend developer do not enforce an API contract. They live on the cutting edge, security isn’t their jam, and it’ll only slow them down anyways. So, while they did get that new address bookmarking feature to work without a hitch, they forgot to implement a few security best practices, which has unfortunately led to…‍3. Excessive Data Exposure‍The marketing team had a great idea. They want to show the world how diverse the rideshare app’s user demographics are, so they’re having the public website show a rotating feed of user first names and the city they’re from. Innocent enough, sure. Despite the marketing folks only needing user first names and cities, the app’s backend services are returning entirethe whole user objects. It’s easier to develop that way, bring back all the data, and cherry pick the few fields that you actually need to use. Well, the extra data is still there. It’s a few clicks away for someone with very basic technical knowledge. And unfortunately for our rideshare company, the extra user data contains some pretty sensitive info like that new field reserved for bookmarked addresses. Suddenly, it’s not a fun new little addition to the website, it’s a user data breach.What could have been done to prevent this? A couple things…Handle data sanitization on the server side. Only return what’s needed. You’ve the expression “need to know”? Since tThe website doesn’t need to know about a user’s PII, cut it out before it’s sent back as part of an API response.Maintain an API contract and make sure it’s being enforced. The contract should have stated that user bookmarks are for specific scenarios that don’t include the public website.‍4. Lack of Resources & Rate Limiting‍The junior backend dev has learned their lesson, data will be sanitized, and a contract will be enforced.The rideshare market is competitive. Sometimes, international competition can play a little less than fairly. A rideshare app whose servers aren’t responding is unable to compete. If your API is being hit with calls that are making the servers unavailable, you’ve done something wrong with the design of your API.Denial of Service (DoS) attacks like these have made the news on more than one occasion. It’s the hacktivist collective’s favorite technique because it’s visible and can easily make a big public relations splash.If a request can make a call for an unlimited number of records from your database, and your server tries to fulfill that request, it’s going to affect the performance of the database, and all the services that depend on that database.Additionally, if a malicious user can send your server a 2 terabyte “jpeg” as their user profile picture, and your server doesn’t handle that gracefully, it’s probably going to have an effect on service availability for legitimate users.This is where rate limiting, pagination, and a transparent API contract come in.Rate limiting will prevent users from sending requests at a rate that is too quick for your backend to handle. Pagination will allow users to slow down their access to your databases by returning a different set of results with each request (items 1-99, then items 100-199, etc.) A clear API contract will mean users, including the team responsible for handling the client side, are aware of the limitations of interaction with the API.It’s difficult to be completely safe from DoS attacks. Even more so distributed denial of service. Hackers can easily change which IP and device ID they’re pinging your servers from, making it difficult to differentiate between a legitimate request and a fake one. For now, suffice to say that the more visibility you have on incoming requests, the more it will be possible for you to catch the ones intending you harm.‍5. Broken Function Level Authorization‍Each API call made to a server is received and processed by a specific function in the application. Before executing their code, functions evaluate the metadata that’s been passed along with each API request. This data includes information like who is making the request, what type of request is being made, and where the request should be going.The user who requests a ride is the only one who should be able to interact with the function that handles payment processing for their account. The driver should not have the ability to mock a user API call to the same payment processing function and change how much they are being paid for the fare.However, if the Principle of least privilege is not being applied to properly define the scope of user-allowed actions, then application functions are vulnerable to broken function level authorization exploits. To avoid this, developers must develop an extremely granular access control system to define who is allowed to do what:As a rider, I can modify how much I leave as a gratuity for a ride I have taken.As a driver, I can view how much was left for me as a gratuity for a ride I have given.Unfortunately, it is a lot easier to write an application that treats all users the same, without making the distinction between the modify or view scope of permissible action on a gratuity, than to write an application that does.Read on to learn about the rest of the OWASP API top 10

*** This is a Security Bloggers Network syndicated blog from FireTail - AI and API Security Blog authored by FireTail - AI and API Security Blog. Read the original post at: https://www.firetail.ai/blog/the-absolute-beginners-guide-to-api-security-2