March 3, 2022

Last Updated on January 19, 2024

The rapid growth of APIs has led to significant security risks. Unless you have been marooned on an uncharted coral atoll for the last five years, you realize that the term application programming interface (API) has leaked into near everyday conversation. (Perhaps my view is a bit distorted by my immediate family, which includes three other engineers besides me, but I digress…)

An API is a computing interface that defines and enables interactions between different pieces of software.  APIs are the magic you use every day to share media on social platforms, bank online, and interact with Alexa. The rise of APIs in recent years can be seen in the explosive increase in API folders on Postman, a collaboration platform for API development, from under 500,000 in 2016 to nearly 35 million in 2020.

Unfortunately, our security practices have not evolved as rapidly, and API-related breaches are on the rise. Gartner has predicted that APIs will become the most significant security vulnerability ever.

 

Most projects are now “API-first”

One of the main drivers of API growth has been the proliferation of microservices, which are small applications/functions that communicate using APIs.  This “API-first” approach yields greater flexibility, reduces development cycles, and is highly scalable.

Today most new development of conventional “web applications” leverages APIs (you may hear the term endpoints) to provide the functionality to a simple web interface (you may hear the term single page). Due to the nature of APIs, they are easy to expose but difficult to defend. This generally results in more attack surface area being exposed compared to old-school web applications.

What happens if you “get it wrong”?

Managing risk across the hundreds of API-supported assets found in any given organization is not a trivial task, and the impact can be notable, especially if they relate to critical controls like user authentication.  For example, user authentication API vulnerabilities led to the exposure of 50 million Facebook accounts in 2018. Hackers used a vulnerability in the API providing video upload functionality to steal account access tokens.

Securing APIs requires a strategy

Securing APIs requires a robust strategy based on trusted frameworks and supported by a trusted ecosystem. Here are the basic steps to get there:

  1. Get a clear picture of where you are now and where you are going. What information are you processing?  Where is the business going? What laws and regulations apply? What contractual obligations apply? What technologies and languages are in play?  What threats/risks do we need to protect against? How mature are our current security practices?
  2. Now that you know what you need to make application security a business enabler, you can build a strategy to act as the set of guiding principles to get you there.  Ensure that you use trusted frameworks like OWASP ASVS, OWAS SAMM, ISO 27001, etc.). Frameworks simplify long-term solutions, enable personnel, minimize rework, and ensure that you have the respected proof you need to demonstrate to critical stakeholders that your applications are secure.
  3. Build an actionable plan. What needs to happen over the next 3 to 132 months? What risks are not yet acceptable? What controls need to be improved? What documentation needs to be developed?  What are the repeatable processes that need to happen to ensure that our applications are secure?
  4. Repeatable information security processes require the right people (qualifications, experience, availability) and the right products to operationalize effectively. That’s where a trusted ecosystem of people and tools is key. It shortens time to target and minimizes the risk of a wrong turn, especially when aligned with your trusted frameworks.
  5. Ensuring that your information security controls operate on schedule and have the intended effect is essential.  Getting this information into an easily consumable format (e.g., a dashboard) creates a single source of truth for all key stakeholders.
  6. Independent and objective assessment is a hallmark of a great information security program.  You may want to test the application (OWASP ASVS), infrastructure (CREST), SDLC (OWASP SAMM), and the overall cyber security program (ISO 27001).
  7. The right testing aligned with trusted frameworks ensures that you have the respected proof you need to prove to key stakeholders (regulators, board, clients, CXO suite) that you are secure.

So, you can spell Security with API – it just isn’t easy :>)