The Murky Waters of API Visibility and What That Means for Your Company

Caves and Muddy Waters

The Tham Luang cave rescue, which took place in 2018, was a high-stakes operation in northern Thailand to save a youth soccer team and their coach who were trapped inside a flooded cave. The monsoon rains flooded the cave, cutting off their exit. The rescue effort involved an international team of divers, cave experts, and volunteers. Over a period of 18 days, the rescuers worked tirelessly to navigate the treacherous cave passages, pump out floodwaters, and successfully bring all 13 individuals to safety. One aspect of the rescue was that the waters were so muddy that the rescuers couldn’t see a thing – the operation was performed almost entirely by feeling their way along.

The Importance of Visibility

We often don’t associate the physical sense of lacking visibility with the same in the virtual or ethereal world, but the sense – or uneasiness due to the lack of that sense – is much the same: without the ability to “see” what’s going on in a tech stack, technologists have to feel their way along. And that experience makes everything go much slower and makes progress risky.

The inability to see what’s taking place leaves room for unnoticed, even unmitigated, attacks. This is especially true with APIs. APIs change all the time – updates, upgrades, feature releases, infra changes, hotfixes – and due to their nature of always being open for innumerable connections, they are known to be difficult to secure.

The lack of an API inventory is common and troubling. Threat actors “take advantage of APIs that are either completely unknown to an organization — shadow or zombie APIs — or APIs whose security posture is not visible, such as unmanaged or third-party APIs.”

Shadow APIs are undocumented or unofficial APIs that are not publicly documented or supported by a company or organization. The API may not adhere to security best practices, opening it up to many common API threats. These unofficial APIs can be reverse-engineered to gain access to the functionality of a service or application. They may not be officially endorsed, and their use can be seen as risky because they are not maintained, and they can change without notice, potentially breaking integrations.

Zombie APIs are abandoned, outdated, or forgotten APIs or API endpoints that were once used to serve a specific function but are no longer needed or have been replaced by newer versions. The main concern with zombie APIs is that they are not properly maintained or updated, making them highly vulnerable to exploitation.

API Visibility is One’s Best Friend

There is a way to clear the murky waters that surround API management and maintenance, and it’s a multi-faceted approach.

Identify/Inventory

This is one of the OWASP API Top Ten, specifically #9. Attackers will leverage the unknown-to-you vulnerability, gaining “unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements.”

Continuous Testing

APIs change all the time – updates, upgrades, feature releases, infra changes, hotfixes. It’s important to test, test, test.

Traffic Analysis

Understanding API usage patterns and traffic sources is valuable for capacity planning, optimizing API design, and identifying potential security threats.

Security and Access Control

API visibility also involves monitoring and controlling who accesses your APIs. Implementing authentication and authorization mechanisms, rate limiting, and API keys are essential for ensuring that unauthorized access is prevented.

Documentation and Versioning

Well-documented APIs provide a clear and comprehensive guide for developers on how to use your APIs. Good documentation helps developers understand the API’s ecosystem, including parameters, authentication methods, and usage.

Throttling and Rate Limiting

Implementing throttling and rate-limiting policies helps prevent abuse or overuse of your APIs, ensuring fair access for all users.

Secure Practices, or Expect the Unexpected

If something such as tokens is hardcoded, useful information is revealed in error messages, endpoints are hidden but not actually secured (security by obscurity), or inputs are not validated – normal users will find and use them heavily; malicious users will find them and abuse them. Don’t plan on everyone playing it safe. For many customers, technology is a tool to be used mercilessly because they expect it to handle their traffic. A company’s job is to expect that from thousands, if not millions, of people thinking the same thing. For threat actors, they’re hoping for things to wrong.

Building on Proper Policies

The above list focuses more on more specific procedures, but let’s back up a level to an overview approach, more of a policy level. Incorporating the following into the API policy will help toward better visibility.

Strategy: Focus on internal APIs first, developing viable business outcomes based on the digital strategy. This also helps with learning how to manage APIs without adding the complexity of outsourced APIs.
Incorporate org and user needs: Discover (easier said than done!) as much as possible about what everyone is looking to get out of the product and service.
Adapt: Be ready to make changes. There’s normal maintenance and planned upgrades due to customer feedback, but then there are massive technological changes and societal shifts that can cause a drastic need for sudden change.
Measurable goals (SMART): Whether spelled out like this or not, the need for goals that are Specific, Measurable, Achievable, Relevant, and Time-Bound is never out of style.
Communicate to stakeholders: Let those who have a vested interest in the product know what’s going on. Board, C-level, developers (whether internal or contracted), customers, and prospects – know who the stakeholders are and communicate.

The Key

Organizations need to embrace API visibility to avoid the pitfalls of the invisible, the inability to see the inventory, and the trepidation caused by the unknown. Does it take work? Yes. Can you do it? Yes.

About
Latest Posts

Ross Moore

Cybersecurity Support Analyst at Passageways

Ross Moore is the Cyber Security Support Analyst with Passageways. He has experience with ISO 27001, ISO 27701, and SOC 2 Type 2 implementation and maintenance. Over the course of his 20+ years of IT and Security, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds ISC2’s SSCP along with CompTIA’s Pentest+ and Security+ certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University. He is also a regular writer at Bora.