Application Security Begins with Secure APIs


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.

Filed in: Risk & Security
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Narcisa Zysman
Narcisa Zysman Senior Product Manager at CAST
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item