APIs help businesses become truly digital. No matter what your application is, an Application Programming Interface (API) connects it with other software or functionality – saving time in building them from scratch.
Now the reason why APIs are given special focus is because of the level of impact they carry on a business’s success.
Business benefits of APIs
Now, I am sure you must be wondering why the list of API security best practices is different from that of traditional security. Let’s answer that next before we look into the top API security risks and how to mitigate them.
The key elements of API security design which differentiate them from traditional security
There is a vast difference between traditional web app security and web API security best practices – a difference that comes because of how they are structured.
A castle with no moat and multiple openings – Earlier, traditional networks only had to be protected in common ports like 443 (HTTPS) and 80 (HTTP). Today, web apps come with multiple API endpoints which use different protocols, so when an API expands its feature sets, managing its security gets difficult.
Frequently changing incoming request formats – APIs constantly evolve under a DevOps environment, most of the WAFs are unable to accommodate this extent of elasticity. Thus, whenever an API changes, the traditional security measures have to be reconfigured and tuned manually – an error-filled method that takes up resources’ time.
Clients may not use a web browser – A majority of the microservice APIs are used on mobile applications or software components. Because the clients do not use the browser, web security tools are unable to use the browser verification functionality and detect harmful bots.
This difference in API structure opens it up to several API security risks, deeming it critical for the web app developers and QA team to find solutions and improve API security in real time.
The top API security risks and how to mitigate them
Before we get down to the risks, let me tell you that the API security checklist is not definite. You think you have solved all the loopholes and new ones will come up. The solution to this lies in stepping in hackers’ shoes and relooking at how your app uses API and the gaps that are overlooked.
While this is a long-term, continuous solution, a good starting point will be to look into the most common API security risks.
1. Insecure pagination
Most of the APIs offer access to the resources which are the list of entities like users or widgets. For a client using the software on a browser, the API would typically filter out and paginate this list to restrict the number of items that are returned to the client.
However, if the entity comes with PII or some other information, a hacker would be able to scrape the endpoint and get a list of all the entities in the database. This can be very dangerous if the entities expose sensitive information accidentally. It will also lead to hackers being able to view your web app’s usage stats and get access to the email lists.
Solution: In order to secure against the pagination attacks, one should be able to track the number of items of a single resource which can be accessed within a specific time period by a user or an API key instead of at the request level. By measuring the API resource access at individual user level, you will be able to block the API key or user after they meet a threshold like “touched 10,000 items in one hour”.
2. Insecure API key generation
Most of the APIs are generally secured through JWT (JSON Web Token) or API key. This enables you to protect your API as the security tools are able to identify abnormal behavior and then block access to API keys. However, the hackers can still outsmart these approaches by getting and utilizing a massive pool of API keys from users, exactly like how a web hacker would make use of IP addresses to hinder DDoS protection.
Solution: The sure-shot way of securing these attacks is by needing a human to sign up for the service and then generate the API keys. On the other hand, the bot traffic can be saved with elements like 2-Factor Authentication and Captcha.
3. Accidental key exposure
The way API keys are used open it up to instances of hacks and leakages.
- The APIs are engineered to be obtained over an indefinite period, which raises the chances of a hacker obtaining an API key which has not expired.
- The user of an API comes with a direct access to the web app’s credentials like when debugging it through CURL or Postman. Following this, it only takes an accident for the developer to copy/paste the CURL command with the API key in a public forum such as Stack Overflow or GitHub Issues.
- API keys are typically bearer tokens that don’t require any identifying information. The APIs are not able to leverage elements like 2-factor authentication or one-time use tokens.
Solution: The way to safeguard key exposure is by using two tokens in place of one. Here, a refresh token gets stored as the environment variable and can be used for generating short lived access tokens. Unlike these refresh tokens, developers can use short lived tokens that can access resources, but only for a limited time period.
4. DDoS attacks
While it’s true that APIs open new business models where the customers can access the API platforms programmatically, this makes DDoS protection challenging. Most of the DDoS protection is engineered for absorbing and rejecting requests from bad actors during the DDoS attacks. This becomes harder in case of API products as every traffic ends up looking like bot traffic.
Solution: The API security best practices in this context lies within the API only. Every access to the web app requires an API key, so when you come across a request which doesn’t have an API key, you can reject it automatically.
5. Wrong server security
When it comes to maintaining good server hygiene, APIs are not very different from web servers. Data can easily be leaked because of a misconfigured SSL certificates or through non-HTTPS traffic.
In the case of modern-day web apps, while there is little reason to accept the non-HTTPS requests, a customer might accidentally issue a non-HTTP request from their web app or CURL, thus exposing the API key.
Solution: Best practices for API security state that you should test the SSL implementation over a SSL test tool. Moreover, you should block out the non-HTTP through the load balancer.
6. Insufficient logging
Most of the global breach studies find that the time period to identify a data breach instance is more than 200 days. If there is a lack of defined API security best practices for API logging in place, hackers can use the vulnerability to create more vulnerabilities.
Solution: You should make sure that the API logging mechanism you use doesn’t just track the API requests but also link it back to the users for behavior analysis and store it for at least a year. These mechanisms, in turn, should be secured to ensure that the data doesn’t get deleted.
7. Not handling authorization
While a majority of API developers add a global Authentication method like OAuth or API keys to verify who is the user, it is difficult to create and keep Authorization different from Authentication.
Since authorization is specific to the app’s logic, it is an area that developers miss on when testing the web app. Now, unless the object identifiers have sufficient entropy, hackers can easily test different ids via iteration and enter the system.
Solution: Make sure that the user you have authenticated is authorized to access resources needed for generating the API response. This may include checking it against access control lists (ACL) linked with the objects in the picture.
Here were the seven most common API security risks and their solutions that a web app developer and entrepreneur come across. But like we mentioned before, this list if not definite, many more loopholes can come up as your web app gets older and the API’s features expand.
Parting notes
As businesses continue to transform their monolithic systems into microservices, APIs will keep getting prone to vulnerabilities. This makes following native and cloud API security best practices mandatory.
The list that we mentioned above, while is a good place to start, requires constant upgradation. Keeping on top of them can be a challenge for entrepreneurs and their in-house development teams which already juggles multiple deadlines. This is where partnering with a company that has a track record of delivering 100% hack-proof apps comes into picture.
0
