Volume 5, Issue 12, December – 2020 International Journal of Innovative Science and Research Technology

ISSN No:-2456-2165

Security Considerations in Implementing Robust

Stateless APIs
Muhtar Hanif Alhassan
Department of Computer Science
National Open University of Nigeria
Abuja, Nigeria

Abstract:- This paper focuses on the salient security • Simple Implementation REST APIs are less complex
implications of the inherent statelessness that because there is no need for server-side state
characterises Representational state Transfer (REST) synchronization logic.
APIs. The ever rising popularity of the REST
architecture has resulted in its widespread application in
the development and deployment of web services for
implementing efficient enterprise solutions. REST
techniques enable applications to share resources of a
variety of nature seamlessly over the web thus making it
possible to provide integration and interoperability. The
REST API technique does not require storage of
complex states in memory and is also characterised by
simple logical structures. It is this inherent simplicity
that leads to issues with security that will be covered in
Figure 1 SOAP Message Structure
this paper.
II. WEB SERVICES
Keywords:- Component; Formatting; Style; Styling; Insert.
Generally, a web service is a piece of software that
I. INTRODUCTION
facilitates communication between two web entities or
devices on a network. Thus, a web service must include a
Web applications are increasingly dominating the ICT
service provider, (the server) and a service requester, (the
enterprise solution arena for a few reasons. These
client). Web services are language independent making it
applications provide platform independence, enhanced
possible to implement services in Java, PHP, C#, or any
interoperability, and high levels of integration through
other language while the client application is written in any
application programming interfaces (API). Thus, there is a
language too. In their initial appearance web services had
growing tendency to replace desktop software with Web
huge specifications and cumbersome formats such as WSDL
based solutions in supporting modern enterprise information
(Web Service Definition Language) for describing the
systems. As we brace ourselves to embark on inevitable
services and SOAP (Simple Object Access Protocol) f or
digital transformation in Nigeria there is the need to support specifying the message formats. On the other hand, we can
resource exchange among stakeholders so as to avoid
describe the REST service in a plain text file and use any
duplication of efforts and ensure optimum utilization of
message format we want, such as JSON, XML or even plain
resources.
text again. The simplified approach was applied to the
security of REST services as well; no defined standard
The REST technique provides a set of rules that define imposes a particular way to authenticate users.
how resources are exchanged in a distributed system. REST-
based APIs enable mobile devices, web browsers, web
III. SIMPLE OBJECT ACCESS PROTOCOL (SOAP)
servers, and other hosts to create, read, update and delete
WEB SERVICES
resources according to the REST rules. When conforming to
statelessness, no state of the client session is ever stored on
A SOAP Web service is implemented as an XML-
the server side. This implies that each client request must
based protocol and all security related data can be inherently
contain the total information needed to process it.
defined in the SOAP header element. The protocol enables
the development of interoperable software and is not tied to
Statelessness provides significant advantages some of any specific operating system or programming language.
which are
• Enhanced Scalability The APIs can be scaled to millions
The SOAP message has an envelope structure as
of concurrent users by deployment on multiple servers.
depicted in Figure 1. The message envelope is designed to
Any server can handle any request because there is no
carry application payload in the body portion and control
inherent session related dependency.
information in the header portion. The header portion thus

