API security: How to ensure secure API use in the enterprise

API security is a growing enterprise concern. In the wake of recent high-profile breaches, discover how to alleviate the issues of insecure APIs.

Application programming interfaces (APIs) have been a topic of interest in the information security community of

late, and for good reason. They are reportedly to blame for a number of recent high-profile website security breaches including Pinterest and Instagram.

Poorly written code can quickly become dangerous code when it involves an API.

In January 2014, insecure APIs were connected to a Snapchat data breach that affected approximately 4.6 million users. While APIs weren't directly to blame, they allowed hackers to match Snapchat users' phone numbers with usernames on a massive scale.

In this tip, I will discuss how and why insecure APIs pose a major risk to enterprises and users alike, and explain what security teams must do to not only help raise awareness and secure the APIs in existing enterprise software but also consume API data safely.

What is an API?

An API is a set of functions or routines that accomplish specific tasks or provide a simplified method of interacting with a software component, often allowing the automation of common processes that interact with services running on other machines.

APIs can be in the form of a library that includes specifications for routines, data structures, object classes and variables, or simply a specification of remote calls exposed to the API consumer. Some APIs are based on international standards such as POSIX (Portable Operating System Interface), while others are made public in open source or vendor documentation. For example, Microsoft's Windows API enables developers to create software for the Windows platform.

To generate potential revenue streams and business opportunities, enterprises are increasingly making their business applications and data available through APIs. Additionally, Web 2.0 has created a surge in Web API usage, allowing users and programs to interact with the core data behind online applications. Amazon Web Services is the most prolific example, as it uses APIs to provide customers with access to its various services, such as EC2.

By making APIs publicly available, enterprises can improve partner connectivity, cloud integration and services to customers. Third parties can also develop applications that offer additional capabilities to users and help grow the awareness and use of an enterprise's services and products.

According to a recent study conducted by Layer 7 Technologies, more than 43% of respondents reported that their organization currently has an API program in place, while 27% said a program would be launched within the next year. The Facebook platform is a great example of API success; the APIs it provides has enabled developers to create hundreds of applications and services that access data in Facebook and its users, which no doubt has been a significant driver of Facebook's growth and success.

Web APIs, such as those from Facebook, are usually Hypertext Transfer Protocol request messages that return a structured response message, most commonly in Extensible Markup Language or JavaScript Object Notation format. This type of API is quickly replacing the Simple Object Access Protocol-based Web services and service-oriented architecture; they are easier to implement and better suited to create an open architecture for sharing content and data between applications and users.

API security mistakes -- and how to avoid them

Despite their many benefits, application programming interfaces are plagued with security problems, as recent events have shown. The problem is usually not the concept behind the API but rather how it is coded. Many application developers are failing to write or use APIs with security in mind, putting both the application and the underlying data at risk. Poorly written code can quickly become dangerous code when it involves an API.

Fortunately, there are many things that organizations and their developers can do to enhance and ensure the security of APIs in enterprise environments.

During development -- and certainly prior to release -- API code should be manually checked by a security expert to test whether it could be abused or misused by an attacker. Documentation is also critical. Clearly documented code allows reviewers to see exactly what the APIs should and should not do, and lets those incorporating the APIs into an application understand how to implement them correctly.

In documentation, developers should state how to call the API, what data will be returned and in what format, and what error messages can be expected. Internal records should also note who can access the API and what information will be logged to capture who, what and when resources have been accessed for audit purposes. While on the topic of access, machine IDs should supplement authentication checks where appropriate. Each API call should also be checked to ensure that the user or device has the correct permissions to view, edit or delete the requested data. Unfortunately, many developers omit secondary access control checks once a user has been authenticated.

To see how APIs handle unexpected inputs and requests, black-box testing and fuzzing are crucial. Data validation routines to prevent standard injection flaws and cross-site request forgery attacks are also vital, as calls to APIs can come from untrusted sources. Additionally, testing should be carried out from all types of endpoints, not just from a Web browser. Many APIs fail to implement SSL when accessed via a nonbrowser application, such as a mobile app, so be sure to check that sensitive data always remains encrypted when not required in plaintext. Penetration tests and vulnerability assessments should also focus on APIs as they are entry points to the application.

Enterprises that are looking to make use of a third party's APIs must ensure that their developers fully understand how to incorporate them securely and validate all responses received from them. Many developers -- both those from third parties and in-house -- love to reuse existing code found on the Internet, especially when it comes to examples of how to call a particular API. However, copying and pasting code without checking that it is appropriate within a given context is a common way that API-related vulnerabilities are introduced into an application.

Organizations must remember: While speed of development may be important, so is attention to detail. Developers must read API documentation carefully and never rely on Internet hearsay. Enterprise development timetables should allow enough time for developers to fully understand how to correctly implement APIs as well as to learn the potential risks the APIs introduce -- particularly when it comes to sharing user data. Poorly written or implemented APIs can introduce attack vectors and increase risks related to confidentiality, integrity, availability and accountability as they are a gateway to an enterprise's resources. APIs that do not have open and extensive documentation should be avoided whenever possible. If encryption keys are used as an access and authentication mechanism to call an API, they must be stored securely according to policy and never hardcoded into configuration files or other scripts.

The issues with APIs aren't likely to wane anytime soon; they are becoming a cornerstone of the modern open enterprise. Given their importance, APIs deserve more attention from all of those who are creating or using them. Implemented securely, APIs can allow an enterprise to leverage its own and others' data with ease and security. Implemented badly, they can be leveraged by hackers to attack an enterprise and its users.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He has a passion for making IT security best practices easier to understand and achievable. His website http://www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices. He co-authored the book IIS Security and has written many technical articles for leading IT publications. Mike has also been a Microsoft Certified Database Manager and registered consultant with the CESG Listed Advisor Scheme (CLAS).

This was first published in March 2014

Dig deeper on Web Application and Web 2.0 Threats

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close