Privacy settings
We use cookies and similar technologies that are necessary to run the website. Additional cookies are only used with your consent. You can consent to our use of cookies by clicking on Agree. For more information on which data is collected and how it is shared with our partners please read our privacy and cookie policy: Cookie policy, Privacy policy
We use cookies to access, analyse and store information such as the characteristics of your device as well as certain personal data (IP addresses, navigation usage, geolocation data or unique identifiers). The processing of your data serves various purposes: Analytics cookies allow us to analyse our performance to offer you a better online experience and evaluate the efficiency of our campaigns. Personalisation cookies give you access to a customised experience of our website with usage-based offers and support. Finally, Advertising cookies are placed by third-party companies processing your data to create audiences lists to deliver targeted ads on social media and the internet. You may freely give, refuse or withdraw your consent at any time using the link provided at the bottom of each page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
API Security, OWASP, Attacks, Vulnerabilities

Improper Assets Management


What is Improper Assets Management?

We should always wonder for every API if all the current endpoint should even be available and if we maybe can't do with only allowing the API to communicate internally. To aid us we can ask ourself if this API even needs to be in production at all and who should have access to it. If the specific API does need to be in production, we can also ask ourselves if we are not using an outdated version, if there is sensitive data exposed or how the data flows throughout the application and APIs.

Improper Assets Management?

A lack of documentation is a problem that plagues many companies and this only makes things worse because an undocumented API that does not send out traffic can remain undetected for a long time.

To ease the removal of older APIs we might consider a retirement plan for APIs that are no longer needed. Another tool we have at our disposal are inventory management systems which index every API and it's version, this can be used to perform a regular inspection of the API plan.

As long as these older APIs and their libraries remain unpatched, the system will be vulnerable to Improper Assets Management.

Example Attack Scenarios

Our first example will be a scenario that I encountered in production. I was scanning the APIs with a directory brute forcer to see if I could not find anything and unsurprisingly i could not find a thing. I noticed however that I was working on version 2 of the API from the URL:


After replacing the v2 in the URL to v1 and restarting my directory brute forcing attempts I did find an admin URL


The admin interface was protected in that it could only be accessed from the internal network but this was easily fooled by adding an "x-forwarded-from" header and setting it to

Our second example comes from a third party vendor. For a new feature to work, the target had to include certain libraries which were using outdated APIs but due to imperfect asset management, our target did not have an overview of these APIs existence. These endpoints ultimately led to more functionality being exposed which had an RCE in it.

Preventive measures against Improper Assets Management?

We need to ensure we have a proper inventory management system set up that includes all the API endpoints with what is special about them, their environment and from which networks they are reachable. Also inventory third party integrations for these APIs, so we can have an overview of critical infrastructure that should be easy to consult by the people who need it.

We all know software is becoming more and more dynamic but with that also comes that we will have to review our inventory system on a regular basis and evaluate it.

Some interesting things to document could be:

  • Errors
  • Authentication flows
  • Rate limiting
  • redirects
  • CORS policy triggers

These days we can automatically generate the documentation from adopting a specification such as Open API. This will make it much harder to miss a rogue API, however still not impossible. This documentation should be available to users.

Besides what we just talked about, it really helps if you make use of external security measures such as an API firewall and we need to ensure that we install it everywhere that is exposed to production, not just the production APIs themselves; but also testing environments as they can sometimes be exposed to the internet, especially with the current pandemic and home work becoming more normal.

When it comes to data, it is important not to use production data on non-production environments and if it must be done, that we treat the endpoints with the same diligent standard as the production APIs.

When newer versions of an API are released, we should always ensure that a thorough risk analysis is done if that version contains security updates. We can wonder to ourselves what our next steps should be and how to implement them, for example if an update is really required, we might have to get it out to our customers immediately or if there is no client impact to leaving out the security fix, if it can not be postponed.


It is incredibly easy to lose track of your APIs and what versions you are running where. I can not stress the importance of keeping track of each one enough as often attackers will be looking for an entry point which could easily get deployed or that might even still be deployed from a long time ago. These entry points could lead to a much bigger issue so it's wise to only enable what is needed in a production environment. Do you want to secure your APIs? Consider the API security solution

Watch the video:


Subscribe for the latest news

February 20, 2023
Learning Objectives
Subscribe for
the latest news
Related Topics
<- ->