IJISRT20DEC039 www.ijisrt.com 48
Volume 5, Issue 12, December – 2020 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
can contain any number of SOAP header blocks that include The widespread deployment of REST APIs means that
addressing, security, and other message requirements. The sensitive data such as credit card information, health records,
SOAP security header is Web Service Security (WS- financial information, business information, and many other
Security, WSS) which an extension to SOAP for supporting categories gets exchanged over the network at a colossal
web service security. It is a part of Web service specifications scale making it necessary for developers to pay attention to
published by the Organization for the Advancement of the security issues that are inherent in the process. Some of
Structured Information Standards (OASIS). these issues include:
• HTTP requests and HTTP responses are accessible to
The WSS extension enables SOAP to specify how potential hackers and since REST APIs rely on HTTP to
integrity and confidentiality can be enforced on messages and exchange information usually saved and sometimes
allows the communication of various security token formats, executed on many servers this could lead to many unseen
such as Security Assertion Markup Language (SAML), breaches and leaks.
Kerberos, and X.509. Its main focus is the use of XML • The REST API server can be attacked from the client
Signature and XML Encryption to provide end-to-end side by the consumer of the REST API just as the attack
security. could be from the REST API server under the control of
an attacker who creates a malicious app to be consumed
IV. RESTFUL WEB SERVICES by REST API client.
• Since APIs inherently provide a mechanism for exchange
RESTful web services are implemented based on of resources the other side typically has full control of
REST Architecture which is centred around the concept of resource presentation, which makes it possible for the
resources. These web services are light weight, simple, injection of malicious payload that could attack resource
scalable and easy to maintain. These attributes make handling.
RESTful web services popular for creating APIs for web- • Potential vulnerabilities can occur during controller
based applications. The REST architecture is based on the mapping (from /to the HTTP message with the resource
HTTP protocol and revolves around resources as it views URI).
every component as a resource accessible via a common • There is also a risk of attack when instantiating the object
interface using HTTP. representing the target resource and invoking the
requested operation.
• Furthermore, vulnerabilities arise during the generation
Thus, a typical REST system consists of a REST Server
of state representation for the target resources.
that provides access to resources and a REST client that
• Another point of vulnerability is during the accessing and
accesses and / or modifies the resource. Each resource is
or modification of data in the backend system hosting the
identified by either a URI (Uniform Resource Identifier) or a
resource state like when saving into the database storage.
global ID. A resource can typically represented as text, JSON
or XML. RESTful web services must be secured so as to
protect the data provided via RESTful endpoints. Clear VI. REST API SECURITY THREATS
access rights must be defined especially for methods that
In this section, we consider the potential threats that
destroy or modify resources. Thus, proper authentication of
must be considered when implementing a robust REST-
users allowed access to such methods is a high priority.
based API. As organizations increasingly depend on APIs
RESTful web services rely on the inherent security of the
for their business needs, developers must proactively prepare
API rather than including within the REST architecture.
to confront these threats. System and application developers
Though RESTful API calls are typically secured with HTTPS
in collaboration with corporations, foundations and
protocol, there is usually a need to implement some form of
volunteers have come together to form the Open Web
session-based security. Popular solutions that provide this
Application Security Project (OWASP) a nonprofit
include OAuth 2.0 and JWT which we shall discuss later.
foundation that works to improve the security of software.
[2]
V. SECURITY VULNERABILITIES IN REST-
BASED APIS
Some of the key (OWASP defined) threats facing
The current popularity of APIs as the drivers of web REST APIs are listed below:
applications and their integration to support resource 1. Injection Attack This threat is realised by embedding
exchanges over the Internet means that organizations malicious code into an unsecured application to facilitate
consider API security as the single biggest challenge that attacks such as SQL injection and cross-site scripting.
should be tackled in the years ahead. A 2018 survey by The attacker tries to manipulate the system by
Jitterbit found that 64% of organizations are creating APIs transferring untrusted data into the API as part of the
for both internal and external consumption. It was also request. If the interpreter processes the corrupted input
established that while about 25% of the respondents are not this can result in the attacker gaining unauthorised access
creating APIs at all, 40% leverage APIs for their to information or the ability to modify data.
operations.[3] 2. Denial of Service (DoS) Attacks The aim of the attacker
in this case is to render the RESTful API non-functional

IJISRT20DEC039 www.ijisrt.com 49
 Volume 5, Issue 12, December – 2020 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
