CLOUD API SECURITY AUDIT

- An Extensive Approach to API Assessment -

Master Thesis
Charity Uche Orji
20210771

Aalborg University
Electronics and IT
 Electronics and IT
Aalborg University
http://www.aau.dk

Title: Abstract:
Cloud API Security Audit
The migration of computing ser-
Theme: vices to the cloud and the use of
Master Thesis APIs to communicate and inter-
act with several applications over
Project Period: the internet come with its chal-
Fall Semester 2023 lenges. As these challenges in-
crease by the day, it is very im-
Project Group: portant that attention is paid to
Charity Uche Orji auditing the use of APIs, espe-
cially in enterprises. This project
Participant(s):
presents an extensive approach to
Charity Uche Orji
assessing RESTful APIs. It com-
Supervisor(s): mences by touching on why this is
Marios Anagnostopoulos essential, discussing vulnerabilities
to APIs, and outlining security re-
Copies: 1 quirements for APIs. A review of
current API security audit frame-
Page Numbers: 54 works and approaches to auditing
is highlighted. Next, an extensive
Date of Completion: approach to assessing Cloud APIs
June 2, 2023 is proposed using the presented se-
curity requirements as metrics. Fi-
nally, the results of an assessment
of a Public API are discussed.

The content of this report is freely available, but publication (with reference) may only be pursued
due to agreement with the author.
Contents

1 Introduction 1

1.1 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Methodology 3

2.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Choice of APIs Used . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 API Assessment/Auditing . . . . . . . . . . . . . . . . . . . . . 5

3 Background and Related Work 6

3.1 Cloud Computing Architecture . . . . . . . . . . . . . . . . . . 6

3.1.1 Cloud Computing Service Models . . . . . . . . . . . . 6

3.2 Types of APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3 API Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.1 REST APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.3 GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 API Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4.1 OWASP API Security Top 10 . . . . . . . . . . . . . . . 9

3.4.2 Cloud API Data Breaches . . . . . . . . . . . . . . . . . 12

3.4.3 Cloud API Security Requirements . . . . . . . . . . . . 12

3.5 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ii
Contents iii

3.5.1 API Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 18

3.5.2 API Security . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5.3 Cloud and API Auditing . . . . . . . . . . . . . . . . . 20

4 API Assessment 22

4.1 Audit Principles and Guidelines . . . . . . . . . . . . . . . . . 22

4.2 API Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Proposed API Assessment Method . . . . . . . . . . . . . . . . 24

4.3.1 Assessing APIs Using The Security Guidelines for Pro-

viding and Consuming APIs . . . . . . . . . . . . . . . 26

4.3.2 API Testing Tools . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Evaluation of A Public API Following This Extensive Approach 40

5 Discussion and Conclusion 44

5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.1 Proposed API Assessment Method. . . . . . . . . . . . 44

5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliography 47

A Appendix 52
Chapter 1

Introduction

The use of cloud computing by individuals and organizations is on the in-

crease. This comes as a result of the ease made available by cloud service
providers (CSPs), in the form of storage and other useful resources. Cloud
APIs make it very easy to access and use these various services. Applica-
tion Programming Interfaces(APIs) are sets of functions and protocols that
enable communication and sharing of resources between services and ap-
plications [18]. Cloud APIs therefore, enable communication and transfer of
information between applications in the cloud. They can be used to access
data or resources from an external server or database. They can equally
be used to write or post data to cloud services. Many organizations and
enterprises now employ the use of APIs to ease their work, and the services
rendered to their clients. Since the use of cloud APIs involve some commu-
nication or transfer of data, it is very crucial to pay attention to its security.
Also significant to enterprises using APIs, is the need to gain the trust of
clients in the handling and protection of data (personal data). It is espe-
cially important if the APIs being used are public or external APIs, as the
use of insecure APIs can affect an organization’s reputation and finances.
There have been several breaches in recent times, due to vulnerabilities in
APIs. For example, in 2022 alone, there were data breaches in 5 companies/
platforms that exposed an average of 5.58 million accounts due to API se-
curity issues. These security issues include the likes of Broken Object Level
Authentication, Broken Function level authentication, and lack of encryp-
tion[48]. The exploitation of these vulnerabilities could lead to privilege
escalation, brute force attacks, data exposure, manipulation, and theft.

1.1 Problem Formulation

The vulnerabilities and data breaches now experienced in the use of APIs
make consideration of API security very crucial. If an API is not secure,
it affects the confidentiality and integrity of data hosted in its system and
transmitted through its endpoint. It can also affect the availability of a ser-

1
1.1. Problem Formulation 2

vice to those using it. This research work, thus focuses on answering the
question:
How can we better enhance the Security of Cloud APIs in use?
What practical measures are to be taken to ensure the confidentiality, in-
tegrity, availability, and appropriate authentication of API and API end-
points? To better approach this subject, we will consider the following
research questions:

• What are the security vulnerabilities common to APIs?

• What are the essential security requirements for APIs?

• How best can cloud APIs be assessed/ audited?

This report is divided into chapters and sections to address these research
questions. The methods used for this project and the reason for the choices
are discussed in Chapter 2. The first and second research questions: what are
the security vulnerabilities common to APIs? and What are the essential security
requirements for APIs are answered in Chapter 3. Chapter 3 discusses some
background information on APIs, such as API vulnerabilities, breaches, and
security requirements. Related works on API security and different ap-
proaches to auditing are also presented in Chapter 3. The third research
question: How best can cloud APIs be assessed/audited? is discussed exten-
sively in chapter 4. The final chapter discusses and provides a summary
of the work done, the limitations of the project, answers to the research
questions, and suggestions on further areas of research on this subject.
Chapter 2

Methodology

This chapter discusses the approach and methods taken for this project.
We take a closer look at methods used for gathering data, analyzing data,
and the reason behind such choices. For clarity, the chapter is divided into
sections covering: data collection, data analysis, choice of APIs used, and
API assessment.

2.1 Data Collection

The data collection phase was focused on gathering relevant, published aca-
demic research work on subject matters such as APIs, API vulnerability, se-
curity, and auditing. Popular search engines were used, the likes of Google
Scholar, IEEE Xplore, Aalborg University Library, and Semantic Scholar. To
get suitable research papers, certain keywords were applied to the search.
The keywords used were: Cloud APIs auditing, API auditing. This did not
produce much result. One reason for this is that it is a relatively new field
with very few published research works. As a result, the majority of the
results from this search were irrelevant. 18 research publications were ob-
tained from the search but only 4 were relevant.
However, the search for related academic work was broadened. More key-
words were applied such as: API testing, API vulnerabilities, API security,
Information systems auditing, API security testing, API audit framework.

2.2 Data Analysis

The choice of API testing tools and platforms used for this project were
products of quantitative data analysis. The data collection process revealed
a lot of API testing tools available in the market. From this list of API testing
tools, 4 open-source tools were chosen randomly. An online poll was made
in a forum on LinkedIn to seek the views of professionals in the Industry

3
2.3. Choice of APIs Used 4

who make use of or have made use of these API testing tools. The aim of
this poll was to find out the most commonly used API testing tools.

The 2 API testing tools with the highest votes as seen in Figure 2.1 were
used for this project. However, it was observed that there were limitations
on what can be achieved with one of the source tools: APISec. This led to
the use of an alternative software testing tool called Synk [24].

Figure 2.1: LinkedIn Poll Result

2.3 Choice of APIs Used

The APIs used for these projects are all Public APIs. YouTube Data API [14]
and Simple Inventory API [31] are some of the APIs evaluated in this
project. The reason for this choice is the difficulty to get organizations
who would be willing to collaborate on auditing and assessing their APIs.
Due to security reasons, many would be unwilling, to avoid any chance of
exposure of data used by these APIs which may be sensitive in nature.
2.4. API Assessment/Auditing 5

2.4 API Assessment/Auditing

This project is focused on auditing Cloud APIs. In general, auditing a sys-

tem is done based on selected metrics. The same approach is applied here
in this project. However, after careful research, it was observed that there
is no known, published, or recognized framework specifically for auditing
APIs. Based on this finding, our focus was shifted to security frameworks
for the Cloud, such as the Cloud Control Matrix by the Cloud Security
Alliance [8]. Further research was made to find out if there are still any se-
curity frameworks or standards related to the Cloud and specifically APIs.
Further extensive research led to the discovery of a document called Se-
curity Guidelines for Providing and Consuming APIs by the Israeli chapter of
Cloud Security Alliance [4]. The security controls contained in this docu-
ment along with the CCM were used as metrics for the assessment of APIs
in this project. Details on how these controls were used and their various
areas of applicability are detailed in Chapter 4.
Chapter 3

Background and Related Work

This chapter works through background information on cloud computing

architecture, service models, types of API, and API architecture. It also
looks into API threats and vulnerabilities and security requirements. The
chapter concludes with a presentation of related works on API security and
existing API security frameworks.

3.1 Cloud Computing Architecture

Microsoft defines Cloud computing as "the delivery of computing services-

including servers, storage, databases, networking, software, analytics, and
intelligence-over the internet("the cloud") to offer faster innovation, flexible
resources, and economics of sales" [30]. In order words, computing re-
sources which are usually provisioned and accessed on-premise, are made
available on demand over the internet [33]. This computing model makes
the management of computing resources very easy and efficient, especially
the sharing of resources.

3.1.1 Cloud Computing Service Models

The various services provided and accessed in the cloud are dependent on
different service models. What a user is able to do, and how much control
he has differs with each service model. The 3 main cloud computing service
models are:

• Infrastructure as a Service (IaaS)

• Platform as a Service (PaaS)

• Software as a Service (SaaS)

6
3.2. Types of APIs 7

Infrastructure as a Service(IaaS).
With this service model, a consumer is able to use cloud infrastructure(software
and hardware) hosted by a cloud provider [33]. These could be servers,
storage, and networking. The consumer only controls and manages com-
ponents such as operating systems, deployed applications, and data.

Platform as a Service(PaaS)
These cloud computing services allow a consumer to develop, run and man-
age applications in the cloud [13]. The consumer only has control over his
deployed applications.

