See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/363266925

API Case Study

Technical Report · September 2022

CITATIONS READS

0 155

1 author:

Torben Jackisch

6 PUBLICATIONS 0 CITATIONS

SEE PROFILE

All content following this page was uploaded by Torben Jackisch on 04 September 2022.

The user has requested enhancement of the downloaded file.

 Assignment 2: API Case Study
Jackisch, Torben
Glyndŵr University
Wrexham, Wales
s20004419@mail.ac.uk
Abstract—This report deals with the development of a web
API for a fashion company with a focus on the points of
authentication, authorisation, requests, encryption, which API
type is suitable and its testing. In order to answer the
individual questions, various sources were consulted, which
primarily deal with the points of architecture, security and
communication in the area of APIs. These are, on the one hand,
various scientific studies and, on the other hand, technical
documentation on corresponding standards. The most
important results of the work are that certain patterns emerge
that can be found in many sources. This is especially true with
regard to architecture and security. Above all, the results
indicate that a clear solution is possible for the fashion
company and that a functioning and relatively secure solution
can be realised with the appropriate standards.
Keywords—API, security, authorisation, authentication,
encryption
I. SCENARIO
The scenario describes the requirements for an
application programming interface (API) for the LATEST
TRENDS CLOTHING COMPANY (LTCC) with a focus on
threats and prevention with security measures for the
different stages of communication between the involved
systems. The API shall provide different functionality, such
as manage current stock levels, generate orders and send
them to suppliers, receive bulk orders from distributors and
receive individual orders from distributors customers
(including customer delivery details). The API will handle
the communication between LTCCs internal systems and the
applications (or client, but in this paper it is only called
application) of distributors and suppliers.
Figure 1: LTCC API
communication
T. Jackisch, Assignment 2: API Case study ©2022 Glyndŵr University
See figure 1 for an illustration of LTCCs communication
model between the internal systems and the applications of
distributors and suppliers.
II. ASSUMPTIONS
As the API acts as a gateway to LTCCs internal systems,
it should be seen as a highly critical implementation of the
infrastructure.
Authentication service attacks can happen on different
layers. It could be possible to read user and password
information while the communications between the hosts
during a session. The authentication service can also be
misused for attacks like XSS and execution of other
malicious code [1 p3]. Another common threat is an API
exhaustion attack which is a type of denial of service (DOS).
That DOS attack will prevent the system from processing
legitimate requests [1 p4].
To prevent threats like the described ones, different
security measures on different layers are necessary, which
will be discussed in this paper.
III. AUTHENTICATION
Before an authorisation can be granted, the application
user need to authenticate at the API authorisation server with
given username and password and proves his/her identity to
allow the API to communicate with the application [12].
LTCCs internal user management can use an LDAP solution
like OpenLDAP [7] for the authentication of outside users.
The communication need to be secured by SSL/TLS [11] and
a strong password protection [8 p5]. An additional protection
can be the usage of a public key infrastructure using a
common x.509 standard [9] (e.g. RSA, FCC, etc.) [8 p5].
IV. AUTHORISATION
After the authentication of the user, the application is
allowed to communicate with the API and the API
authorisation server will share an authorisation token with
the application for a secure communication. This
authorisation token will be used to request an access token
from the API authorisation server. This access token will be
used by the application to access resources (e.g. data) from
the API resource server, which will crosscheck that access
token with the API authorisation server. If this crosscheck is
successful and the access token is valid, the API resource
server should check the request for malicious characters and
sanitise the code before sending the request to the internal
systems [12].
See figure 2 for a mapping of the oauth authorisation
process with reference to LTCC.