by overwhelming it with enormous messages with in the cookie against the session information stored in
requests that contain invalid return addresses. memory. Figure 2 illustrates the basic implementation of
3. Broken Authentication In this case the attacker is able to session-based authentication. Session based authentication
bypass or take control of the authentication methods was the traditional way of coping with statelessness. Then
implemented in the web programme. Thus web tokens, at every request the server must check the session before
API keys, passwords , etc can be compromised. sending the response. Thus every time a user is
4. Sensitive Data Exposure This threat is brought about by authenticated, the server creates a record and stores it
poor or missing sensitive data encryption. The encryption usually in memory resulting on increased overhead when
should normally be available for sensitive data both in there are many users authenticating. More importantly,
transit and at rest. server based authentication poses a a big hinderance on
5. Broken Access Control This threat is characteristic of scalability because session information is stored in
missing or inadequate access control leading to the memory. Having vital information in session memory
attacker gaining control of other users account, and the limits the ability to replicate servers and provide
ability to alter access privileges, change data and carry scalability. Keeping session information on a user on a
out other malicious operations. particular server would require us to keep sending that
6. Parameter Tampering This is an attack that seeks to user to the same server that they logged in at (called
manipulate the parameters that are exchanged between session affinity) thereby hindering replication and load
the client and the server so as to change application data balancing.
like user credentials, permissions, sensitive values , and
so on. The success of the attack depends on the integrity
and logic of the validation mechanisms implanted in the
API.
7. Man-In-The-Middle (MITM) Attack In this attack the
attacker secretly relays and possibly alters the
communications between the client and the server even
though they believe that they are directly communicating
with each other. Thus the attacker intercepts the private
and confidential data that is passed between the two
parties. MITM attacks occur in two stages: interception
and decryption of the sensitive data. A MITM attack can
succeed only when the attacker impersonates each
endpoint sufficiently well to satisfy their expectations. Currently a more popular approach is to use JSON
thereby circumventing mutual authentication. Web Token (JWT) instead of sessions for providing
authentication. Figure 3 shows how this is done. Here the
VII. STRATEGIES FOR SECURING REST APIS server generates JWT with a secret and sends the JWT to the
client. The client keeps the JWT in local storage and
We have seen that RESTful Web services rely on subsequently includes the token in the header of every
HTTP URL Paths to operate. It is therefore clear that to request. To provide the appropriate response the server then
safeguard them we need to take similar steps used in validates the JWT with every request from the client. The
protecting regular websites. Some of these measures include: validation is carried out by checking if the JWT signatures
• Input Validation All inputs to the server must be validated match. Thus the user’s state is not stored on the server but
to prevent SQL and NoSQL injection attacks. Though resides in the token stored on the client side. The server
validation is aimed at protecting the server, it makes sense simply keeps the secret signature of the JWT. Token
to have a validation layer on the client so as to authentication is thus completely stateless and supports
interactively indicate errors and give advice on how to scalability. Load balancers are able to pass a use along to
improve the input. The primary goal of validation is to any available server since there is no need for state or
verify that the value of a data item belongs to a given set session information anywhere.
of acceptable values. For an API this means verifying that
data items coming to the application from external sources
have acceptable values. This is achieved by defining data
validation rule for every type of data item coming into the
system.
• Authentication The stateless nature of HTTP and RESTful
services necessitates the use of either sessions or tokens to
implement authentication. In session based authentication,
the server creates a session for the client after login. Thus
a session ID is created and stored on the server. The
session ID is then embedded in a cookie which is sent to
the client where it is stored. While the client remains
logged in, the cookie is sent along with every subsequent
request and the server compares the session ID embedded

IJISRT20DEC039 www.ijisrt.com 50
Volume 5, Issue 12, December – 2020 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
• Keeping Out Sensitive Data from the URL The URL IX. OAUTH
should never contain username, password, session token
and other sensitive data. Such important values should OAuth is short for Open Authorisation which is an
only be passed to the Web service using POST methods. open standard authorisation framework built around token-
• Place Restriction on Verbs The use of methods like GET, based authorisation on the Web. The framework enables
POST, and DELETE should be restricted. The GET third party services to use an end user’s account information
method which tends to encourage placing parameters in without exposing the user’s password. OAuth acts as an
the URL should never be used delete data. It is also intermediary on behalf of the end user by providing the third
important to ensure that any PUT, POST, and DELETE party with an access token that authorises the scope of
requests are protected from Cross Site Request Forgery. information to be shared. For this arrangement to work the
XML serialiser so as to avoid XML injection. Similarly, client application must have registered with the API
for JSON encoders it is important to use a proper JSON (Resource and Authorisation Servers) in the first place.
serializer for encoding user-supplied data to avoid Registration involves providing the services with the client
arbitrary Javascript remote code execution. application’s name, website, callback URL as a minimum.
Then the API sends back to the client application a Client ID
VIII. THIRD PARTY AUTHORISATION and Client Secret code that will be required every time the
client makes a request.[5]
There are numerous situations in which the resource
owner might want to provide authorisation to a third party
Figure 4 shows how OAuth2 facilitates authentication.
for limited access to some restricted resources. Traditionally
It supports four types of grants to third parties. These are:
this would involve the resource owner having to share
credentials with the third party. Such an arrangement pauses
1. Authorisation Code Grant used for applications running
issues that include
on web servers
1. the need to store resource owner’s credentials on the
2. Password Grantis used to exchange a user’s credentials
third party applications for subsequent use
for an access token. In this case the client application has
2. the inherent need to use password-type authentication
to collect the user’s password and send it to the
with its characteristic security weakness
authorization server. This type of grant it is not
3. the resource owner is unable to restrict duration and
recommended because of the need for password
scope of access once the credentials have been
exchange and is only in use by banking systems that are
transferred to the third party application
yet to implement best practice in OAuth2.0
4. there is very little support for revoking access to an
3. Implicit Grant previously recommended for native apps
individual third party without revoking access to all other
and JavaScript apps where the access token is returned
third parties.
immediately without an extra authorization code
5. a security breach on any third party application would
exchange step. This is now considered too risky and
result in compromising the end-user’s password and all
many servers do not support it.
of the data protected by the password.
4. Client Credentials Grant is used by clients to obtain an
access token outside of the context of a user. This is
From the above it soon became clear that a solution is
typically used by clients to access resources about
required that does not rely on the use of passwords and their
themselves rather than to access a user’s resources.
subsequent exchange in supporting third party access to
selected resources spread across the globe.