Software as a Service(SaaS)
Software as a Service allows users to make use of cloud-based software so-
lutions/ applications over the internet. Some examples of SaaS solutions
include Gmail, Microsoft Office 365, Google Workspace, Adobe, etc. These
applications can be accessed using a web browser or a program interface
such as an Application Programming Interface(API) [33].
Cloud APIs enable communication and interaction with other applications
and services, such as other SaaS products. With them, one is also able to
access/ retrieve data from applications deployed in the cloud.

3.2 Types of APIs

The most common types of APIs we have are:

1. Open APIs

2. Public APIs

3. Partner APIs

4. Private APIs

5. Composite APIs

Open APIs
Open APIs are free and public APIs, with Open API specifications. They
generally do not need the authorization to be accessed [5].

Public APIs
Public APIs are in some way similar to Open APIs [5]. They are publicly
available for use to developers, but most do not have an Open-API specifi-
cation. Some may also require a subscription to fully utilize the APIs [5, 16].
They are usually built with little security(authorization and authentication)
measures [16]. The Google APIs are an example of Public APIs.
3.3. API Architecture 8

Partner APIs
These APIs are only accessible to certain parties, usually authorized clients
with licenses who are partners with the API developers [5, 16]. Due to their
limited access and nature, partner APIs have more built-in security mea-
sures than public APIs.

Private APIs
Private APIs are also known as Internal APIs. They are only accessible and
designed for use in an organization. Thus, they are not available to external
or third parties [16].

Composite APIs
A Composite API has multiple APIs embodied in it, such that multiple re-
quests can be made even from multiple servers, with a single API call [5].
These APIs are efficient, as they reduce the server load and system com-
plexity [16].

3.3 API Architecture

API Architecture is the framework of rules or protocols for creating and

building APIs. There are several architectural styles adopted in building
APIs. These include:

• REST

• SOAP

• GraphQL

3.3.1 REST APIs

REST stands for Representational State Transfer [5]. REST APIs allow com-
munication with web services over the HTTP protocol. All requests are
made using HTTP methods. The methods commonly used are POST, GET,
PUT, PATCH, and DELETE. These methods are used to create, read, up-
date, modify, and delete resources respectively [17].
To access a web service or resource in the cloud using APIs, a request is
made in the form of a web URL using any of the HTTP methods above [17].
In turn, a response is sent back by the server in HTML, XML, Image, or
JSON. The most commonly used response is in JSON format [17].
3.4. API Security 9

3.3.2 SOAP

SOAP stands for Simple Object Access Protocol. SOAP APIs are more struc-
tured than REST APIs. It encodes data sent and received over the API client
in XML [50]. SOAP APIs use HTTP as a primary protocol for transport.
However, it is language-independent and can use HTML, plain text, and
JSON as data formats. It also makes use of other protocols such as SMTP,
TCP, and UDP to transport messages [50]. Due to its structure, SOAP APIs
are not as flexible and lightweight as REST APIs.

3.3.3 GraphQL

GraphQL is a protocol developed by Facebook. To use GraphQL, an outline

is made of all possible queries and their specific type of response. [49]. This
makes GraphQL very good for privacy, as it keeps data secure, returning
only exactly what the user requests for [5, 49]. It is also well structured and
provides detailed error logs [49].

3.4 API Security

A report published in 2019 showed that APIs constitute about 83% of to-
day’s internet traffic [1]. As more enterprises adopt the use of APIs in their
organizations, their percentage is sure to increase. Different types of APIs
are used in different ways and for different purposes by organizations to-
day. APIs no matter the type or purpose, could be vulnerable to certain
security risks. OWASP in 2019 published a list of the top 10 vulnerabilities
common to APIs [48].

3.4.1 OWASP API Security Top 10

The OWASP Top 10 for APIs are threats and vulnerabilities most exploited
and common to APIs. For 2023, its API Security Top 10 release candidate
on GitHub has a list of top threats to API. They are as follows in order of
priority:

1. Broken object-level authorization

2. Broken Authentication

3. Broken Object Property Level Authorization

4. Unrestricted resource consumption

5. Broken function level authorization

3.4. API Security 10

6. Server Side Request Forgery

7. Security misconfiguration.

8. Lack of protection from automated threats

9. Improper Inventory management

10. Unsafe Consumption of APIs

Broken object level authorization

An API is vulnerable to broken object-level authorization if an attacker is
able to manipulate the ID of an object. This is usually implemented at the
code level. Successful exploitation of this vulnerability can lead to unau-
thorized access resulting in data exposure, loss, and manipulation [38].

Broken Authentication
The absence of user authentication or improper implementation of it on
API endpoints and API management tools makes it vulnerable to malicious
actors. An API is vulnerable to broken authentication if it allows the use of
weak passwords, sends sensitive details such as tokens and passwords in its
URL, or uses weak encryption keys. This vulnerability can be exploited to
gain access to users’ accounts in a system, reading their data and probably
using the data obtained for something malicious [48, 39].

Broken Object Property Level Authorization

With the appropriate function level authorization and user authentication
implemented, an API endpoint can still be vulnerable to broken object prop-
erty level authorization(BOPLA). BOPLA comes with the inability of an API
endpoint to validate what specific properties of an object a user has access
to. This can lead to excessive data exposure, data loss, and data manipula-
tion [40]

Unrestricted resource consumption

An API is vulnerable if any of the following is lacking or set to be too low
or high: execution timeouts, maximum allocable memory, the maximum
number of file descriptors, the maximum number of processes, maximum
upload file size, number of operations to perform in a single API client
request (e.g. GraphQL batching), number of records per page to return
in a single request-response and third-party service providers’ spending
limit [41]

Broken Function Level Authorization

Broken function level authorization occurs as a result of the inability to
properly define functions such as the administrative and general user func-
tions [48], and restricting it to authorized users alone [52]. These irregu-
larities could give an average user to resources only accessible to admin-
istrators. Attackers could take advantage of this flaw to steal valuable or
sensitive data.
3.4. API Security 11

Server Side Request Forgery

This applies to API endpoints that take a URL as an input and access it
without validation [42]. An attacker could exploit this, making the vulner-
able API endpoints redirect its request to an internal network [23]. This
exposes the network, resulting in service enumeration and information dis-
closure [42].

Security misconfiguration
This entails the use of unpatched and out-of-date system components, lack
of Transport Layer Security(TLS), enabling features that are not necessary,
and lack of Cross-Origin Resource Sharing (CORS) policy on APIs. These
can lead to the exposure of sensitive data and possibly full system compro-
mise [43].

Lack of protection from automated threats

This threat exploits sensitive business flows and automates access to it.
When this is done by an attacker and in excess, it can lead to a DOS at-
tack: preventing legitimate users from using the service or purchasing a
product. It can also lead to the spread of false news since the attackers are
able to send a lot of messages [44].

Improper Inventory management

An API is vulnerable to improper inventory management if it has a doc-
umentation blindspot and a data blindspot. An API has a documentation
blindspot if there is outdated or no documentation of the API and its end-
point, providing inventory and essential details on the purpose and visibil-
ity of the APIs. Additionally, if an API shares sensitive data with a third
party without any inventory and basis for such, the API is said to have a
data blind spot. Improper Inventory management makes it difficult to find
and fix vulnerabilities in APIs. Attackers can also gain access to sensitive
data through unpatched APIs [45].

Unsafe Consumption of APIs

This happens when developers fail to strengthen the security of their end-
points when using external APIs by well-known companies. The trust they
have in these third-party APIs makes them pay little or no attention to im-
portant things such as input validation and sanitation of data from other
APIs. They fail to also look into the security of the channel of communica-
tion used by these APIs. As a result of this, the endpoints are left exposed
to injection attacks and exposure of sensitive data by attackers [37].

There are so many APIs and different API management platforms as well.
As a result, security functions are implemented in different ways in these
tools. This requires a proper study and understanding of these tools to
properly affect these functions. Vulnerabilities in API are not limited to the
OWASP TOP 10. APIs are written programs and codes of instructions. This
means that certain code vulnerabilities would also be applicable to APIs.For
3.4. API Security 12

example, improper input validation.

3.4.2 Cloud API Data Breaches

A good number of Cloud API data breaches exploiting some of the API
vulnerabilities mentioned earlier were experienced in the year 2022.
The Broken Object Level Authorization(BOLA) vulnerability was quite preva-
lent in 2022. In January 2022 for example, Twitter, a social media platform
was made aware of a Broken Object level authorization vulnerability in its
system. This enabled the disclosure of certain details of a Twitter account
by an API if an email address or phone number associated with that ac-
count is entered by an individual [55]. About 5.4 million Twitter accounts
were exposed in July 2022 and reportedly offered for sale as a result of this
bug in their code [55, 27]. Another case of a data breach experienced as
a result of the BOLA vulnerability was that of Flexbooker. Flexbooker of-
fers digital appointment scheduling services. It uses an Amazon S3 bucket
for cloud storage. It experienced a DDoS attack on its AWS server, which
attackers exploited to gain unauthorized access to sensitive information of
over 3.7 million of its customers [57]. The Texas Department of Insurance,
on the other hand, had some security issues with its web application that
handles worker’s compensation information. This was a case of Broken
Function Level Authorization. The program code allowed internet access
to a protected area of the application. This led to the exposure of certain
information of about 1.8 million Texans, such as names, addresses, dates of
birth, phone numbers, part or all of Social Security numbers, and informa-
tion about injuries and workers’ compensation claims [19, 27]

3.4.3 Cloud API Security Requirements

The OWASP API Security T0p 10 and the examples of data breaches dis-
cussed in the previous sections highlight that are certain risks associated
with the use of APIs. These risks could be in [2]

• API accessibility

• the volume of data involved

• the sensitivity of the data

• integration frequency

• data retention

• third-party trust and

• third-party security
3.4. API Security 13

The document: Security Guidelines for Providing and Consuming APIs [3], of
the Cloud Security Alliance(CSA) provides guidelines that can be applied in
all phases of the development cycle of APIs as well as during the use. The
guidelines are presented based on two use cases based on the associated
risks, namely:

1. Ingress Access and

2. Egress Access

Ingress API Connectivity

Ingress API connectivity deals with a third party accessing data from a
public or private API [4]. A good example is an organization making use of
an external or public API in its application. These security controls apply
from the development stage to the use and/or monitoring of APIs. They
are organized based on risk areas.
3.4. API Security 14

