API Security: An Internal Auditor’s Quick Reference

“Man is still the most extraordinary computer of all.” – John F. Kennedy

APIs (Application Programming Interfaces) are an integral part of the web. When we visit a website, the web server that hosts that website will show a webpage. The API is the tool that makes the data of the website digestible for the client (whether desktop, laptop, mobile) through which we log in. API, a program provided by the server, could be part of the same program that handles web traffic or a separate one providing data to the client.

API is designed for interaction between two software programs, while a UI (User-Interface) is designed for a user to interact with a program directly. API presents raw data that can be parsed and manipulated by another program, while UI presents data that can be easily read by a human user.

API is shown in this diagram like a waiter in a restaurant who takes the order to the chef, gathers the food items ordered, and returns with the order.

Types of APIs by intended audience

1. Public APIs. Also called external or open APIs available publicly to developers and other users with minimal restriction.
2. Partner APIs. They are not available publicly and provided by strategic business partners, requiring specific entitlements to access them.
3. Internal APIs. Also known as private APIs, they are hidden from external users and exposed only to internal systems and internal development teams.
4. Composite APIs. Composite APIs combine multiple data or service APIs. They are useful in a microservices architecture, where information is needed from several services to perform a single task.

Types of APIs by protocol

1. REST. The Representational State Transfer (REST) architecture is the most popular approach that relies on client/server approach that separates front end and back ends of the API, and provides considerable flexibility in development and implementation. REST is stateless, which means that API stores no data or status between requests.
2. RPC. The Remote Procedure Call (RPC) protocol is a simple means to send multiple parameters and receive results. RPC APIs invoke executable actions or processes, while REST APIs mainly exchange data or resources such as documents.
3. SOAP. The Simple Object Access Protocol (SOAP) is a messaging standard defined by World Wide Web Consortium and broadly used to create web APIs usually with XML, though it supports a wide range of communication protocols.

API security in context

API security lies at the intersection of the three following three areas:

1. Information Security is concerned with the protection of information over its full lifecycle from creation to eventual destruction.
2. Network Security deals with the protection of data flowing over the network as well as prevention of unauthorized access to the network itself.
3. Application Security ensures that software systems are designed and built to withstand attacks and misuse.

API security: most important controls

1. Ownership and management. Every API should have an owner or provider that will define and publish the terms of use through proper SLAs to restrict the way the API is used and consumed, and also modify the implementation of API at any time in line with the definition and agreed SLA.
2. API design per corporate policy. There should be a policy on API clearly articulating the APIs be technology agnostic, meaning it should not be dependent on applications, programming languages and platforms.
3. Privacy and security. The design of the API should ensure the privacy of consumer data and enable audit trails for review. There should be end-to-end security of data, and it should be network agnostic and data-centric.
4. API governance. APIs should be developed per established digital strategy and should have clear answers for the following:
   • What are the business outcomes achieved?
   • Who is the target audience?
   • What is the API vision and had it been socialized?
   • Do we have established API architecture and re-use of components?
   • Have API security best practices been activated?
   • Is there an effective API lifecycle management?
   • Are APIs compliant to current laws and regulations?
   • Are there periodic vulnerability assessments and penetration tests conducted on APIs, and are timely corrective actions taken?
5. Audit controls
   • Is the data transmission from source to destination monitored, and if there is a failure, is there an intimation to the administrator, and is it recorded in the audit trail?
   • Are anonymous APIs disallowed?
   • Are user-identity and passwords deployed on APIs used for internal development and training purposes?
   • Is API key authentication used to secure applications’ authentication?
   • Are digital certificates used for all B2B communications?
   • Are OAuth2.0 and security tokens deployed for internal and external production APIs?

Author’s note: The opinions expressed are the author’s own views and do not necessarily represent those of the organization or of the certification bodies he is affiliated with.