Developers building web, desktop, or mobile

applications need a system that will support access to
protected data from API servers for use by these applications
without requiring the users to login with passwords. On the
other hand API developers need to allow application
developers secure access to users’ data without sharing their
passwords.

Clearly the issues at hand can be broadly categorized in

to authentication and authorization requirements that must
be ratified to provide security and data integrity.

In what follows we look at some solutions that have

been developed to address the above issues.

IJISRT20DEC039 www.ijisrt.com 51
Volume 5, Issue 12, December – 2020 International Journal of Innovative Science and Research Technology
ISSN No:-2456-2165
X. OPENID CONNECT REFERENCES

This is an identity layer on top of the OAuth 2.0 [1]. 120 HIRSCH, Fredrick, KEMP, John and ILKKA, Jani:
protocol which allows Clients to verify the identity of the ’Mobile Web Services- Architecture and
End-User based on the authentication performed by an Implementation,’John Wiley and Sons, 2006.
Authorization Server, as well as to obtain basic profile [2]. KANG, A., CRUZ, D., MUNZ, A.: ’RESTing on your
information about the End-User in an interoperable and laurels will get you Pwned!, RSA Conference, 2014
REST-like manner. OpenID Connect is thus required to JITTERBIT: ’2018 State of API Integration’, Jitterbit
provide authentication so as to augment authorisation that is Report, 2018
the focus of OAuth. OpenID Connect provides the following [3]. HARI, Subramanian: ’REST API Security
additional features: [6] Vulnerabilities’, Inter Systems Cache: ’OAuth2.0
• ID token Introduction’ 1996-2020 InterSystems Corporation,
• Userinfo endpoint for additional user information Cambridge, MA
• Standard set of scopes [4]. OpenID Foundation: https://openid.net/connect/faq/
• Standardized implementation of authentication

The ID token is normally provided in JWT format and

has three main parts, namely the header, the payload and the
signature all encrypted. Thus integration of OAuth2.0 and
OpenID connect ensures that the authorisation server is also
capable of providing authentication.

XI. CONCLUSION

RESTful web services are based on HTTP and

therefore exhibit statelessness which makes their
implementation simple. These services have become
ubiquitous as they facilitate communication among ever
increasing numbers of web entities and devices on the
Internet. Thus through these APIs sensitive data,
organisational or personal, gets exchanged over the Internet
at a colossal scale. It is therefore clear that API security is a
big challenge for all organisations. In this paper we have
looked at the main vulnerabilities and threats that these
services face and identified some of the approaches used in
tackling them. Also highlighted are the salient issues of
authentication and authorisation which can be quite tricky
when implementing REST APIs. Securing authentication
and authorisation requires a combination of front-end and
back-end methods in an optimum way to ensure that
sensitive data, such as a token, is only exchanged through
the more secure back-channel while the less sensitive data
like authorisation code, redirect URLs, request scope, etc
can be routed via the front-channel.

It is evident that back-channel authentication allows

for server-to-server communication and thus removes the
need for browser redirections. Many popular and widely
used service providers use back-channel authentication to
allow access to their services. Furthermore, back-channel
protocols provide mutually authenticated end-to-end security
via TLS (Transport Layer Security) because the
communication is point-to-point. It is hoped that ICT
strategists and practitioners in Nigeria will pay special
attention to applying these measures to enhance the tendency
of resource exchanges among organisations thereby boosting
resource utilisation and mitigating against duplication of
efforts.

IJISRT20DEC039 www.ijisrt.com 52