- Threat modelling and appropriate counter measures.

- Service authentication (For example, use of API keys, OAuth,
JWT.)
- Complete mediation on API management platform (Authoriza-
tion checks must be done on all requests).
- Token Strength (use state of-the-art encryption algorithm).
- Protection of testing/staging environments. This includes
software update and proper configurations. This might also
include restricting them from external parties.
- Regular penetration testing and continuous vulnerability
scanning by certified professionals.
- Security oriented code review.
- Application security scanning and secret scanning. Removal of
hard coded sensitive string such as secrets, passwords, and keys.
API Accessibility
- Use of TLS and only strong cipher suites.
- Source IP limitation.
- Lockdown accounts not in use, unsuccessful authentication
attempts, and malicious accounts based on a predefined threshold.
- Only mandatory ports (ports in use) should be exposed
especially on the admin APIs. This also applies to external
network infrastructure related to the API hosting.
- Protect API gateways with Web/ API application Firewall.
- Session termination on the API gateway. Termination of inactive
authentication tokens or API keys after predefined inactivity
time.
- Protection of API against DOS and brute force attack. For
example, implementing rate limiting.
- Proper and updated documentation of the API inventory
- Threat modeling and countermeasures
- Least privilege (authorization should be limited to only
permissions and HTTP methods needed to perform a required
Required Permissions
action
to all functions
- Authorization should be implemented as a separate service.
- Request rate limiting
- Data sanitation (to ensure removal of sensitive data)
Table 3.1: Security Controls To Risk Areas in API [4]
3.4. API Security 15

- Request rate limiting

- Regex Denial of Service (When using Regex for input validation,
restrict input length to avoid DOS attack)
- Protect API gateways with Web/ API application Firewall
Volume of Data
- Session termination
Involved
- Protection of API platform from DOS and brute force attacks.
For example, implementing rate limiting
- API Security tool for implementing API protection (Detection
and response to API security incidents)
- Threat modeling and counter measures
- Service authentication
- Granting authorization on principle of least privilege
- Authorization should be implemented as a separate service
- Input validation decoupled from the application
- Complete mediation on API management platform
(Authorization checks must be done on all requests).
- Input validation and output encoding
- Data sanitation (to ensure removal of sensitive data)
- Error handling (should not disclose any information that could
be exploited by an attacker. E.g internal path, filename, data, etc.)
- Protection of testing/ staging environments.
Sensitivity of Data - Regular penetration testing and continuous vulnerability
scanning
- Security-oriented code review
- Application Security scanning and secret scanning
- Web/API Application Firewall
- Continuous monitoring across the entire stack. Enable audit,
access, and other relevant types of logs.
- Storing HTTP Access Logs for use during an incident or digital
forensics. The logs should not have any sensitive data. This
practice should be in line with necessary data retention policy and
other regulations.
- API Security tool for implementing API protection (Detection
and response to API security incidents)
- Threat modeling and appropriate counter measures.
- Request rate limiting
- Input validation and output encoding
- Regex Denial of Service (When using Regex for input validation,
restrict input length to avoid DOS attack)
- Data sanitation
- Error handling (should not disclose any information that could
be exploited by an attacker. E.g internal path, filename, data, etc.)
Trust of third Party
- Regular penetration testing and continuous vulnerability
scanning
- Application security testing and secret scanning
- Web/API Application Firewall
- Protection of API platform from DOS and brute force attacks.
For example, implementing rate limiting
- API Security tool for implementing API protection (Detection
and response to API security incidents)
Table 3.2: Security Controls To Risk Areas in API [4]
3.4. API Security 16

Existing vs. New - Threat modeling and countermeasures

API - Proper and updated documentation of the API.
- Threat modeling and countermeasures
- Service authentication
- Granting authorization on principle of least privilege
- Authorization should be implemented as a separate service
- Request rate limiting
Integration - Data sanitation
Frequency - Security-oriented code review
- Session termination
- Continuous monitoring across the entire API stack.
- Storing HTTP Access Logs for use during an incident or digital
forensics. The logs should not have any sensitive data.
- API Security tool for implementing API protection.
- Threat modelling and countermeasures
- Granting authorization on principle of least privilege
- Authorization should be implemented as a separate service
- Request rate limiting
- Data sanitation
- Regular penetration testing and continuous vulnerability scanning
- Security-oriented code review
Data Retention
- Lockdown accounts not in use, unsuccessful authentication
attempts and malicious accounts based on a predefined threshold.
- Session termination
- Continuous monitoring across the entire API stack.
- Storing HTTP Access Logs for use during an incident or digital
forensics. The logs should not have any sensitive data.
- API Security tool for implementing API protection.
- Threat modeling and countermeasures
- Granting authorization on the principle of least privilege
- Cross-Site Request Forgery (CSRF) protection
- Request rate limiting
- Storage of Application Secrets in a secure location, away from
code repository. Encryption of API keys in transit and delivery
Third Party’s through a secure channel.
Security and - Complete mediation on API management platform (Authorization
Security compliance checks must be done on all requests).
status - Input validation and output encoding
(SOC 2, - Regex Denial of Service (When using Regex for input validation,
penetration test, restrict input length to avoid DOS attack)
ISO 27001, etc.) - Protection of testing/ staging environments.
- Regular penetration testing and continuous vulnerability scanning
- Installation of a valid, up-to-date and signed TLS certificate on the
API server/gateway.
- Lockdown accounts not in use, unsuccessful authentication attempts
, and malicious accounts based on a predefined threshold.
- Continuous monitoring across the entire API stack.
Table 3.3: Security Controls To Risk Areas in API [4]
3.5. Related Works 17

Egress API Connectivity

Egress API connectivity deals with API connectivity that grants read/write
access to an external party, i.e. sharing information owned by one’s organi-
zation to a third party [4]. This is more of an outbound connectivity than an
ingress, which is inbound. For this use case, the following security controls
apply:

1. Threat modeling and countermeasures: Identification of possible threats

during the design of the API, and measures to deal with it [4].

2. Storing Secrets: Storing of encryption keys and secrets in a safe loca-

tion [4].

3. Application Security Scanning and Secrets Scanning: Scanning of

the program code for vulnerabilities before deployment(Static Testing)
and continuously after deployment(Dynamic testing) [4].

4. TLS Valid Certificate: TLS certification validation is necessary to en-

sure a secure connection to the third party [4].

5. Session Termination: All inactive external connections should be closed

based on preset rules [4].

6. Destination IP and Port limitation: Connections to external parties

should be restricted to fixed IP addresses and ports [4].

7. Continuous Monitoring: This should be done to look out for possible

security issues [4].

8. Detection and Response: Implementation of appropriate tools and

procedures for detection of, and response to security issues [4].

9. Documentation: Proper and updated documentation of the API in-

ventory [4].

The security controls presented in Tables 3.1, 3.2, and 3.3 serve as security
requirements for Cloud APIs. More details on these controls are discussed
later on in Chapter 4.

3.5 Related Works

This section presents related work on API vulnerabilities and security. It

also takes a look at existing API security Audit Frameworks.
3.5. Related Works 18

3.5.1 API Vulnerabilities

With its use, the security features provided by API management tools are
usually not sufficient to ensure the secure use of APIs [53, 54]. A contribut-
ing factor is the lack of security in the design of APIs. Another significant
reason is the inability of API management tools and platforms to handle au-
thentication and authorization. Authentication and authorization services
usually identify the source of API requests. The failure of API management
tools in doing this can leave APIs vulnerable to attacks caused by a lack
of authorization. This is reflected in the T-Mobile breach that led to the
compromise of 2.3 million customer data. The API failed to check who was
making the query. As a result, any request for customer data made with
a valid phone number was granted. This led to the exposure of customer
data which could be used to gain access to other accounts or services used
by a customer to steal sensitive data. DDoS attack is another vulnerability
common to APIs. Poor design in APIs such as not putting rate limits on
API requests could lead to DDoS attack [53].

3.5.2 API Security

To properly manage vulnerabilities associated with APIs, API security test-

ing and audit are very necessary. Analysis of API assets is one way of
testing APIs, as stated by Sun et al [54]. However, identifying these assets
through active scanning can be quite challenging. API data flow analysis,
on the other hand, can be used to supplement this. Sun et al proposed
an API security audit system based on the Internet traffic. The security
audit system is divided into three parts based on assets, namely: Asset
discovery, Asset portraits, and Vulnerability detection. Asset discovery al-
lows for the identification of API assets including unknown APIs, as well
as how they process data. This discovery is enabled through methods such
as traffic analysis, docking data, and importing data. The Asset portrait
produces a profile list of identified APIs using data analysis. This contains
vital information such as the functions and permissions the API has such
as user login, registration, data query, and administrator permissions. The
API safety detection and protection module which handles vulnerability
detection, applies active and passive means to audit APIs. It allows for the
detection of possible vulnerabilities such as Remote command/code exe-
cution, data leakage, unauthorized access, unauthorized access, and logic
defects in APIs. This, in turn, would enable an immediate response to fixing
the vulnerabilities where applicable. The figure below shows the structure
of Sun et al. Security Audit Framework.
3.5. Related Works 19

Figure 3.1: Security Audit Framework [54]

For active property monitoring as opposed to the passive monitoring of

APIs, Atlidakis et al. came up with 4 security rules as security checkers on
REST APIs [6]. These rules are designed to check out for essential security
properties REST APIs should have, which are usually not detected by pas-
sive monitoring. The rules are the Use-after-free rule, Resource-leak rule,
Resource-hierarchy rule, and User-namespace rule. The Use-after-free rule
states that any deleted API resource must not be available for further use.
As such any more attempts at using it should fail. An attacker could exploit
a violation of this rule to bypass resource quotas leading to the elevation of
privilege attacks or possible corruption of services. With the Resource-leak
rule, a resource that was not successfully created must not be accessible nor
“leak” any associated resources in the backend service state. If a resource
quota is exhausted by violation of the resource-leak rule, it becomes im-
possible to create new resources if needed. Violation of this rule can also
affect the overall performance of the service. The resource-hierarchy rule
prevents a child resource created from a parent resource, to be accessible
by another parent resource with no parent-child relationship to the given
sub-resource. Violation of this rule gives an attacker unauthorized access
to a parent object identifier, which would in turn be used to steal or hijack
its child object. The last rule called the User-namespace rule, states that a
resource created in a user namespace must not be accessible from another
user namespace. In other words, if a resource is created using the token of
user A, the same resource must not be accessible using the token of user B.
Violation of this rule allows an attacker to perform unauthorized operations
on a victim’s resource, using unauthorized authentication tokens.
Atlidakis et al. implemented four active checkers to check and detect viola-
tions of these 4 rules in APIs.

• Use-after-free checker

• Resource-leak checker

• Resource-hierarchy checker and

3.5. Related Works 20

• User-namespace checker

Use-after-free checker: the algorithm for the use-after-free checker is called

after the main driver of an API executes a DELETE request. It takes as in-
put: a sequence seq of requests(the latest executed by the API); global_cache
which has the most recent object types and ids for the dynamic objects cre-
ated until that point and the set of all available API requests. The id of
the deleted object type is fetched from the global_cache, and a request is
executed on it. It is expected that the request on the deleted object fails and
returns a “404 Not Found” HTTP status code in their response. But if the
request is successfully executed, then the use-after-free rule is violated.
Resource-leak checker: This checker takes the same three inputs as the use-
after-free checker. It operates on request sequences executed by the main
driver whose last request led to an invalid HTTP status code in the re-
sponse. The algorithm iterates over object ids “guessed” for the current ob-
ject type for which an invalid HTTP status code was received. The function
GUESS takes as argument an object type and returns a set of possible object
ids matching this type and which were not created successfully. A guessed
object-id value is temporarily added to the global cache of properly-created
dynamic objects. The algorithm then tries to trigger a resource-leak viola-
tion or asserts that no such violation occurs for the given request sequence
Resource-hierarchy checker: This checker takes a sequence seq of requests(the
latest executed by the API) and the global_cache as inputs. The algorithm
records the object types consumed by the last request and those prior to
it. After this, it retrieves the most recent id of each child object consumed
only by the last request and attempts to violate its hierarchy. The algorithm
executes a request on the old child id using a parent id different from that
of the object. Failure of the request is an indication that the resource-leak
rule is not violated.
User-namespace checker: This checker tries to re-execute the valid last re-
quest of any test case executed by the API’s main driver with another au-
thentication token. Successful execution of this request indicates a violation
of the use-namespace rule.

3.5.3 Cloud and API Auditing

Auditing refers to the steps and processes an organization takes in evaluat-

ing and assessing its IT infrastructure, to ensure it is compliant with certain
security requirements [56]. These security requirements could be indus-
try standards such as the CCM, NIST, and ISO standards. It could also be
internal requirements set by the organization. However, auditing a cloud
system in which cloud APIs are inclusive, and using industry standards can
be challenging as these systems are designed in different ways to cater to
different needs. This makes it quite impractical to evaluate and assess these
different systems in relation to one another using the same standard [56]
There are several approaches to auditing. These are the retroactive ap-
3.5. Related Works 21

proach, the intercept-and-check approach, and the proactive approach [26].

The retroactive approach to auditing in the cloud utilizes security patches
and updates to detect intrusion and any vulnerabilities [7]. It executes two
copies of patched code: one with the patch and the other without, using
the same input to determine its outcome. A varying response on the patch
shows an indication of a vulnerability [58]. This approach has its limita-
tion as it only detects an incident after it has occurred [34]. The intercept-
and-check approach as the name implies, intercepts requests to verify their
compliance before accepting or rejecting it [7]. This is an improvement to
the retroactive approach. But its method of auditing creates delays in re-
sponding to requests [25]. The proactive approach audits cloud systems
way ahead of time, before any security incident occurs [34, 26].

The API Security Audit Framework by Sun et.al and the Security Rules and
Checkers by Atlidakis et al. all focus on different parts of an API system
that are crucial to assessing and maintaining API security. Nevertheless,
each approach is not sufficient enough to evaluate an API. In this report,
we would present a more general, but specific API assessment method that
takes into account various areas of an API system.
Chapter 4

API Assessment

This chapter presents a more extensive approach to auditing APIs. First,

we take a look at guidelines and/or principles for auditing APIs. This is
followed by how to evaluate APIs with API management tools and API
testing tools using certain standards and controls. Finally, we present the
outcome of assessing some public APIs using this proposed approach. The
words "audit"/"auditing" and "assess"/"assessing" are used interchangeably
in this chapter, and both refer to the same thing.

4.1 Audit Principles and Guidelines

Auditing of IT systems makes certain that the systems meet certain secu-
rity requirements [22]. The standard ISO/IEC 19770-1:2017 states 3 reasons
for auditing an IT asset management system, namely: to determine if a
system [22]

• meets the organization’s own requirements for the system

• fulfills the requirements of the ISO/IEC 19770-1:2017 standard

• is effectively implemented and maintained [22].

These reasons mentioned above also apply to APIs in order to ensure their
security.
Audits are usually carried out based on some criteria [21]. These audit cri-
teria are outlined in the ISO 19011:2018 standard on Guidelines for auditing
management systems. They include [21]

- requirements defined in one or more management system standards;

- policies and requirements specified by relevant interested parties;
- statutory and regulatory requirements;
- one or more management system processes defined by the organization

22
4.2. API Assessment 23

or other parties;
- management system plan(s) relating to the provision of specific outputs
of a management system(e.g. quality plan, project plan).

In general, when auditing any system, it is essential to know the objective,

scope, and criteria of the audit [21], The objective and scope are usually
defined by the auditee. The criteria is agreed upon by the auditor and
auditee.

4.2 API Assessment

As with any IT system, the objectives, scope, and criteria for auditing APIs
should be defined from the beginning. Of equal importance is getting to
know the number of APIs the organization has and uses. Having this
knowledge helps to more clearly define the scope of the assessment. The
organization should have necessary documentations that provides valuable
information such as

• Type of APIs (Public or private)

• identify assets used by the APIs

• Policies associated with the use

The assets used by these APIs should be classified based on the level of
sensitivity, importance, and associated risks to the organization. For orga-
nizations that make use of API gateways and management tools, a thorough
understanding of how these tools work would make for a very efficient as-
sessment.

Cloud API Audit Criteria

One of the criteria that could be used for assessing IT systems are require-
ments defined in management system standards [21]. Some widely recog-
nized standards are the ISO standards [20] and the NIST framework [32].
There is also the Cloud Control Matrix (CCM) [8] developed by Cloud Secu-
rity Alliance(CSA). Although there are no standards specifically dedicated
to APIs, the above-mentioned standards contain security controls that ap-
ply to Software applications and the Cloud as a whole. As a result, some of
the controls can be applied to APIs as well. In the subsections that follow
this chapter, we will have an overview of these controls that can prove very
useful in assessing APIs.
4.3. Proposed API Assessment Method 24

4.3 Proposed API Assessment Method

The objective here is focused on Information security and assessing how

cloud APIs maintain Confidentiality, Integrity, and Availability. The as-
sessment criteria applied are select controls from the Cloud Control Ma-
trix(CCM) [8] and the document: Security Guidelines for Providing and Con-
suming APIs [4], both developed by the Cloud Security Alliance. In using
these publications, we aim at highlighting how APIs can be evaluated with
the associated controls. The choice of controls from CCM V4.0.7 for assess-
ment is based on the article: Top Threats to Cloud Computing Pandemic Eleven.
The controls dependent on 5 domains are seen in Table 4.1

Control Domain Control Title Control ID

Application and Interface Application and Interface Security Policies
AIS-01
Security(AIS) and Procedures
AIS Secure Application Design and Development AIS-04
AIS Automated Secure Application Deployment AIS-06
Change Control and Configu-
Change Management Policy and Procedure | CCC-01
ration Management (CCC)
CCC Quality Testing CCC-02
CCC Change Agreements CCC-05
Cryptography, Encryption &
Data Encryption CEK-03
Key Management (CEK)
CEK Encryption Algorithm CEK-04
Data Security and Privacy Life-
Security and Privacy Policy and Procedures DSP-01
cycle Management (DSP)
DSP Data Inventory DSP-3
DSP Data Classification DSP-4
DSP Data Flow Documentation DSP-5
Infrastructure & Virtualization
Network Security IVS-03
Security (IVS)
IVS OS Hardening and Base Controls IVS-04
IVS Network Defense IVS-09
Table 4.1: CSA CCM Controls Version 4.0

These controls are further classified in the area of applicability:

• Documentation

• Code

• API Management Platform

Documentation:
Documentations are very important in any IT system and this includes sys-
4.3. Proposed API Assessment Method 25

tems using APIs. Proper documentation makes monitoring of APIs eas-

ier. With these documentation, APIs can be examined to see if they are in
compliance with the security requirements outlined in the documentation.
Documentations here include policies and logs. The controls DSP-01, DSP-
04, and DSP-05 are applied primarily to documentation. Thus, during an
audit, an auditor should look out for documented evidence such as data
inventory, flow diagrams, and logs. These should provide details on the
classification, handling, storage, sharing, and protection of data [8], which
could reveal if there is any risk of excessive exposure of data.

Code:
APIs are basically sets of instructions and codes. As such they should fol-
low the same security design principles as softwares, during development.
One such principle is input validation. This is what the control AIS-04 looks
out for. Other things to pay attention to include:

• query parameters: be certain that no sensitive data such as API key,

client secret, or personal data that could be traced to an individual,
are used as query parameters. These are very likely to be exposed
and leaked to authorized persons who could use them for selfish and
inferior motives.

• scope: the principle of least privilege should be applied in defining

scopes to avoid excessive exposure of data

• response body in JSON format: The expected response to an API

request should be examined to ensure that only the data required by
the user is contained in the response body.

Details are provided in the later section of this chapter on what more can
be ascertained from analyzing the codes that make an API. Even though
analysis of the code can reveal a lot about an API, this is still limited. This
makes the use of API management tools very essential.

API Management Platform and Tools:

API management enables developers to incorporate APIs into applications.
In an enterprise, API management tools provide a platform to control access
to APIs and monitor and analyze the use of the APIs. They also provide
useful documentation [35]. As a result, API management platforms/tools
can prove very useful in evaluating APIs. The CCM controls in Table 4.1
which can be assessed from API management platform/tools are the AIS-
01, CCC-01, CEK-03, and CEK-04. Details of how these controls can be as-
sessed using Microsoft Azure API Management Service and Google Cloud
Platform would be discussed in the later parts of this chapter.

Another assessment criteria used here for evaluating APIs is based on the
document: Security Guidelines for Providing and Consuming APIs (SGPC APIs)
also from the Cloud Security Alliance. The controls in the document, are
mapped to the OWASP API TOP 1O 2019 [48] and when applied can ensure
4.3. Proposed API Assessment Method 26

the security of APIs from its design phase even through monitoring during
use [4].

4.3.1 Assessing APIs Using The Security Guidelines for Pro-

viding and Consuming APIs

The table below provides a classification of the controls from the Security
Guidelines for Providing and Consuming APIs, based on different areas of
applicability.
4.3. Proposed API Assessment Method 27

S/N Controls Area of Applicability

1 Asset and API Documentation Documentation
2 Input Validation decoupled from the application Code
3 Output encoding Code
4 Regex Denial of Service Code
5 Data sanitation Code
6 Safe Package Usage Code
Storage of Application Secrets - Rotation of secrets, Code and API Manage-
7
Mode of transfer or delivery ment Platform (API MP)
Service Authentication: authentication mechanisms/
8 API MP
protocols - API Key, OAuth, JWT
Least Privilege (Access control to API endpoints and
9 API MP
HTTP methods based on need only)
10 Cross Site Request Forgery (CSRF) Protection API MP
11 Request Rate Limiting API MP
12 Complete Mediation - Authorization to object and scope API MP
13 Token Strength: Encryption Algorithm API MP
14 Protection of Staging Environment API MP
15 Valid TLS Certificate API MP
16 SSL/TLS Cipher Suites API MP
17 Source IP Limitation API MP
18 Account Lockdown API MP
19 Exposed Network Interfaces - Open Ports API MP
Session Termination - inactive authentication tokens
20 API MP
or API keys
21 Denial of Service Mitigation API MP
Storing HTTP Access logs - check contents for
22 API MP
sensitive data
23 Error handling (should not disclose any information) Pentesting results and logs
24 Pentesting and Vulnerability scanning Review test reports
Review code test results in
25 Security-Oriented Code Review line with organizational
policies
26 WEB/API Application Firewall Firewalls
OS and Packages/libraries
27 OSI/Packages updates
update
Table 4.2: API Security Controls from SGPC APIs

Documentation Dependent Control:

Identification of an organization’s assets based on priority and use by APIs
is vital when evaluating an API. This is especially important if the use of an
API would involve fetching the personal data of clients. Proper documen-
tation of assets and API documentation would make the following parts of
the evaluation very easy and efficient. It provides details on the various
endpoints and methods of the API, as well as its parameters, if any. These
would serve as a guide on what to look out for during Code analysis, as
4.3. Proposed API Assessment Method 28

well as assessment through API management platform.

Code Dependent Controls:

Code analysis of APIs is an integral part of API assessment. This is quite so
as security is usually not in the picture, during the design phase of APIs. As
seen in Table 4.4, some security requirements to check for when analyzing
APIs include:

• Input Validation and Output Encoding: APIs that take some form of
input from a user or database require input validation to guarantee
that only the expected data is taken as input. Output encoding, on
the other hand, ensures that any input from the user, be it a script
from an attacker, does not have any malicious effect [46]. This also
helps control vulnerabilities such as injection attacks and Cross site
scripting [47].

• Regex Denial of Service: The use of regular expression is one way

to implement input validation. However, if there is no check on how
regular expressions are used, especially when the input text is long,
that could lead to a denial of service.

• Data Sanitation: This entails an inspection of data returned by APIs,

to remove any which may be sensitive [4]. This can be done through
code and log analysis. Executing this also requires thorough knowl-
edge of the assets of an organization that the APIs make use of.

• Safe Package Usage: There are many public APIs out there used by
many. These APIs probably have never been updated since they were
published. There is also a possibility that they may have been updated
at some point, but that may be a long time ago. As a result, these
APIs are running outdated packages. A good example is YouTube
Data API [14]. A look at its GitHub repository [15] showed the last
commit to it was done in 2018. The repository was tested to check
for vulnerabilities. One of the results showed it had a vulnerability
called Insecure Default. This is the case because the API is using New-
tonsoft.Json 6.0.4, a package of the Json.NET framework which was
released in August 2014. Figure 4.1 shows the test result.
4.3. Proposed API Assessment Method 29

Figure 4.1: Vulnerability Test on YouTube API detecting an outdated package in use 1

When assessing APIs, therefore, the APIs should be checked for vul-
nerabilities associated with outdated packages. These APIs should be
examined to ensure they are running the latest patch version avail-
able [4].

• Error Handling: How APIs respond to, or handle errors should not be
overlooked when auditing APIs. Its response to errors should never
reveal any information an attacker could exploit [4]. Code Analysis
and logs can be used to check for Error handling in APIs.

• Storage of Application Secrets: As the name implies, application se-

crets are secrets. Thus, they should be stored securely and not be left
exposed. If API keys and client secrets are to be used for any request,
their delivery should be over a secure channel [4]. The response body
of an API request should not contain any application secret. Assess-
ing this security requirement can be done through code analysis, and
from the API management platform. Through analysis, the code can
be checked for keywords that would detect if the code contains any
sensitive strings. API testing tools can also be used to make API re-
quests and check the request headers and response body for any sen-
sitive strings or secrets. It is recommended that organizations have a
rotation of application secrets as part of their security policy. In that
regard, API management platforms used by organizations should be
checked to see if and how they implement rotation of application se-
crets [4].

Software testing tools can be used to check for most of the code-dependent
controls. Synk was used to test the public APIs used for this project. Some
of the results of these tests are in the appendix.
4.3. Proposed API Assessment Method 30

API Management Platform Dependent Controls

API management platforms are used to manage the entire lifecycle of APIs.
In effect, they provide a platform for enterprises to more easily develop,
design, monitor, test, secure, and analyze APIs [12]. We will now consider
an overview assessing these security requirements.

• Service Authentication: The organization should have established its

authentication and authorization mechanism. This could be API keys,
or protocols such as OAuth, JWT, etc. [4] It should be verified that
these mechanisms are properly implemented in the API management
Platform.

• Least Privilege: Authorization and access control to API endpoints

and HTTP methods should be restricted to just those required to per-
form a certain operation.

• Cross-Site Request Forgery(CSRF) Protection: For APIs that make use

of cookies for authentication and authorization, it is essential to avoid
the execution of unwanted actions via the API. Mechanisms that check
the value in the cookie to determine if it matches that in the API
request, can be used. Additionally, all forms can be checked to verify
they are hashed [36].

• Denial of Service and Request Rate Limiting: Lack of control over how
an API is used, could result in denial of service. One way to prevent
this is by implementing rate limiting on requests. Rate limiting defines
the maximum number of requests allowed in a given time interval [9].
The rate limit of an API and its operations should be defined in the
organization’s security policy [4]. This is then used to check against
what is in the API management platform for consistency.

• Complete Mediation: This involves preventing any access to API end-

points without authorization. As such, all API endpoints should have
authorization mechanisms. All-access to any resource should be checked
for authorization and this should be limited to just the required scope [4].

• Token Strength: Weak encryption algorithms should be avoided. Only

strong and state-of-the-art encryption algorithms should be used.

• Protection of Staging Environment: The platforms used to host these

APIs in the cloud should be properly set up. If this is not done, this
still leaves the APIs vulnerable even when the necessary security mea-
sures have been applied to the codes. In this regard, the platforms and
any software used should be properly configured, and always patched
when necessary, among other things [4].

• Cipher Suites and TLS Certificate: The API management platform

should be checked for valid, up-to-date, and signed TLS certificates.
4.3. Proposed API Assessment Method 31

It should be verified TLS is used, as well as strong cipher suites based

on the organization’s security policy [4].

• Source IP Limitation: To ensure access control and mitigation of denial

of service, API calls should be limited to only dedicated IP services if
possible [4].

• Account Lockdown and Session Termination: Accounts which are not

in use for various reasons, accounts which have tried carrying out
malicious actions and authenticating with invalid credentials should
be locked, based on a preset timeline [4]. To do this effectively, the
API management platform’s logs and monitoring system should be
checked against the organization’s list of current and valid accounts.

• Exposed Network Interfaces: The necessary network ports needed for

hosting the API should be defined by the organization. The results of
a network scan would reveal if any unnecessary ports are open and
exposed.

• Storage of HTTP Access Logs: API calls and requests should be prop-
erly logged. It should be verified that these logs do not contain any
sensitive data [4].

Some commonly used API management platforms include the Microsoft

Azure API Management Service and Apigee - Google Cloud’s API Manage-
ment platform. The Microsoft Azure API Management platform consists of
an API gateway, a management plane, and a developer portal. APIs and
other management services are defined and configured in the management
plane, while the API gateway enforces the services and policies defined in
the management plane [28]. In assessing APIs using the Azure API Man-
agement platform, our emphasis would be mainly on the API gateway and
management plane.
Apigee is also a platform for building and managing APIs. With Apigee,
API proxies can be created to manage and secure APIs and communication
between client Applications and the server [11].

In auditing Cloud APIs through Management platforms, we will map some

controls of the CCM V4.0.7 to specific controls of Security Guidelines for
Providing and Consuming APIs.
4.3. Proposed API Assessment Method 32

CCM Control SGPC APIs Control

Least Privilege (Access Control)
Complete Mediation
AIS - 01
Denial of Service Mitigation
Request Rate Limiting
Storage of Application Secrets (Rotation of Secrets)
CCC - 01 Account Lockdown
OSI/ Packages update
CEK - 03 Storage of Application Secrets
CEK - 04 Token Strength: Encryption Algorithm
DSP - 01 Asset and API Documentation
DSP - 04 Asset Documentation
DSP - 05 Asset and API Documentation
Exposed Network Interfaces - Open Ports
IVS - 03 Valid TLS Certificate
SSL/TLS Cipher Suites
IVS - 04 Firewalls
Table 4.3: Mapping of CCM V4.0.7 Controls To Security Guidelines For Providing and
Consuming APIs

Having mapped these controls, we will now consider in detail how to au-
dit Cloud APIs from management platforms based on these controls. The
order of presentation is based on how each control relates to the other

DSP - 01: Security and Privacy Policy and Procedures

Asset and API documentation is a point of reference when evaluating APIs
for this control. The auditor should identify and ensure that the organiza-
tion has policies on classification, protection, and handling of data through-
out its lifecycle [8]. These relevant documentation should be examined to
establish if they are compliant with local regulations on data protection.

DSP - 04: Data Classification

The data used by the APIs should be checked to ensure that they are prop-
erly classified according to the data privacy policies and procedures estab-
lished by the organization. There are likely to be changes in the data used
and its sensitivity level with time. Thus, it should be checked that these
classifications are reviewed and updated frequently. The implementation of
these classifications can be examined in the Azure API management plat-
form as well.
4.3. Proposed API Assessment Method 33

Figure 4.2: Azure API Operations and Policies

As seen in Figure 4.2, the operation GetSessions of Demo Conference API has
three parameters of which response value is expected. The classification of
these data should be in the data privacy policies. When evaluating these
data and their implementation based on data classification, it should be
checked that the policies on this operation and those who are allowed ac-
cess to it reflect its sensitivity level.

DSP - 05: Data Flow Documentation

This involves a check of the availability of data flow documentation. It
should be assessed to ensure it is complete, accurate, and in line with the
API’s data security and privacy policies as well as the flow of data when
using the API [8].

AIS - 01: Application and Interface Security Policies

This entails examining documentation on policies and procedures for main-
taining API security, against the policies in the API management service.
There should be clear documentation on

1. Users and/or accounts who are allowed access to an API or API ser-
vice and their roles.

2. authorized access to individual APIs and their respective operations.

3. Allowed or accepted number of requests that can be made to an API

endpoint within a specified time interval

4. IP addresses that are allowed to communicate with the API service,

make API calls, or request to a certain endpoint.
4.3. Proposed API Assessment Method 34

The Microsoft Azure API management provides policies to help imple-

ment this. The policies in MS Azure management could have the following
scopes, namely:

1. Global Policies: These policies cover all APIs in the management ser-
vice.

2. Product Policies: Product policies apply to all APIs in a particular

product. Figure 4.3 shows a product with two(2) APIs: Echo API
and ThesisFunction. The policies applied to it show that the APIs can
only be accessed by administrators, and would need a subscription to
access.

3. API: These policies cover all operations in a given API.

4. Operation: Operation policies are limited to just specified operations

in an API.

Figure 4.3: Product Policies in Azure API Management 2

The figures below show an API management service with two APIs: Demo
Conference API and Echo API. Each shows specific areas to check on the
implementation of API policies.

Figure 4.4: Global API Policies

4.3. Proposed API Assessment Method 35

Figure 4.5: API scoped Policies

As shown in the figures above, policies applied to API can vary in scope.
The policies in Figure 4.4 apply to all APIs in that Management service.
On the other hand, policies in Figure 4.5 can apply to all operations in
the Demo Conference API or a specific operation. Therefore, in auditing
cloud APIs for Application and Interface Security Policies, the scopes of the
policies should be checked to ensure they are in harmony with the docu-
mentation.

CCC - 01: Change Management Policy and Procedure

This would involve reviewing changes to an organization’s assets, applica-
tion, systems infrastructure, and configurations [8]. An organization should
have policies on the rotation of access keys and other application secrets, as
well as how often this should be done. There should be documentation
on the set timeline of accounts, especially when the user of such an account
quits or no longer uses it for various reasons [4]. These should be compared
to what is obtainable from the API management service for uniformity. Fig-
ure 4.6 below shows the users in an API management service. Auditing an
API management service based on Change Management Policy and Proce-
dures would require that the organization provide a list of all current users
of the API service. This should be checked against the active users on the
API service, to determine if there is any user or account not in use that is
still active.
4.3. Proposed API Assessment Method 36

Figure 4.6: Users In an Azure API Management Service.

As part of the CCC-01 control, the API management service, and all soft-
ware, packages, and libraries in use should be examined to see if they are
updated.

CEK - 03: Data Encryption

Cloud APIs can be examined for data encryption both in transit and at rest.
For data in transit, logs and HTTP response to API requests should be in-
spected for any presence of application secrets or encryption keys. Azure
API management platform also allows for the tracing of subscription keys.
Enabling the tracing of these keys can make examining the encryption of
data in transit much easier. Storage locations of applications and API se-
crets should be inspected to determine if they are secure.

CEK - 04: Encryption Algorithm

The APIs and their management platform should be examined to ensure
that the encryption algorithm used is state-of-the-art and strong [4]. In the
Azure API management platform, for example, a good number of these
encryption algorithms are pre-activated, both weak and strong alike. It is
good practice to check that no weak encryption algorithms are in use.

IVS - 03: Network Security

Communication with cloud services is enabled through network ports and
interfaces. Misconfiguration and exposure of these interfaces and ports can
leave the network open and vulnerable to attackers. The bad actors could
exploit this to gain access to sensitive and unauthorized data, modify or
delete certain information and possibly steal them for selfish gains. There-
fore, when auditing cloud APIs, the network should be checked for any
open ports which may not really be needed. The service should also be
examined for the use of valid TLS Certificates and strong cipher suites [4].
4.3. Proposed API Assessment Method 37

IVS - 09: Network Defense

Certain restrictions are essential in a network to maintain confidentiality,
integrity, and availability of data and assets in a network. For Cloud APIs,
a Web/API Application Firewall can prove very helpful in achieving this
goal. Google has a Cloud Firewall [10] which can be used with Apigee to
protect API connectivity. However, not all Web Application firewalls are
compatible with APIs [4]. But other products can be used to cater to this
need in some way. One such is Microsoft Defender for cloud [29].

4.3.2 API Testing Tools

API testing is an important aspect of the API lifecycle. It provides a means

to determine if an API is working as it should. There are quite several API
testing tools used by many. From a list of commercial API testing tools
and platforms, 4 were picked at random. A poll was made to find out the
most preferred by many. Postman and APISec had the most preference,
with 55% and 27% respectively. Thus, we will consider how these tools can
prove useful in the testing and security assessment of APIs.

Postman
The Postman platform can be used for performance testing of APIs. It tests
APIs based on requests and expected responses. This is done in two(2)
ways: Unit testing and End-to-End testing. Unit testing allows for the test-
ing of an individual endpoint in an API collection. End-to-End testing en-
ables the testing of all endpoints in an API collection one after the other.

For APIs that require authorization and authentication, these mechanisms

can be tested to ensure they are working properly as should.

Figure 4.7: Authorization mechanisms and Protocols in Postman 3

The figure above shows the various authorization mechanisms Postman

4.3. Proposed API Assessment Method 38

supports. An enterprise can set up its API collection and test its autho-
rization to ensure it works as it should. This feature can also aid in security
testing when it comes to authentication. The results of an attempt at au-
thorization and authentication can be checked against the organization’s
policies on authorization and authentication to see if it is working as ex-
pected.

In obtaining access tokens for APIs, application secrets such as Client ID

and Client Secret would need to be supplied. This is seen in the figure
below

Figure 4.8: Use of Application Secrets in Postman

In configuring access tokens for an API in Postman, the client ID and client
secret can be supplied directly into the specified box or set as a variable.
Application secrets such as these, when input directly to the new token
form could likely be exposed, and used for malicious purposes. This can be
used to test for another security control, Control No. 7 in Table 4.4: Storage
of Application Secrets - Mode of transfer or delivery.
Other nice features of Postman are the Pre-request Scripts and Test scripts.
The Pre-request scripts are very useful for analyzing the codes before API
requests are sent. This can be used, for example, to search for a variable in
the code before the API request is sent. The Test scripts, on the other hand,
run tests scripts after the execution of API request [51]. These tests vary
from getting variables, the status code of the response to the API request,
to searching the response body for a string. These features can be used to
check the API requests and responses for sensitive data such as application
4.3. Proposed API Assessment Method 39

secrets, and also see how the APIs handle errors.

The interesting thing about using test scripts is that they can be customized
by an organization to suit its needs and security criteria based on the orga-
nization’s policies.

APISec
APISec is an API solution that provides automated testing for APIs. Its API
testing tool EthicalCheck is used in testing API. To test APIs using this tool,
the user needs to supply its Open-API Specification URL or a Postman URL.
The EthicalCheck Engine invokes the API and runs tests on it, scanning for
the OWASP API Top Ten list. On successful completion of the process, a
report is generated, detailing the outcome of the scan. The image below
shows a summary of the scan result of an Online Banking REST API.

Figure 4.9: APISec API Scan Result

As evident in the scan result above, the APISec scanner discovers all end-
4.4. Evaluation of A Public API Following This Extensive Approach 40

points associated with the API to be tested. With this discovery, the meth-
ods in each endpoint are all tested for vulnerabilities. The vulnerabilities
discovered are classified based on the level of severity and their impact on
the business. This classification of discovered vulnerabilities would help an
organization determine what areas to pay more attention to and prioritize
how to remedy the associated risks.

4.4 Evaluation of A Public API Following This

Extensive Approach

An attempt was made in assessing a Public API using the extensive ap-
proach outlined in earlier sections of this chapter. The assessed API is a
Simple Inventory API. It is a public API with an Open API specification
available for use on SwaggerHub. This API was assessed using the Azure
API Management Platform and Postman. It is assumed that an organization
is

• using this API to keep stock of its physical assets.

• using this API as built by the developer without any added security
measures

The table below provides the results of the assessment of this API using
the controls from Security Guidelines For Providing and Consuming APIs. The
remark "Y" means a particular control is implemented correctly, while "N"
signifies it is not implemented. On the other hand, when "N/A" is used it
means a certain command is not applicable.
4.4. Evaluation of A Public API Following This Extensive Approach 41

S/N Controls Remark(Y,N,N/A)

Asset Documentation N/A
1
API Documentation Y
2 Input Validation decoupled from the application N
3 Output encoding Y
4 Regex Denial of Service N/A
5 Data sanitation N
6 Safe Package Usage N/A
Storage of Application Secrets - Rotation of secrets,
7 Y
Mode of transfer or delivery
Service Authentication: authentication mechanisms/
8 N
protocols - API Key, OAuth, JWT
Least Privilege (Access control to API endpoints and
9 N
HTTP methods based on need only)
10 Cross-Site Request Forgery (CSRF) Protection N/A
11 Request Rate Limiting N/A
12 Complete Mediation - Authorization to object and scope N
13 Token Strength: Encryption Algorithm API MP
14 Protection of Staging Environment N/A
15 Valid TLS Certificate API MP
16 SSL/TLS Cipher Suites API MP
17 Source IP Limitation N
18 Account Lockdown N
19 Exposed Network Interfaces - Open Ports N/A
Session Termination - inactive authentication tokens
20 N
or API keys
21 Denial of Service Mitigation N
Storing HTTP Access logs - check contents for
22 Y
sensitive data
23 Error handling (should not disclose any information) N
24 Pentesting and Vulnerability scanning Review test reports
Review code test results in
25 Security-Oriented Code Review line with organizational
Policies
26 WEB/API Application Firewall N/A
27 OSI/Packages updates N/A
Table 4.4: API Security Controls from SGPC APIs

Assessment of the Simple Inventory API showed using Azure API Manage-
ment Service showed

• There were no access control implemented on the API

• The absence of complete mediation - specifying authorization to APIs’

object and scope
4.4. Evaluation of A Public API Following This Extensive Approach 42

• There were no policies implementing request rate limiting, source IP

limitation, Denial of service mitigation, etc

The Postman tool was also used to test and assess this API. The results of
the assessment are as follows

1. Output encoding was incorporated in the API.

2. There were no application secrets in the API request or response body

3. Content headers were also free of any sensitive data.

4. A view of the raw form of the requests and results showed that cookies
were not used in sending the server’s response to the API Call. Hence,
the API is protected from Cross-Site Request Forgery.

The figures below show some of the screenshots from Postman

Figure 4.10: Simple Inventory API Test Scripts

Figure 4.11: Simple Inventory API Test Results

4.4. Evaluation of A Public API Following This Extensive Approach 43

Figure 4.12: Simple Inventory API Headers

Figure 4.13: Simple Inventory API Authorization

The security controls with the remark "N/A", "Review test reports" and
"Review code test results in line with organizational Policies" were not ap-
plicable in this assessment as the security controls can only be examined in
a real API system, not a test system. Also, it was a challenge integrating this
API into the software testing tool Snyk. However, vulnerability scanning of
the YouTube Data API was achieved with the software testing tool Snyk.
A Screenshot of the test result was presented earlier in this chapter. Other
screenshots of the test results are in the appendix.
Chapter 5

Discussion and Conclusion

This chapter discusses at length further details on the approach taken to

assess Cloud APIs in this report. It also highlights areas that could benefit
from more research in the future. The chapter concludes with a summary
of the report and how the research questions were answered in this report.

5.1 Discussion

5.1.1 Proposed API Assessment Method.

The API audit system proposed by Sun et.al mentioned earlier in related
works, is based on data analysis of captured internet traffic [54]. As effec-
tive as that may sound, it can be time-consuming as well. It would take
a lot of time to analyze captured network, especially when that is done
manually. Additionally, this system of audit is focused more on the iden-
tification of APIs and vulnerabilities through the data flow of API assets.
Basing security audits only on assets can be limiting. How quickly can an
unauthorized attempt by an insider, from a legitimate source IP be detected
using this system? A lot can go wrong and may probably not be captured
by internet traffic.

The proposed API assessment method applied in this report, therefore fo-
cuses more on tools and platforms commonly used with APIs today. The
Cloud Control Matrix and the Security Guidelines for Providing and Con-
suming APIs, all created by the Cloud Security Alliance were used for this
project. The specifics of the security controls in the Security Guidelines for
providing and Consuming APIs make it a good reference, for audit criteria
when accessing APIs. However, the choice of audit criteria is always depen-
dent on the needs of the organization requiring an audit.

44
5.1. Discussion 45

API Management Tools

In highlighting the vulnerabilities of APIs, Sun et. al made mention of the
inability of API management tools and platforms to handle authentication
and authorization [54]. However, assessment of APIs using these tools has
shown that APIs managed with these tools are more vulnerable to attacks
if the tools are not properly configured. Thus any organization employing
the use of these tools should first gain a proper understanding of these tools
and their features to properly configure them. The same applies to the au-
diting party.
As noted by Sun et. al, attackers usually access APIs with legal/autho-
rized credentials and then simulate normal operations [54]. This makes
the input validation and access control implemented in code, as well as
security mechanisms provided by traditional API security gateways insuffi-
cient. Nevertheless, with the use of dedicated IP addresses and the setting
of quota limits on APIs and API operations, this can be controlled. This is
more efficient for organizations making use of internal APIs at work. As-
suming each staff has a dedicated work computer and is only allowed to
work from it, and just during official working hours, any access to the API is
limited. Thus, if that organization already has policies on this, comparisons
of how these are implemented in the API management platform against the
policies is a good way to evaluate the APIs. By doing this, an organization
can also ensure that Availability, as a security property is maintained by its
API.

API Testing and Testing Tools

API testing remains an invaluable aspect of API auditing. Many approaches
are applied. Many tools are used as well. Manual testing or code analysis of
API is still used by some today. But the choice of API testing tool to be used
can greatly affect the quality of tests to be conducted. This is reflected in
the API testing tools used in this project: Postman and APISec. Both tools
handle testing in different ways. Postman allows for performance testing
of APIs. It allows for flexibility in testing to suit the needs of an organiza-
tion. It can be used to test if an API has authorization and authentication
mechanisms or not. Its built-in feature "Test" can be used to perform cer-
tain tests on responses to API requests. These tests range from searching
the response body for certain variables, searching the content header for
any sensitive data, checking the response time for API requests, the status
code, and much more. However, it was observed with the use of APISec
that testing is automated. It tests APIs based on the OWASP Top 10 for API.
The entire testing process is automated. Nevertheless, the results obtained
are limited as its free API Scan engine only scans APIs for a few of the
Top 10 API Vulnerabilities. The paid version of APISec offers full access to
the tool’s scanning capabilities. The only limitation is its cost as it is really
expensive. Thus due to a lack of funding, we opted to use another software
5.2. Conclusion 46

testing tool.

Another delimitation of this project is that the assessment and testing of

APIs were restricted to a test environment only. As such, some of the se-
curity controls were not fully tested and assessed. This is because they can
only be assessed in a real working system.

5.2 Conclusion

It has been established that security is not taken into consideration in the
design of APIs. With the rise in data breaches experienced in the use of API,
an API audit is necessary to review how organizations implement security
measures in API. It has also been seen that security vulnerabilities such as
Broken Object Level Authentication, Broken function-level authentication,
and Security misconfiguration are some of the vulnerabilities common to
APIs. When adequate measures are not put in place, exploitation of these
vulnerabilities can come in the way of confidentiality, integrity, and avail-
ability of an organization’s assets and its API system. The Security Guide-
lines for Providing and Consuming APIs [4] provides security controls that
when implemented can help ensure the confidentiality, integrity, and avail-
ability of APIs. An extensive approach to how best these controls can be
used to assess cloud APIs has also been considered.
Assessment of the Business Logic of an API would be a great topic to con-
sider for further research on this subject
Bibliography

[1] Akamai. Akamai State of the Internet Security Report: Retailers Most Com-
mon Credential Stuffing Attack Victim; Points to Dramatic Rise in API
Traffic as Key Trend. Accessed: 2023-03-02. url: https://www.akamai.
com/us/en/about/news/press/2019- press/state- of- the- internet-
security-retail-attacks-and-api-traffic.jsp.
[2] Cloud Security Alliance. A New Resource for API Security Best Practices.
Accessed: 2023-03-10. url: https://cloudsecurityalliance.org/blog/
2021/04/30/a-new-resource-for-api-security-best-practices/.
[3] Cloud Security Alliance. Security Guidelines for Providing and Consum-
ing APIs. Accessed: 2023-03-10. url: https : / / cloudsecurityalliance .
org / artifacts / security - guidelines - for - providing - and - consuming -
apis/.
[4] Cloud Security Alliance. Security Guidelines for Providing and Consum-
ing APIs. 2021. url: https : / / cloudsecurityalliance . org / artifacts /
security-guidelines-for-providing-and-consuming-apis/.
[5] Nordic APIs. 6 Types of APIs: Open, Public, Partner, Private, Composite,
Unified. Accessed: 2023-05-26. url: https://nordicapis.com/6-types-
of-apis-open-public-partner-private-composite-unified/.
[6] Vaggelis Atlidakis, Patrice Godefroid, and Marina Polishchuk. “Check-
ing Security Properties of Cloud Service REST APIs”. In: 2020 IEEE
13th International Conference on Software Testing, Validation and Verifica-
tion (ICST). 2020, pp. 387–397. doi: 10.1109/ICST46399.2020.00046.
[7] Livia Maria Brumă. “Cloud security audit – issues and challenges”.
In: 2021 16th International Conference on Computer Science & Education
(ICCSE). 2021, pp. 263–266. doi: 10.1109/ICCSE51940.2021.9569654.
[8] Cloud Security Alliance. Cloud Controls Matrix (CCM). en. fFrame-
work. 2021. url: https://cloudsecurityalliance.org/artifacts/cloud-
controls-matrix-v4/.
[9] IBM Corporation. Understanding rate limits for APIs and Plans. Ac-
cessed: 2023-05-15. url: https : / / www. ibm . com / docs / en / api -
connect/10_reserved_instance?topic=connect- understanding- rate-
limits-apis-plans.
[10] Google. Cloud Firewall. Accessed: 2023-05-22. url: https : / / cloud .
google.com/firewall#section-1.

47
Bibliography 48

[11] Google. Understanding APIs and API proxy. Accessed: 2023-05-16. url:
https://cloud.google.com/apigee/docs/api-platform/fundamentals/
understanding-apis-and-api-proxies.
[12] Google. What is API Management? Accessed: 2023-05-12. url: https :
//cloud.google.com/learn/what-is-api-management?.
[13] Google. What is cloud architecture? Accessed: 2023-05-22. url: https :
//cloud.google.com/learn/what-is-cloud-architecture#section-6.
[14] Google. YouTube Data API v3. url: https : / / console . cloud . google .
com/apis/library/youtube.googleapis.com?project=psyched-choir-
377513.
[15] Google. YouTube Data API v3. url: https://github.com/youtube/api-
samples.
[16] HubSpot. 4 Types of APIs All Marketers Should Know. Accessed: 2023-
05-26. url: https://blog.hubspot.com/website/types-of-apis.
[17] HubSpot. REST API (Introduction). Accessed: 2023-05-26. url: https:
//www.geeksforgeeks.org/rest-api-introduction/.
[18] Fatima Hussain et al. “Enterprise API Security and GDPR Compli-
ance: Design and Implementation Perspective”. In: IT Professional 22.5
(2020), pp. 81–89. doi: 10.1109/MITP.2020.2973852.
[19] Texas Department of Insurance. Notice of Data Security event. Accessed:
2023-03-25. url: https://www.tdi.texas.gov/data- security- event/
index.html.
[20] ISO. Standards. Accessed: 2023-05-02. url: https : / / www. iso . org /
standards.html.
[21] ISO Central Secretary. Guidelines for auditing management systems. en.
Standard. Geneva, CH, 2018. url: https://www.iso.org/standard/
70017.html.
[22] ISO Central Secretary. Information technology – Part 1: IT asset man-
agement systems – Requirements. en. Standard. Geneva, CH, 2017. url:
https://www.iso.org/standard/68531.html.
[23] Bahruz Jabiyev et al. “Preventing Server-Side Request Forgery At-
tacks”. In: Proceedings of the 36th Annual ACM Symposium on Applied
Computing. SAC ’21. Virtual Event, Republic of Korea: Association
for Computing Machinery, 2021, 1626–1635. isbn: 9781450381048. doi:
10.1145/3412841.3442036. url: https://doi.org/10.1145/3412841.
3442036.
[24] Snyk Limited. Snyk. url: https://www.nist.gov/cyberframework/
framework.
[25] Suryadipta Majumdar et al. “Cloud security auditing: Major approaches
and existing challenges”. In: Foundations and Practice of Security: 11th
International Symposium, FPS 2018, Montreal, QC, Canada, November 13–
15, 2018, Revised Selected Papers 11. Springer. 2019, pp. 61–77.
Bibliography 49

[26] Suryadipta Majumdar et al. “User-Level Runtime Security Auditing

for the Cloud”. In: IEEE Transactions on Information Forensics and Secu-
rity 13.5 (2018), pp. 1185–1199. doi: 10.1109/TIFS.2017.2779444.
[27] Anne McCormick. The Top 5 API Security Breaches in 2022, and How to
Avoid Them in 2023. Accessed: 2023-03-11. url: https://techblog.cisco.
com/blog/top-5-api-security-breaches-in-2022.
[28] Microsoft. Azure API Management. Accessed: 2023-05-16. url: https://
learn.microsoft.com/en-us/azure/api-management/api-management-
key-concepts.
[29] Microsoft. Microsoft Defender for Cloud documentation. Accessed: 2023-
05-22. url: https://learn.microsoft.com/en-us/azure/defender-for-
cloud/.
[30] Microsoft. What Is Cloud Computing? Accessed: 2023-05-22. url: https:
//azure.microsoft.com/en-us/resources/cloud-computing-dictionary/
what-is-cloud-computing.
[31] SUNANDHINI MURALIDHAR. Simple Inventory API. url: https://
app.swaggerhub.com/apis/SUNANDHINIMURALIDHAR/InventoryAPI/
1.0.0.
[32] NIST. Framework Documents. Accessed: 2023-05-02. url: https://www.
nist.gov/cyberframework/framework.
[33] NIST. NIST SP 800-145, The NIST Definition of Cloud Computing. Ac-
cessed: 2023-05-22. url: https://nvlpubs.nist.gov/nistpubs/legacy/
sp/nistspecialpublication800-145.pdf.
[34] Minjie Ou, Liming Wang, and Hao Xun. “Deaps: Deep learning-based
user-level proactive security auditing for clouds”. In: 2019 IEEE Global
Communications Conference (GLOBECOM). IEEE. 2019, pp. 1–6.
[35] Michiel Overeem, Max Mathijssen, and Slinger Jansen. “API-m-FAMM:
A focus area maturity model for API Management”. In: Information
and Software Technology 147 (2022), p. 106890. issn: 0950-5849. doi:
https://doi.org/10.1016/j.infsof.2022.106890. url: https://www.
sciencedirect.com/science/article/pii/S0950584922000532.
[36] OWASP. Cross Site Request Forgery (CSRF). Accessed: 2023-05-15. url:
https://owasp.org/www-community/attacks/csrf.
[37] OWSAP. API10:2023 Unsafe Consumption of APIs. Accessed: 2023-03-
24. url: https://github.com/OWASP/API-Security/blob/master/
2023/en/src/0xaa-unsafe-consumption-of-apis.md.
[38] OWSAP. API1:2023 Broken Object Level Authorization. Accessed: 2023-
03-25. url: https : / / github . com / OWASP / API - Security / blob /
master/2023/en/src/0xa1-broken-object-level-authorization.md.
[39] OWSAP. API2:2023 Broken Authentication. Accessed: 2023-03-11. url:
https://github.com/OWASP/API-Security/blob/master/2023/en/
src/0xa2-broken-authentication.md.
Bibliography 50

[40] OWSAP. API3:2023 Broken Object Property Level Authentication. Ac-

cessed: 2023-03-11. url: https://github.com/OWASP/API-Security/
blob / master / 2023 / en / src / 0xa3 - broken - object - property - level -
authorization.md.
[41] OWSAP. API4:2023 Unrestricted Resource Consumption. Accessed: 2023-
03-25. url: https : / / github . com / OWASP / API - Security / blob /
master/2023/en/src/0xa4-unrestricted-resource-consumption.md.
[42] OWSAP. API6:2023 Server Side Request Forgery. Accessed: 2023-03-24.
url: https : / / github . com / OWASP / API - Security / blob / master /
2023/en/src/0xa6-server-side-request-forgery.md.
[43] OWSAP. API7:2023 Security Misconfiguration. Accessed: 2023-03-24.
url: https : / / github . com / OWASP / API - Security / blob / master /
2023/en/src/0xa7-security-misconfiguration.md.
[44] OWSAP. API8:2023 Lack of Protection from Automated Threats. Accessed:
2023-03-24. url: https://github.com/OWASP/API-Security/blob/
master / 2023 / en / src / 0xa8 - lack - of - protection - from - automated -
threats.md.
[45] OWSAP. API9:2023 Improper Inventory Management. Accessed: 2023-
03-24. url: https : / / github . com / OWASP / API - Security / blob /
master/2023/en/src/0xa9-improper-assets-management.md.
[46] OWSAP. Encode and Escape Data. Accessed: 2023-05-10. url: https :
//owasp.org/www- project- proactive- controls/v3/en/c4- encode-
escape- data#:~:text=Encoding%20(commonly%20called%20%E2%
80%9COutput%20Encoding,writing%20to%20an%20HTML%20page..
[47] OWSAP. Input Validation Cheat Sheet. Accessed: 2023-05-10. url: https:
//cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_
Sheet.html.
[48] OWSAP. OWASP API Security Project. Accessed: 2023-03-02. url: https:
//owasp.org/www-project-api-security/#.
[49] Postman. A guide to the different types of APIs. Accessed: 2023-05-29.
url: https://blog.postman.com/different-types-of-apis/.
[50] Postman. API 101: What Is a SOAP API? Accessed: 2023-05-29. url:
https://blog.postman.com/soap-api-definition/.
[51] Postman. Scripting in Postman. Accessed: 2023-05-15. url: https : / /
learning.postman.com/docs/writing-scripts/intro-to-scripts/.
[52] Rapid. API Security - Broken Function Level Authorization Vulnerability.
Accessed: 2023-03-02. url: https : / / rapidapi . com / guides / broken -
function-level-authorization.
[53] Salah Sharieh and Alexander Ferworn. “Securing APIs and Chaos
Engineering”. In: 2021 IEEE Conference on Communications and Net-
work Security (CNS). 2021, pp. 290–294. doi: 10.1109/CNS53000.2021.
9705049.
Bibliography 51

[54] Ronghua Sun, Qianxun Wang, and Liang Guo. “Research Towards
Key Issues of API Security”. eng. In: Communications in Computer and
Information Science. Vol. 1506. 2022, pp. 179–192. isbn: 9811692289.
[55] Twitter. An incident impacting some accounts and private information on
Twitter. Accessed: 2023-03-11. url: https://privacy.twitter.com/en/
blog/2022/an-issue-affecting-some-anonymous-accounts.
[56] Kazi Wali Ullah, Abu Shohel Ahmed, and Jukka Ylitalo. “Towards
Building an Automated Security Compliance Tool for the Cloud”. In:
2013 12th IEEE International Conference on Trust, Security and Privacy
in Computing and Communications. 2013, pp. 1587–1593. doi: 10.1109/
TrustCom.2013.195.
[57] WhiteBlueOcean. Retroactive Auditing. Accessed: 2023-03-24. url: https:
//www.whiteblueocean.com/newsroom/5- key- data- breaches- in-
2022/.
[58] M. Frans Kaashoek Xi Wang Nickolai Zeldovic. Retroactive Auditing.
Accessed: 2023-03-23. url: https://people.csail.mit.edu/nickolai/
papers/wang-rad.pdf.
Appendix A

Appendix

Below are Screenshots of vulnerability scanning of the YouTube Data API

using Snyk.

Figure A.1: Youtube Data API Vulnerability Scan Results - 1a

Figure A.2: Youtube Data API Vulnerability Scan Results - 1b

52
 53

Figure A.3: Youtube Data API Vulnerability Scan Results - 1c

Figure A.4: Youtube Data API Vulnerability Scan Results - 1d

Figure A.5: Youtube Data API Vulnerability Scan Results - 1e

 54

Figure A.6: Youtube Data API Vulnerability Scan Results - 1f