Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer
Noname Security enters into agreement to be acquired by Akamai
Learn more
Noname Security Logo

The Role of API Security in Digital Transformation

Matt Tesauro
Share this article

Digital transformation (DX) is a technology paradigm that has proven powerful enough to survive several seasons of hype and still emerge as an enduringly valid business proposition. DX is about leveraging new digital technologies to change a company’s fundamental relationships with its customers and suppliers. It frequently means connecting legacy systems to cloud-native applications. DX implies making the IT estate “cloud ready.” With that said, application programming interfaces (APIs) play an outsized role in DX. However, the use of APIs in DX comes with a variety of API security risks that need to be mitigated for DX initiatives to flourish. 

What is digital transformation, anyway?

Digital transformation involves the use of cloud and mobile technology to redefine the customer experience. In retail, for example, DX might mean implementing an omnichannel sales and marketing relationship. The customer becomes able to engage with a retailer over the phone, using in-store kiosks, websites, mobile apps, and so forth. 

In banking and financial services, a DX project might mean adding stock trading, insurance and credit card payments to a banking app. DX in healthcare could look like enabling patients to communicate directly with care teams or seek second opinions over a mobile app. Government DX initiatives often involve linking public record systems with cloud- and mobile-based service request forms. 

Envisioning a DX program also usually posits the use of data analytics in tandem with mobility to raise a brand’s presence in the customer’s life. For example, a pet food brand may seek to transform itself into a constant pet care advisor by means of a smart mobile app that connects to a digital sensor on a cat collar. The same thought process can apply to interactions with suppliers and partners. The supply chain can be digitally transformed, as can strategic alliances. Even the employee-employer relationship is up for digital transformation as smart devices go home in hybrid work scenarios.

Ultimately, the term DX is proving itself to be incorrect. It should really be called “business transformation.” Digital technology is simply a catalyst for changing the way a company functions.

The API’s role in digital transformation

APIs are essential for DX because almost every DX idea involves linking previously separate software applications and data sources. Making an in-store kiosk talk to the mobile app, which talks to the website, which talks to the e-commerce back end, which talks to the interactive voice response (IVR) system requires having an API at every connection point. 

In healthcare, a patient-to-care-team mobile app will call on APIs to connect with internal hospital communication platforms and Electronic Health Record (EHR) systems. Government mobile apps will require APIs to expose data from public records repositories and workflow processes from government legacy systems.

APIs also come into play with financial services. A bank might undertake DX by enabling customers to access their life insurance policies through a banking app, for instance. Making this work will mean building an API call into the banking app that reaches out to the insurance company’s systems. The business processes inherent in the new banking app will invoke functionality in the bank’s mainframe-based legacy banking system via an API.

Understanding the security risks

Digital transformation initiatives create risk exposure, with APIs forming a major attack surface. This occurs for several reasons. For one thing, the architectural complexity of a DX project establishes multiple situations where a malicious actor can exploit API vulnerabilities or misconfigurations. What can go wrong? The Open Web Application Security Project (OWASP) top 10 most serious API risks presents a veritable menu of potential DX disasters. 

A DX project might expose an API with broken object-level authorization, for example, which allows unauthorized access to other users’ data. There could be excessive data exposure, wherein an API call returns more data than the API owner intended. User authentication can break, which exposes the API to requests from virtually anyone. The number of connections inherent in DX amplifies the risk that one of these vulnerabilities will result in a data breach or denial of service (DoS) attack.

Another driver of risk is the speed at which DX development is taking place. One reason DX is a viable idea in the first place is that it is now possible to write and deploy software far more quickly than was ever possible before. With Continuous Integration/Continuous Deployment (CI/CD) and DevOps, each entity involved in a DX program can release new features on a daily basis. Moving that fast is an invitation to configuration errors and other lapses in controls that protect APIs. For example, DevOps teams might be tempted to bypass security testing altogether, which amplifies risk all the more. 

It’s also worth remembering that security risk is not the only potential API issue that enterprises will face in a DX initiative. Basic API functionality is a factor as well. For DX to be viable, the APIs that power it must work as intended. That means accurate, fast responses, as well as failovers for high availability and the like.

Mitigating API risks

What can be done to mitigate API risks in DX? A number of best practices have emerged to protect APIs and the digital assets they connect to. One of the most important first steps is to build a thorough API inventory. Exposing applications to API calls from the cloud should ideally come after a full audit of existing environments for APIs. Otherwise, as the DX process kicks off cloud migration and system upgrades, it may expose unknown APIs to invocation from malicious actors. This, in turn, can lead to data breaches. Being cloud ready in DX should not mean exposing APIs to such risks. 

This is not as easy as it sounds, if one lacks the right tools. Some IT managers have the erroneous view that API gateways automatically track every API in the IT estate. This is not always true. Indeed, a great many “rogue” APIs can be running loose in the wild, so to speak. 

Reasons for this include APIs that were launched but abandoned. Or, someone thought they were switched off but no one remembered to do it. There are “shadow APIs” that enterprising people put up, but fail to tell anyone about. Other unknown APIs are older versions of APIs that also never got taken offline. 

The process is known as “API discovery.” The goals are to know what APIs are out there, where they are hosted and what data they handle. The challenge is to execute API discovery efficiently. Companies doing DX by migrating from a legacy gateway could find it takes as long as 40 hours per API to get the information they need for the inventory. 

Given that an organization doing DX might have hundreds of APIs, the costs can be astronomical. Discovery tools like Noname Posture Management are able to perform API discovery using automated processes. They efficiently catalog APIs, enabling DX projects to accelerate to completion. 

Next comes API governance. Any API that’s needed for integration in a DX project has to be subject to carefully thought-out governance policies. These might include controls like data encryption in transit, security tokens, rate limiting, and more. 

API governance requires policy enforcement and monitoring in addition to policy definition. If one specifies encryption as a policy, for example, but has no way to enforce the policy—and cannot check to see if data is being encrypted as required—then the policy has little value as a security countermeasure. Contracts are a related area of control. For sure, if an API involves two corporate entities, there must be a legal agreement governing its use. Even inside the same organization, it is still a good practice to come to clearly understood agreements between API providers and consumers. 

API security testing is critical for success with DX. APIs must be tested for the OWASP vulnerabilities and other security weaknesses that can expose the organization to cyberattacks. The best practice is to implement API testing as early in the software development life cycle (SDLC) as possible, a strategy known as “shifting left.” The API security testing should also integrate with CI/CD processes to ensure that insecure APIs do not get rushed out into production without anyone knowing. Functional API testing is also recommended.

As APIs go into production as part of a DX project, they should be monitored continually for performance and security problems that can negatively affect the success of the DX strategy. If an API is running slowly or is targeted by attackers, the relevant system owners need to be alerted as soon as possible. 

These are a few of the security issues that come up when contemplating the use of APIs in digital transformation. DX and APIs go together, so it’s a wise practice to make API security a key element of a DX project. To avoid addressing API risks in DX is to court serious risks.

To learn more about API security and the Noname API Security Platform, please schedule a demo.