Strong application security programs must include application programming interfaces (APIs), but perfecting API design is the number one challenge for any team trying to protect its applications. APIs are now the core of applications, with enterprise developers now relying heavily on them to support the delivery of new products and services. While they can be challenging to secure, using APIs allows programmers to integrate functionality from external sources instead of having to build those functions themselves – saving time and money.
Indeed, the benefits of a well-designed API are huge, and providing data through well-curated APIs has become a burgeoning business. Therefore, an API with good documentation, reliable performance and security will be adopted by more developers more quickly. However, in today’s world of fast-paced change, a quality API for programs can’t necessarily be applied to APIs made for containers or mobile apps.
The Application Security Challenge for APIs
The rise of APIs brings with it the risk for weaker application security, which can put corporate and consumer data at risk. Consequently, businesses need guidelines to ensure their API deployments do not create application security issues. The identification of these possible issues is mandatory to support a reliable and secure business.
One of the major mistakes when working with API is that teams tend to focus on one subset of services to make that feature available as fast as possible, thinking inside the box. Challenges may also arise because front ends and back ends are linked to a hodgepodge of components. On the other hand, hackers think outside the box, examining how a gateway can be used for nefarious purposes.
Moreover, DevOps has made allocating resources simpler and faster, but at the same time, the number of connections between application components has risen, and system design has become more complex. APIs support many thousands of possible connections. Being under pressure to deliver new releases at speed, well-intended and responsible programmers sometimes hurry and make mistakes.
Protecting Against Third-Party Risk
The sophistication of APIs creates other problems. One popular use of APIs is to allow third parties to write add-on code for a platform. Mobile and social media platforms, like Facebook, rely on others to add value to their system. Often, developers give a high level of authorization rights (system administrator functionality in some cases) to those APIs. Hackers then try to obtain these privileges to find out system vulnerabilities. And unfortunately, the list of possible attacks is long. The Open Web Application Security Project (OWASP), an ad hoc consortium focused on improving software security, keeps tabs on the most common API vulnerabilities, including SQL/script injections and authentication vulnerabilities.
Another major challenge to consider when designing an API is the authorization and authentication on the front end, as APIs do not live alone. Developers tie these elements with other pieces of software. Securing the code properly requires that developers take a multi-pronged approach. This starts with solid authentication, which is the process of checking the correct identity of a user. Enterprises have been moving away from simple password systems to multi-step authentication, but they also need to take steps to secure back end access.
No matter how much time and effort are put into securing the front-end of APIs, attackers still worm their way into the system through back doors. Organizations need to set up another checkpoint on the way out of the network. Even if hackers access confidential information, it will only have value if it is moved out of the organization’s own systems.
With API usage rising and empowering businesses to build more dynamic applications, organizations need to be aware of the potential application security risks that come with them. Source code must be checked on a regular basis in order to be sure that guidelines are followed and OWASP vulnerabilities are removed. These regular checks help guarantee a well-designed API, without security or performance holes. It does not only benefit the API, but also the whole application and therefore the company.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.