The explosion of APIs in recent years shows no sign of slowing down, becoming the glue that increasingly connects so many services in a world focused on the programmable web, mobile apps, containers, the cloud, and microservices. Software is being broken into a much larger number of smaller pieces: it took us 40 years for the first 500 million apps to be developed - the next 500 million will be created by 2023.
APIs have spawned a whole new ecosystem of tools and techniques to help ensure that they are managed effectively, including a strong focus on API security. There is now a definite shift towards looking more at securing the entire API lifecycle, particularly during the development stage, and for good reason. First, one of the reasons many companies use APIs is precisely because they provide a controlled route through which to share critical data – including with third parties. This makes it doubly important that the API itself does not introduce vulnerabilities and cannot easily be breached.
Second, in common with so many other areas of software creation, development is the stage at which the majority of vulnerabilities are introduced.
This can then lead to a future risk of malicious attacks, unauthorised access, and exposed data. Teams are understandably focused on creating a great user experience, enhancing performance, and building impressive features. While arguably changing, security has traditionally never been top-of-mind for developers.
The problem is that once an API is published and a problem becomes apparent, there is little or no time to take remedial action. To give this some perspective, as soon as a website is published, it is likely to be subjected to attack within hours – that is the nature of today’s world. The same is true with APIs, and not only external or public-facing APIs: securing the APIs within an organisation or private ecosystem is just as important. This is why API security needs to become a priority mindset, and not something that gets sorted further along the delivery process. APIs put corporations at risk of putting their data in the public domain.
Some industries have a bigger focus on ‘security first’ API management than others. For instance, the introduction of the open banking standards in the UK has put the spotlight on the need to secure the vast volume of APIs connecting financial firms and their customers. While giving consumers faster and more flexible payment options, open banking standards could potentially put their data at more risk unless APIs are properly protected. A bank might have thousands of its own APIs and over 10,000 within its supply chain. That is a lot of APIs to control, escalating the number of ingress points for would-be attackers and creating a far bigger landscape for fraud and data breaches.
To add further fuel to the challenge, the nature of APIs means that more people have the ability to create them. These developers may have different levels of experience, and in many cases, work at third-party consultancies or design agencies outside the host organisation. While most in-house teams have had the need for more robust security processes drummed into them by now, this may not a central focus for their suppliers, who are often small but talented teams focused on creating great software. Add in the fact that they are usually under pressure to deliver an API quickly, it is easy to see how errors can occur.
This is why, when it comes to improving API security, a first step is to engender the right culture, starting with making everyone involved aware of its importance and their roles in mitigating risks. Security needs to be a priority, not second on the list to functionality. It goes without saying that this should apply to external contributors as well as in-house teams.
It is also worthwhile to invest in training developers on API security issues and equip them with the basic knowledge to protect against these vulnerabilities. Most notable are the OWASP Top 10, which includes: injection, broken authentication, sensitive data exposure, XML external entities (XXE), broken access control, security misconfigurations, cross site scripting (XSS), insecure deserialisation, using components with known vulnerabilities, and insufficient logging and monitoring.
Next up is to create all the processes that will support a more secure API development environment. These processes need to be comprehensive across deployment policies and approval workflows across users, groups and roles. They should also cover authorisation, authentication, rate limiting, message content security, malicious patterns detection, and other security policies.
Nominate people who must review any API before it is launched, with time-stamped approval, typically enabled through manual intervention combined with automation within the Continuous Integration/Continuous Delivery pipeline. That process should also have a clear audit trail, particularly in regulated markets such as banking. Should something go wrong, it is then possible to trace the original cause and take remedial action so that the same problem is not repeated in the future.
Next, measures need to be put in place to ensure that those security policies and processes are automatically and consistently enforced across all current and existing APIs without requiring additional coding or scripting. API security just ‘needs to happen’, not something that can be switched on or off, or requiring manual intervention. Introducing an API gateway with built-in security features will also help to police contributions from third-party developers. However, be sure to choose an API gateway that has the ability to support different types of APIs (REST, SOAP and so on).
Automate at scale
While the exact volume of future APIs is not clear, one thing for certain is that it will continue to expand. To reduce manual steps that are error-prone as well as time-consuming, automate API deployment in each environment as approvals come in (rather than having system administrators and DevOps people manually promoting APIs and re-applying configuration values from development to QA, to staging to production, for example). In effect, a human makes the decision, but the software carries out the workflow task. Also identify and apply different workflows or approval processes based on the type of API (for instance, internal or customer-facing), so that an appropriate amount effort is applied to each case. Consider using tools that continually inspect code as it is being created to detect defects at an early stage.
As businesses accelerate their adoption of the API-centric development philosophy, the global number of APIs will explode over the next few years. Putting in place a strong foundation that secures those APIs both today and in the future, makes sound business sense, to help protect organisations, their employees, partners and customers.
Rod Cope, CTO, Perforce Software