Figure 2: OAuth authorisation for LTCC
Since the access token is critical, as it can be used to open
a communication path to the API resource server, it needs to
be secured. Details about encrypted communication between
the involved servers will be discussed in the encryption
paragraph.
A common solution for the access token is the JSON
Web Token (JWT) [13], which acts as a container for data
transport and has become a widely supported standard for
modern APIs. The JWT is defined in three parts, which are
the head, payload and signature, which are base64 encoded.
They look like this: xxx.yyy.zzz, where every element
contain JSON formatted information [14 p157].
V. REQUESTS
The data requests sent by the user through the application
to the API end up providing data that is processed by internal
systems and sent back to the api.
The internal systems parse the requests and check them for
threatening content. Furthermore, the user permissions are
checked in order to send back only data that is approved for
the user. It is important that these permissions are not only
checked during processing, but also that the data is only
available with the appropriate authorisation. For example,
data from a database can be restricted with grants and views.
If a request is incorrect, it may only be acknowledged with
an abstract error message. No details that are relevant for
spying on vulnerabilities may be shown to the user.
If a request is valid, only the requested data may be
transmitted to the user.
Every action that happens in relation to the API triggers
an event, which must be perceived and persistently recorded
by a corresponding logging mechanism [19]. Log entries can
be subdivided and categorised hierarchically. For example,
Apache logging serves as an abstract toolkit for interface
logging. Levels and priorities would look like this [20]:
 fatal: lead to premature termination
 error: other runtime errors
 warn: poor use and deprecated APIs and almost errors
 info: non-critical but interesting events
 debug: system information
 trace: detailed system information
VI. ENCRYPTION
Every communication between the involved systems need
to be encrypted. The access token, which was discussed
earlier, can be used to get access to the API resource server
and therefore to the data of LTCCs internal systems, this
T. Jackisch, Assignment 2: API Case study ©2022 Glyndŵr University
communication need to be secured by an encryption standard
[8 p5].
A possible encryption for the access token transfer is
JSON Web Encryption (JWE) [15], which is commonly used
with JSON content, but can also be used with other types of
payload. JWE has JWT as basis and builds a token in serial
order with dot-separation, where each element is
BASE64URL-ENCODE encoded: JOSE Header, JWE
Encryption Key, Initialisation Vector, Ciphertext and
Authentication Tag [14 p185].
VII. API TYPE
Different resources talking about four types of trends in
API usage [3] & [4]:
 Public API (Open for all outside Applications)
 Partner API (Available for authorised partners)
 Internal API (For the use only inside of a company)
 Composite API (Combined usage)
