Such client-side apps interact with centralised servers via an Application Programming Interface (API). In essence, APIs make it easy for a developer to create a client-side app without needing to change anything on the server.

However, because they’re often available over public networks, APIs are typically well documented or easily reverse-engineered. Also, because they are highly sensitive to denial of service (DDoS) type attacks, APIs are attractive targets for cybercriminals.

For this reason, ensuring effective API security is vital and must be a high priority for any organisation making use of them within their IT infrastructure.

APIs come in a variety of forms and sometimes the style of an API affects how security is applied to it. For example, before web APIs, the standard style in use was SOAP Web Services (WS). During the service-oriented architecture era from 2000 to 2010, XML was ubiquitous, and a rich set of formal security specifications were widely recognized for it. 

Meanwhile, the SOAP style of security is applied at the message level using digital signatures and encrypted parts within the XML message itself. Decoupled from the transport layer, it has the advantage of being portable between network protocols, however it has fallen out of favour and is mostly encountered only with legacy web services.

Representational state transfer (REST) became the more common API security style over the past decade. REST is often assumed by default when the term “web API” is used. A fundamental convention of the REST style of APIs is that resources are uniquely identified by HTTP URIs. This predictable aspect of REST APIs inspired a generation of access control methodologies in which rules are associated with the URI (resource) being accessed.

Yet another API style is GraphQL, an emerging open-source API standard project. GraphQL is popular with front-end developers because it puts them in control. They’re no longer restricted to a fixed set of API methods and URI patterns but instead get to customize their queries in whichever ways best suit their applications and context. Because of this added control—and additional benefits like non-breaking version upgrades and performance optimizations—GraphQL is on its way to becoming omnipresent among web APIs.

While GraphQL isn’t a substitute for REST, and both API styles will continue to co-exist, it’s an increasingly common choice. In fact, its popularity is threatening to disrupt a decade of web API access control infrastructure. This disruption centres on one major divergence from the popular REST pattern: GraphQL requests do not identify the data being accessed via the HTTP URI. Rather, GraphQL identifies the data requested using its own query language, typically embedded inside an HTTP POST body.

Layers of API Security

Because of the large number and diverse nature of APIs, maintaining effective security is challenging. There are a range of layers that need to be considered to ensure that protection levels are achieved and maintained at all times.

Firstly, it should be remembered that you can’t secure what you’re not aware of, and there are many obstacles that prevent security staff from having full visibility into all exposed APIs. There may be API silos in place which affect visibility by having partial lists of APIs under disconnected governance.

Another obstacle to API security is the rogue or shadow APIs. These happen when an API is developed as part of an application but the API itself is considered an implementation detail of the application and is only known by a close-knit group of developers. Shadow APIs are not on the radar of security operatives because they don’t have visibility into the implementation details.

A third challenge is that APIs go through their own lifecycle. Each evolves over time, with new versions emerging. An API may even be deprecated but still continue to operate for a temporary period for backward compatibility and then be forgotten or gradually fall off the radar because they receive very little traffic.

API discovery is a race between API providers and hackers who will easily exploit vulnerabilities when they are found. To discover your APIs before an attacker does, one option is to mine API traffic metadata. This data is extracted from API gateways, load balancers or directly inline of network traffic and then fed to a specialised engine which reports on an effective list of APIs. This can then be compared with catalogues of APIs that are available via an API management layer.

Being aware of these challenges is a vital part of achieving effective API security. Take the time today to discover and review all APIs being used within your organisation to ensure that vital applications and data stores remain safe at all times.