End-to-End Security for APIs: From Development Through Retirement

Akamai acquired Noname Security in June 2024. This archived blog post was originally published on October 5, 2022.

Properly securing application programming interfaces (APIs) is a process that goes well beyond security. It’s also about IT operational and architectural issues that drive security outcomes. To be successful, API security must be viewed as an end-to-end process covering the full software lifecycle. It starts with development but continues through runtime and end of service.

API security forces us to challenge some old assumptions. One may assume, for example, that software development ends with the deployment of code into production. This is no longer true. Software development now outlives the basic process of writing code.

Development is a continuous process embodied in the concept of continuous integration and continuous deployment (CI/CD). In tandem, software comes into existence through DevOps, which blends the previous sequential steps of software development (Dev) and deploying software into products by IT operations (Ops).

Today, as soon as a piece of code gets deployed into production, the DevOps team is busy getting ready to deploy another iteration of the application. That next deployment could be an hour later. With DevOps, Dev is Ops, it seems. The operational side of the process is no longer distinguishable from the development side. Security for applications must therefore span the connected stages of Dev and Ops.

Additionally, modern software is more than just code. It’s also a set of connections among components like microservices, APIs, code libraries, and the like. Keeping APIs secure means understanding how these connections work, where they are, and how they can be vulnerable to malicious actors. This requirement, too, transcends regular security practices to include operational tasks like creating API inventories and monitoring API traffic.

API security must be active at the development stage of an application’s life, at runtime, and beyond – through the entire software development lifecycle (SDLC). Starting with development, developers may instruct applications to invoke API functionality through API calls or create APIs that expose the app’s functionality and data to other software applications. Both modes of API operation create risk exposure.

API security risks occur for a variety of reasons, but many have to do with problems in API configuration that affect user authentication and authorization. A misconfigured API might allow an unknown user to access sensitive data. Alternatively, a mistake in configuration could enable a user to get data beyond what is permitted. Other configuration issues can allow an attacker to overload the API with calls and execute a denial-of-service (DoS) attack. 

At development

API security testing can mitigate such API risks at the development stage. The testing needs to be specific to APIs, because general-purpose application testing will not catch issues like API misconfiguration. Instead, a dedicated API security testing suite needs to identify API vulnerabilities and facilitate their remediation before software gets deployed.

To work, API security testing has to be positioned early in the development process, which is known as the shift-left approach. The testing suite must integrate with the CI/CD pipeline, as well. Otherwise, the security remediation process will be too cumbersome for DevOps team members to handle.

At runtime

At runtime, API security means blocking threats in real time. This takes API security monitoring. An API security solution has to stay on top of API traffic and alert admins when it notices anomalous behavior or attack signatures. Alternatively, the solution may take the extra step to automatically block the API when it detects a threat.

API runtime security is relatively straightforward. However, it only works if the API security solution knows where all the APIs are. To be secure, APIs must be subject to API posture management, which involves the process of API discovery. It’s impossible to defend an API that is invisible to the security solution, which is why APIs must be inventoried. API discovery is necessary, too, because API gateways and web application firewalls (WAFs) do not automatically inventory all APIs in an environment, despite what people may think.

Rogues, zombies, and shadows: Oh my!

The API discovery process inevitably leads to IT admins being surprised to find that their environments contain many “rogue,” “zombie,” and “shadow” APIs.

• A rogue API is an API that somehow was lost over time. It may be an old version of an API that never got switched off. It might be an API exposed on a commercial packaged software application that no one knew about. 
• A zombie API is a functioning API that is off the radar screen. 
• A shadow API is created by someone who takes it upon themself to build APIs, but doesn't inform the IT department.

All three types of undiscovered APIs generate risk exposure. Security policies cannot be applied to them because they are invisible. If they are not configured for security — and they are almost always misconfigured or lacking in patches — they will allow improper access to attackers.

It can be challenging to know what to do with previously unknown APIs. If they are going to continue operating, they need to be brought into compliance with policies regarding configuration, authentication, and so forth. Shutting off a just-discovered API may be the best choice, but this can cause problems.

For instance, if an earlier version of an API is still in use, despite being superseded by its replacement, turning it off could cause applications to break. Someone could get in trouble for making the decision to take the API offline. What’s needed is a toolset that gives admins the information they need to make the right decision.

Executing API security on an end-to-end basis requires having the right tools. An effective end-to-end API security solution will be one that can handle API security testing, API runtime security, and API security posture management and inventorying. One needs to take a critical look at existing tooling, as most WAFs and API gateways do not cover development, testing, runtime monitoring, and inventory.

The API security solution should also ideally operate in ways that don’t affect the network or API performance. For example, Akamai API security solutions work by monitoring a copy of network traffic. They can spot API calls in this copied network traffic, identifying unknown APIs and security threats in the process.

API security must cover all phases of an API’s life, from development through runtime and retirement. Security comes in part from processes that are not technically about security, such as API inventories. Because unknown APIs create risk exposure, identifying them makes their applications more secure. It’s an end-to-end proposition. The more complete the API security measures are, the more secure the entire environment will be.