As the API that is planned for LTCC shall only
communicate with specific partners and must have a strong
focus on security, the planned API will be a partner API.
Since the applications from suppliers and distributors are
handling the requests remote through the internet, the API is
basically a web service, which communicate with the
approach of REST or SOAP [1 p3].
VIII. TESTING
The Open Web Application Security Project (OWASP),
has published a TOP10 of API security leaks in 2019, which
lists common flaws. These flaws are basically broken
authorisation and authentication on different level, data
exposure or general security misconfiguration. This can be
used as a general guide to have a focus for further test cases
[17].
Beside the OWASP TOP10, general tests and validation
can be used in a process. Basically, testing the API consists
of validating the individual communication steps. To validate
the input, different parameters to be processed and the
response needs to be checked for a valid code. The JSON or
XML format needs to be validated for their structure. The
parsed data that is returned to the user needs to be checked if
they are correct. It needs to be checked, what happen, if bad
requests are processed and how the API responds to the user.
It needs to be checked, how the API reacts to changed
resource data. Basically on every layer, a security test must
be run. [16]
Security testing can be done with a Dynamic application
security testing (DAST) tool while the API is active or
SAST, when the source code is open to the testing team. In
addition to that, the access from other layers (e.g. admins)
need to be checked for the involved systems and the general
system availability [6 p 5].
IX. CONCLUSION
The LTCC's API clearly focuses on safety-related issues.
This cannot be handled exclusively with encryption. Regular
tests must be carried out in the various communications and
known weak points must be dealt with. Distributors and
suppliers not only have the possibility to read data, but can
also change data. For example, orders can be placed with
LTCC, causing records to be created. Security measures need
to be implemented at different levels. Data, application, API
endpoints and network must be monitored alongside their [9] ITU, “Recommendation X.509”, Accessed 01/2022, Available:
preventive implementations, and data response must not https://www.itu.int/rec/T-REC-X.509/en
reveal critical information about the structure of API or [10] OAuth, “The Authorization Response”, Accessed 01/2022, Available:
https://www.oauth.com/oauth2-servers/authorization/the-
internal systems to a malware. authorization-response/
[11] IETF, “Transport Layer Security (tls)”, 12/2021, Accessed 01/2022,
X. REFERENCES Available: https://datatracker.ietf.org/wg/tls/documents/
[1] M. F. Ibrahim & M. A. M. Ariffin, “API Vulnerabilities In Cloud [12] OAuth, “OAuth 2.0 Authorization Code Grant”, Accessed 01/2022,
Computing Platform: Attack And Detection”, International Journal of Available: https://oauth.net/2/grant-types/authorization-code/
Engineering Trends and Technology, 10/2020, Available:
https://www.researchgate.net/publication/344867986 [13] IETF, “JSON Web Token (JWT)”, 05/2015, Accessed: 01/2022,
Available: https://datatracker.ietf.org/doc/html/rfc7519
[2] Upwork Staff, “SOAP vs. REST: A Look at Two Different API
Styles”, 08/2021, Accessed: 01/2022, Available: [14] P. Siriwardena, “Advanced API Security - OAuth 2.0 and Beyond
https://www.upwork.com/resources/soap-vs-rest-a-look-at-two- Second Edition”, apress, 2020
different-api-styles [15] IETF, “JSON Web Encryption (JWE)”, 05/2015, Accessed 01/2022,
[3] S. Castellani, “What are the different types of APIs?”, 04/2020, Available: https://datatracker.ietf.org/doc/html/rfc7516
Accessed 01/2022, Available: https://blog.axway.com/amplify- [16] A. S. Isha and M. Revathi, "Automated API Testing", 3rd
products/api-management/different-types-apis International Conference on Inventive Computation Technologies
[4] S. J. Bigelow, “What are the types of APIs and their differences?”, (ICICT), 11/2018, pp. 788-791, doi:
02/2021, Accessed: 01/2022, Available: 10.1109/ICICT43934.2018.9034254, Available:
https://searchapparchitecture.techtarget.com/tip/What-are-the-types- https://ieeexplore.ieee.org/document/9034254
of-APIs-and-their-differences [17] OWASP, “API Security Top 10 2019”, Accessed: 01/2022, Available:
[5] OAuth, “OAuth Access Tokens”, Accessed 01/2022, Available: https://owasp.org/www-project-api-security/
https://oauth.net/2/access-tokens/ [18] I. Odun-Ayo & C. Okereke & O. h. Evwieroghene, “Cloud and
[6] B. Kasthurirengan, “From Batter to Cake: Bake your Own Security Application Programming Interface”, The World Congress on
Model in API Management”, International Journal of Computer Engineering 2018 London, 07/2018, Available:
Trends and Technology Volume 68 Issue 10, 14-20, 10/2020, https://www.researchgate.net/publication/333402621_Cloud_and_Ap
Available: https://www.researchgate.net/publication/344876988 plication_Programming_Interface
[7] The OpenLDAP Project, “The OpenLDAP Project Overview”, [19] IBM, “API logging”, DataPower Gateways, Accessed 01/2022,
Accessed 01/2022, Available: https://www.openldap.org/project/ Available:
https://www.ibm.com/docs/en/datapower-gateways/2018.4?
[8] L. Tang & L. Ouyang & W.-T. Tsai, “Multi-factor web API security topic=gateway-api-logging
for securing Mobile Cloud”. 2163-2168.
10.1109/FSKD.2015.7382287, 08/2015, Available: [20] The Apache Software Foundation, “Apache Commons Logging”,
https://www.researchgate.net/publication/304293991 Accessed 01/2022, Available:
https://commons.apache.org/proper/commons-logging/guide.html

T. Jackisch, Assignment 2: API Case study ©2022 Glyndŵr University

View publication stats