Application Development

The future for APIs - how management and security will have to come of age

This is a contributed piece by Stephen Singam, Managing Director - Security Research at Distil Networks


In September, Google announced that it would acquire Application Programming Interface (API) management company Apigee for $625 million. Red Hat acquired API management company 3Scale the month before. Forrester predicts that companies will invest around $3 billion in controlling their APIs over the next five years.

Is there anything further that we can learn from this investment by Google? And what should we all bear in mind for the future?


Where APIs are developing more in company IT strategies

APIs change how companies make their IT infrastructure available and re-usable. As enterprises shift from huge, monolithic software edifices toward simpler applications, APIs are the connective tissues that link these services together and make them work.

Many APIs have to be public and available to other providers or customers, and this is expanding. ProgrammableWeb listed over 15,460 open APIs, with a growth rate of around 23 percent annually.

However, IT organisations are not managing their own operations to keep pace with these changes in how systems are designed. Internally, divisions across IT such as between software development, operations and security can lead to problems over time.

Taking a consistent approach to APIs, from initial creation through to daily management and eventual decommissioning, is therefore important. Whoever owns the API management interface will therefore play a considerable role in enterprise IT strategies over time.


Why APIs are not secure today

A major part of this management role is security. Every month, new software vulnerabilities are found and APIs are not immune to these flaws either. Looking at the Common Vulnerability and Exposures list, 80 flaws in APIs have been reported for 2016 so far. These vary from small irritations through to serious vulnerabilities that can jeopardise customer data.

Business Logic Flaws can also jeopardise security. For example, the US Internal Revenue Service has an online service based on an API called GetTranscript. This used personally identifiable information to route calls for data by individuals. However, as this PII can be found on the black market or stolen, the API could be abused.

The gaps that exist between internal IT teams can lead to issues not being fixed. Research by Ovum pointed to problems here, with 53 percent of respondents stating that the security team should lead on this topic while 47 percent believing that the software development team handling APIs would be responsible.

Alongside nailing down the responsibility for these potential problems, this includes managing the response that IT teams should take when there are attacks on their APIs. For internal APIs, the response includes looking at what the attacks are targeting and how to stop the problem.

Simply turning an API “off” is one approach; the issue with this is that it stops legitimate traffic from accessing the API as well. Categorising attacker traffic and blocking this from interacting with the API is a more fine-grained approach, but relies on a more intelligent approach to rating requests.


How to make APIs “secure by design”

Alongside protecting API requests and stopping automated attacks, it’s worth putting time and effort into designing APIs from scratch to be secure. This can be a good opportunity for developers, IT operations and security professionals to apply best practice steps from all three disciplines.

For example, security teams will design IT services so that any activity outside scope is denied. This will minimise the potential attack surface area for the APIs involved. This approach may not be one that developers normally take as it can limit potential choices and deployment options for the application. Looking at design principles like OWASP’sSecurity By Design can therefore help all members of the team to be on the same page.

Good principles for API security include not automatically trusting external services and managing separation of roles. As APIs may have to be publicly available to work, security by obscurity is not an approach that can be maintained.

Basic steps like authorisation and rate limiting can stop attacks on APIs, while more advanced behavioural analysis can sense when automated bot attacks are taking place as well. By working across teams like this, it’s possible to improve security against “bad” traffic to the API while also maintaining efficiency and letting “good” traffic continue.


The future for enterprise APIs

As companies continue to expand their use of APIs, management of these interfaces will be critical. The likes of Google are moving into the management space around APIs to take advantage of this trend.

However, the role of security around APIs will also have to change over time too. This will be based on better security management, more mature processes and greater collaboration between all the internal and external teams that make use of APIs.


« Quotes of the week: "The crime scene of tomorrow will be the internet of things."


Three insights to make Agile development work for you »
IDG Connect

IDG Connect tackles the tech stories that matter to you

  • Mail


Do you think your smartphone is making you a workaholic?