‍The Critical Importance of Testing Internal APIs: A Holistic Approach to Cybersecurity‍

In the rapidly changing digital connectivity landscape, organizations increasingly depend on Application Programming Interfaces (APIs) for smooth communication between various software components. While testing public-facing APIs is a common practice and a crucial step in ensuring the security and functionality of digital systems, the importance of testing internal APIs is often underestimated. In this article, I aim to highlight the potential risks of overlooking internal API testing, especially in the context of data security and the challenges posed by relying solely on perimeter security measures.

Commencing with public-facing APIs in the testing process is a logical choice. Public APIs serve as the entry points to an organization's digital ecosystem, interacting with external systems, applications, and third-party services. Consequently, they are more susceptible to external threats and unauthorized access attempts. Organizations can prioritize public API testing to fortify their external defenses, thwart potential cyber threats, and safeguard sensitive information from unauthorized access.

However, the sequence in which APIs are tested should not be arbitrary, especially when dealing with critical data such as the Payment Card Industry (PCI), Protected Health Information (PHI), or Personally Identifiable Information (PII). These types of data demand heightened security measures, making it imperative to test internal APIs thoroughly. Focusing on these internal APIs early in the testing process ensures that the most sensitive data is protected from the outset, preventing potential vulnerabilities from being exploited.

One significant challenge to relying solely on perimeter security, such as firewalls, is that it is not foolproof. If you take a house and an alarm system, you will usually have sensors on doors and windows. Those are the equivalents of firewalls.  In my home, I also have motion sensors. The motion sensors provide additional defense in case the outer layer is passed.  There are two main challenges with relying on network perimeter or access security—the first lies in the assumption that a secure perimeter guarantees the safety of internal APIs. In reality, if an attacker manages to breach the perimeter, there is no internal layer of protection for the APIs. The second fold of this challenge is even more complex – perimeter protection is insufficient in mitigating threats posed by internal actors, specifically employees with malicious intent.

What happens when internal APIs go untested? Breaches like the one Optus faced occur. Optus had a publicly exposed endpoint that required no authentication, allowing attackers to get in. It resulted in 11.2 million customer records including driver’s license numbers, phone numbers, date of birth, etc., being exposed. 

Testing internal APIs emerges as a vital line of defense against external and internal threats. By conducting comprehensive assessments of internal APIs, organizations can identify and rectify vulnerabilities before they are exploited. This proactive approach significantly reduces the risk of data breaches and ensures compliance with regulatory standards, providing reassurance about its effectiveness.

In conclusion, testing internal APIs is not just a best practice but a strategic necessity for maintaining a robust cybersecurity posture. While starting with public-facing APIs is a logical entry point, prioritizing internal API testing is essential for safeguarding critical data. Perimeter security measures, while necessary, should be complemented with internal testing to address the two-fold challenge posed by potential breaches. In an era where digital threats continue to evolve, organizations that prioritize internal API testing demonstrate a commitment to data security, regulatory compliance, and overall resilience, underlining the urgency of adopting this practice.

‍