V9_Improper Assets Management

Deepshikha Paty
DI-ASM

Inappropriate Asset Management happens when an old version of an API (say APIv1) is left running, even though the new version (APIv2) is the one in use.
The problem is that old versions don’t have the latest security features and are usually outdated, making them vulnerable.
If these old versions aren't properly removed or disabled, hackers can exploit them and get access to sensitive data or even take over the system.

Your company builds and uses APIv2 for everything, but forgets about APIv1.
APIv1 is still live on the server and may have security gaps, like leaking extra user data (balance, address).
Hackers may target the old version, which isn’t as secure as the newer one.

Example

A software team uploads their project to a public GitHub repository.
The repo contains a .env file with database passwords and secret API keys.
An attacker finds the repo, clones it, and uses the credentials to access the database.

This is an example of Improper Asset Management because sensitive assets were exposed in public repositories without proper cleanup or control.

Exposes sensitive data (like API keys, passwords, config files).
Forgotten systems (e.g., old subdomains, test servers) become easy entry points.
Unsecured APIs or files may be publicly accessible.
Increases attack surface, giving hackers more ways to break in.
Outdated or unpatched assets remain vulnerable.
Lack of cleanup after deployments or migrations leaves backdoors open.
No inventory = no protection — you can’t secure what you don’t know exists.

Delete old API versions (if they’re not needed anymore).
Ensure that only the latest version is available for users to access.
Deactivate unused APIs at the network level and ensure they can't be used.
Document everything. Don’t leave any old versions or endpoints undocumented. This is critical for keeping track of what’s available.
Separate environments for different stages of development (e.g., testing, production) to prevent accidental exposure.