Towards Security-Aware Microservices: On Extracting Endpoint Data

Access Operations to Determine Access Rights

Amr S. Abdelfattah

, Micah Schiewe

, Jacob Curtis

, Tomas Cerny

and Eunjee Song

Computer Science, ECS, Baylor University, One Bear Place #97141, Waco, TX 76798-7356, U.S.A.

Keywords:

Static Analysis, Microservices, Access Rights.

Abstract:

Security policies are typically deﬁned centrally for a particular system. However, the current mainstream

architecture - microservices - introduces decentralization with self-contained interacting parts. This brings

better evolution autonomy to individual microservices but introduces new challenges with consistency. The

most basic security perspective is the setting of access rights; we typically enforce access rights at system

endpoints. Given the self-contained and decentralized microservice nature, each microservice has to imple-

ment these policies individually. Considering that different development teams are involved in microservice

development, likely the access rights are not consistently implemented across the system. Moreover, as the

system evolves, it can quickly become cumbersome to identify a holistic view of the full set of access rights

applied in the system. Various issues can emerge from inconsistent settings and potentially lead to security

vulnerabilities and unintended bugs, such as incorrectly granting write or read access to system data. This pa-

per presents an approach aiding a human-centered access right analysis of system endpoints in microservices.

It identiﬁes the system data that a particular endpoint accesses throughout its call paths and determines which

operations are performed on these data across the call paths. In addition, it takes into account inter-service

communication across microservices, which brings a great and novel instrument to practitioners who would

otherwise need to perform a thorough code review of self-contained codebases to extract such information

from the system. The presented approach has broad potential related to security analysis, further detailed in

the paper.

1 INTRODUCTION

Proper access control enforcement is difﬁcult for de-

centralized computing. One major challenge in mi-

croservice systems is the lacking of a centralized view

of the system. This leads to inconsistent data access,

violation of privacy, and disruption of data integrity,

etc. While documentation and security policies indi-

cate the intended access rights for a system, documen-

tation can quickly fall out of date, and policies can

be incorrectly implemented in the ever-changing de-

centralized environment, leaving the source code of

the system the only reliable source to determine ac-

cess rights. This type of analysis is very important

since separate teams typically implement microser-

vices that interact with data that need to consistently

https://orcid.org/0000-0001-7702-0059

https://orcid.org/0000-0001-6173-7397

https://orcid.org/0000-0002-0295-564X

https://orcid.org/0000-0002-5882-5502

https://orcid.org/0000-0002-8680-9411

enforce Create, Read, Update, and Delete (CRUD)

authorization security policies in the system.

We recognize Role-Based Access Control

(RBAC) involvement, but still, to determine which

roles to apply on which system endpoint, a lower-

level granularity must be considered broadly driven

by the underlying system data. Most role-based

access control enforcements are speciﬁcally in place

to prevent illegal access to data, represented as

data entities in databases. Thus, in more detail,

by identifying CRUD operations performed on the

various data entities, one can get a robust idea of the

permissions allotted to speciﬁc control ﬂows.

This paper proposes a methodology to analyze mi-

croservice systems’ REST endpoints with respect to

the CRUD operations performed on data entities as-

sociated with these endpoints. It is set to account for

entities across inter-service calls to reﬂect the decen-

tralized system nature. Having such information has

broad application potential, such as being able to de-

termine differences between the expected set of re-

Abdelfattah, A., Schiewe, M., Curtis, J., Cerny, T. and Song, E.

Towards Security-Aware Microser vices: On Extracting Endpoint Data Access Operations to Determine Access Rights.

DOI: 10.5220/0011707500003488

In Proceedings of the 13th International Conference on Cloud Computing and Services Science (CLOSER 2023), pages 15-23

ISBN: 978-989-758-650-7; ISSN: 2184-5042

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

quired permissions as deﬁned in the code on a given

endpoint and the inferred set of CRUD rules given as

output by our tool.

The approach analyzes the system code to (1)

gather information about inter-service calls and to (2)

infer what CRUD operations are performed based on

speciﬁed data-source calls within each endpoint’s call

paths. Next, (3) we integrate these results and com-

pute the full set of CRUD accesses performed by each

endpoint by analyzing the inter-service call ﬂow to

determine the extra CRUD operations each endpoint

runs indirectly via called services.

To assess our approach, we implemented a proto-

type tool and performed a case study on an established

microservice benchmark with 41 microservices. We

compared our results to the ground truth to assess our

results. Our results are promising for being able to

successfully accomplish this in a large microservice

codebase and indicate high accuracy for the identiﬁ-

cation of the full set of per-entity CRUD operations in

the microservices-based system.

In summary, the approach provides analysts with

a centralized view of endpoints and their data access

operations to determine proper access rights in mi-

croservice systems. Therefore, our approach aims to

support a human-centered security analysis by pro-

viding the following beneﬁts: (1) help security ana-

lysts to determine access roles to be applied on end-

points of new microservices; (2) help to analyze in-

consistent access rights across already speciﬁed end-

point access roles by assessing the intra-service and

inter-service inconsistencies across microservices; (3)

help to promote security-aware system evolution by

detecting whether performed code changes promoted

changes in data access operations and if they should

lead to endpoint access rights updates.

This paper is organized as follows: Section 2 in-

troduces related work, while Section 3 introduces the

proposed approach analysis, design and implementa-

tion details. Section 4 describes performed case study

followed by discussion on limitations and threats to

validity in Section 5. Conclusions are given in Sec-

tion 6.

2 RELATED WORK

Modern software has seen a shift to highlight the im-

portance of maintaining robust authorization security

in its applications. One example of this is commonly

seen in microservices with RBAC corresponding to

CRUD permissions which are used for controlling ac-

cess to resources such as database tables or entities.

As a result of this, we have seen increased importance

in uncovering bugs related to incorrect permissions

being applied in code bases or locating permission er-

rors by omissions within the source code. Another

important topic is inferring access permissions in soft-

ware systems, which we will also outline later.

Modern microservice systems face many chal-

lenges (Bogner et al., 2021). These relevant to our

work include: lack of a centralized system view, tech-

nological heterogeneity, insufﬁcient documentation,

and decentralized team coordination. We aim to alle-

viate some of these challenges by providing a central-

ized view of all CRUD operations executed by end-

points within a microservice system in a language-

agnostic fashion; this will yield better automated doc-

umentation and team coordination.

A method to identify conﬂicting applications of

RBAC at the endpoint level in a microservices (Das

et al., 2021) utilizes the roles deﬁned on the JSR-375

endpoints and, similar to our approach, utilizes inter-

service calls to detect inconsistencies. In contrast, this

paper focuses on the CRUD accesses each endpoint

makes as opposed to the explicit roles deﬁned on the

endpoints. In particular, we aim to infer the complete

set of CRUD accesses made on various entities to de-

termine both the security policies and the roles explic-

itly deﬁned on endpoints.

Solutions using machine learning were proposed

in (Le et al., 2015) to infer access roles for web apps.

However, they determine access permissions for users

based on dynamic analysis using existing user roles

to crawl the webpages. The approach deals with in-

consistent access rules by human intervention, which

is another downside of this approach. Our work au-

tomates the inference of CRUD access roles only by

analyzing the source code of the systems involved.

An access log mining solution (Xiang et al., 2019)

tracked changing access permissions in systems and

determined access control policy changes. However,

the system must have been deployed, and thus poten-

tially vulnerable to malicious attacks if there was an

unintended access control bug. By shifting the anal-

ysis from run-time to only source code, we can avoid

these sorts of vulnerabilities up front.

A static analysis tool named FixMeUp ﬁnds and

repairs access control bugs in PHP applications (Son

et al., 2013) since it is not uncommon for develop-

ers to accidentally omit these when writing applica-

tions. High-level speciﬁcations for identifying access

control statements are provided as input to the sys-

tem. However, their approach does not guarantee the

resulting program is semantically correct and recom-

mends reviewing the changes made by the tool. While

their approach also seeks to infer the access permis-

sions on endpoints as we do, here the goals and as-

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

sumptions are radically different. FixMeUp seeks to

create a single solution for PHP applications, assum-

ing access permissions are incorrect and attempting a

repair. Our approach creates a generic solution adapt-

able to different languages and frameworks, assuming

the software’s functionality is correct and seeking to

determine the access permissions that exist for con-

sumption by another application.

Detection of potential security holes (”security

policy differencing”) (Srivastava et al., 2011) was ad-

dressed by comparing multiple implementations of

the same API. The approach uses control ﬂow in or-

der to determine the conditions that must be met when

sensitive statements are executed in an API, which are

predeﬁned. Inconsistent access conditions result in

identifying a potential bug in one of the API imple-

mentations. Our work does not identify differences

between implementations, but infers permissions that

can be a result of some deeply nested code or external

service call that has additional required permissions.

Finally, ROLECAST statically analyzes code for

”missing” security checks during sensitive operations

in web apps, such as database writes (Son et al.,

2011). Their work is relevant because it is similar in

that we are identifying implied or possibly ”missing”

security roles on endpoints. However, we also un-

cover ”inconsistencies” by detecting differences be-

tween the set of permissions required to perform an

action (an endpoint call) and the inferred set of CRUD

permissions from our tool.

3 APPROACH ANALYSIS AND

DESIGN

Microservice systems consist of multiple codebases,

such as MS-1, MS-2, etc., and each microservice typi-

cally contains multiple endpoints. Identifying CRUD

accesses and allotting them to endpoints requires mul-

tiple steps. These steps are abstracted in Fig. 1.

The process starts with extracting the endpoints

from the whole system, such as EP-1, EP-M, etc. Af-

ter that, it identiﬁes the CRUD operations used per

each endpoint; it analyzes the endpoint source code,

converts it to a call-graph, and explores the differ-

ent accesses to data entities. The third step consid-

ers inter-service calls. It aggregates the holistic end-

points dependency graph — generated in a separate

process— with the identiﬁed CRUD operations per

microservice. It accumulates the individual CRUD

accesses from an endpoint with the CRUD operations

used in its dependencies endpoints (other microser-

vices).

Highlighting the usage of each step is shown in

Fig. 2. It illustrates a simpliﬁed use-case for reser-

vations in a hotel, such that the RentalService has an

endpoint besides an UPDATE operation used to start a

room rent process; this endpoint calls two other end-

points on RoomService and ClientService, each has

different CRUD operations as well.

Applying the process starts by extracting these

endpoints from the following three microservices:

POST /rent/room, POST /rooms/reserve, and

GET /client/blacklist. Then, it identiﬁes enti-

ties CRUD operations run by individual endpoints as

shown as UPDATE ROOM, CREATE reservation, and

READ client. Afterward, it utilizes the service de-

pendency graph to analyze which system endpoints

interact with each other and aggregates the CRUD op-

erations accordingly. Finally, Fig. 3 concludes the

expected outcome that the request access right to

RentalService should satisfy the access of the three

CRUD operations to function properly, however, both

RoomService and ClientService do not require addi-

tional CRUD operations access to proceed.

3.1 Implementation Details

Analyzing microservices-based systems presents a

steep challenge since these contain many distributed

parts that evolve independently. Also, the microser-

vices architecture encourages the heterogeneity be-

tween the included services (Cerny et al., 2020).

The proposed approach is implemented based on

ReSSA (Relative Static Structure Analyzer) method-

ology (Schiewe et al., 2022). ReSSA extracts mi-

croservice high-level conceptual components using

static code analysis; it achieves this by operating on

a language-agnostic version of an abstract syntax tree

dubbed a Language-Agnostic Abstract Syntax Tree

(LAAST). This enables the analysis of heterogeneous

microservices-based systems, such that it keeps ex-

tracting the matched components from the analyzed

source code. ReSSA operates using a list of hierar-

chical parsers that run against all nodes in LAAST.

Upon a parser matching the information stored within

the tree, it runs all sub-parsers against the descendent

nodes of the node that was matched.

Our implementation targets the Spring-Boot

framework-based systems to identify CRUD accesses

through the endpoint calls. However, ReSSA is gener-

alizable to other platforms which utilized component-

based development, as demonstrated for C++ mi-

croservice benchmark in (Schiewe et al., 2022). Fur-

thermore, most libraries offer consistent API for ac-

cessing and interacting with data entities; this empha-

sizes the potential of ReSSA to be utilized in our ap-

proach; it could identify these CRUD accesses hetero-

Towards Security-Aware Microservices: On Extracting Endpoint Data Access Operations to Determine Access Rights

MS-1

MS-2

MS-N

...

Endpoints

Identiﬁcation

EP-1

...

EP-M

MS-1

EP-1

...

EP-L

MS-N

...

CRUD Identiﬁcation

...

CRUD Operations

CRUD Dependency

Aggregation

Service Dependency Graph

EP-1

...

EP-M

EP-1

...

EP-L

Aggregated

CRUD

Aggregated

CRUD

...

Aggregated

CRUD

Aggregated

CRUD

Figure 1: Microservices CRUD accesses detection process.

POST /rooms/reserve

CREATE reservation

RoomService

GET /client/blacklist

READ client

ClientService

POST /rent/room

UPDATE ROOM

RentalService

Figure 2: Microservices use-case example.

POST /rooms/reserve

CREATE reservation

RoomService

GET /client/blacklist

READ client

ClientService

POST /rent/room

UPDATE ROOM

CREATE reservation

READ client

RentalService

Figure 3: An example after Processing.

geneously.

The following subsections walk through the steps

mentioned above in Fig. 1 to highlight the implemen-

tation perspective of our approach

3.1.1 Endpoint Identiﬁcation

The proposed approach utilizes the capabilities of

ReSSA to construct a service dependency graph. It

produces a format interface with our approach as

shown in Listing 1. It is structured per each microser-

vice to list service endpoints and user ﬂows. It shows

the endpoints and the calls performed from each end-

point to others.

ReSSA uses a pattern-matching technique to

detect the endpoints in the source code. As shown in

Table 1, the pattern used in Spring-Boot framework

that identiﬁes endpoints as any method anno-

tated @.*Mapping (covering both @PostMapping

and @RequestMapping–Spring-Boot’s endpoint-

deﬁning annotations) within a class annotated

@RestController.

Listing 1: Selected Schema for Determining Endpoint

Calls.

{

” s e r v i c e s ” : [

{

” c a l l s ” : [

{

” e n dp o i n t ” : ” / c a l l e d / e n d p o i n t / s l u g ” ,

” fro m ” : [ ”VERB / c a l l i n g / e n d p o i n t / s l u g ” ] ,

/ / A l l e n d p o i n t s p e r f o r m t h i s c a l l .

” meth od ” : ”VERB” , / / i . e . GET , POST , PUT

, e t c .

Implementation available at http://github.com/

cloudhubs/authz-ﬂow-analysis, accessed on 2/13/2023.

” s e r v i c e ” : ” c a l l e d − s e r v i c e −name ”

} ,

. . .

] ,

” e n d p o i n t s ” : [

{

” code ma p p i n g ” : ” . . . ” , / / I d e n t i f i e r f o r

in −c o de e n d p o i n t d e f i n i t i o n o f t h e

e n d p o i n t .

” meth od ” : ”VERB” ,

” name ” : ” / s l u g ”

} ,

. . .

] ,

” name ” : ” s e r v i c e −name”

}

]

}

3.1.2 CRUD Identiﬁcation

This phase includes three parts of information to link

together as follows: the performed CRUD operations,

the target entities of these operations, and their called

endpoints.

ReSSA (Schiewe et al., 2022) has demonstrated

that it is adept at creating a design that can be eas-

ily expanded to accommodate more frameworks, we

extended its components to add CRUD operations to

match against as shown in Listing 2. However, every

framework has a unique API for accessing database

entities, so extracting these individual CRUD op-

erations entails some form of analysis of the API

the underlying library uses. The patterns used for

Spring Data framework are summarized in Table 1.

It identiﬁes four patterns of CRUD methods as fol-

lows: find.* that matches against many variations

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

of find, where all of which logically group together

for our purposes, remove, delete, and save. In

addition, these operations are required to be called

through an @Autowired .*Repository. Mapping

these APIs with the CRUD operations, such that find

corresponds to the READ operation, while remove and

delete correspond to the DELETE operation. save is

tricky; it corresponds to both CREATE and UPDATE, de-

pending on whether the entity it saves already exists,

as illustrated in Listing 3.

Identifying the target entities of these CRUD op-

erations is the second information to extract. Inferring

the entity’s name is based on the returned type from

methods, such as ﬁnd, get, etc. For example, Foo f

= repository.get(id) implies the entity name as

Foo. In the case of the absence of the return type, the

*.Repository naming convention-based heuristic is

employed, for example, FooRepository implies that

Foo is an entity name.

Listing 2: Selected Schema for Entity CRUD Operations.

{

” e n d p o i n t m e t h o d ” : {

” e n t i t y ” : {

”CREATE” : b o o l e a n ,

”READ” : b o o l e a n ,

”UPDATE” : bo o l e a n ,

”DELETE” : b o o l e a n

} , . . .

}

Listing 3: Common difference between CREATE and

UPDATE usage in TrainTicket Benchmark (from con-

tacts.service.ContactsServiceImpl).

/ / Method p e r f o r m i n g a CREATE

@O ve rri de

p u b l i c R e s p o n s e c r e a t e C o n t a c t s ( C o n t a c t s c o n t a c t s ,

H t t p H e a d e r s h e a d e r s ) {

C o n t a c t s c o n t a c t s T m p = c o n t a c t s R e p o s i t o r y .

f i n d B y I d ( c o n t a c t s . g e t I d ( ) ) ;

i f ( c o n t a c t s T m p ! = n u l l ) {

/ / . . .

r e t u r n new Res pon se <>(0, ” A l r e a d y E x i s t s ” ,

c o n t a c t s T m p ) ;

} e l s e {

c o n t a c t s R e p o s i t o r y . s a v e ( c o n t a c t s ) ;

r e t u r n new Res pon se <>(1, ” C r e a t e S u c c e s s ” ,

n u l l ) ;

}

/ / Method p e r f o r m i n g an UPDATE

@O ve rri de

p u b l i c R e s p o n s e m odi f y ( C o n t a c t s c o n t a c t s ,

H t t p H e a d e r s h e a d e r s ) {

Resp o n s e o l d C o n t a c t R e s p o n s e = f i n d C o n t a c t s B y I d

( /

* *

/ ) ;

/ / . . .

C o n t a c t s o l d C o n t a c t s = ( C o n t a c t s )

o l d C o n t a c t R e s p o n s e . g e t D a t a ( ) ;

i f ( o l d C o n t a c t s == n u l l ) {

/ / . . .

r e t u r n new Res pon se <>(0, ” C o n t a c t s n o t

found ” , n u l l ) ;

} e l s e {

o l d C o n t a c t s . se tN am e ( c o n t a c t s . getName ( ) ) ;

o l d C o n t a c t s . s e t Docu m e n tTyp e ( c o n t a c t s .

ge t Do c ume ntT ype ( ) ) ;

o l d C o n t a c t s . setDo cu mentN um ber ( c o n t a c t s .

getDo cumentN um ber ( ) ) ;

o l d C o n t a c t s . s e tPh o neN u mber ( c o n t a c t s .

ge tPh on eNu mb er ( ) ) ;

c o n t a c t s R e p o s i t o r y . s a v e ( o l d C o n t a c t s ) ;

/ / . . .

r e t u r n new Res pon se <>(1, ” Mo dify s u c c e s s ” ,

o l d C o n t a c t s ) ;

}

The third part of the information is achieved by

linking the extracted CRUD operations with their cor-

responding endpoint. The approach matching be-

tween the code mapping ﬁeld from Listing 1 with the

endpoint method ﬁeld from Listing 2 to indicate the

[contains] relationship between them. We generate a

simple call-graph based on method names, it identi-

ﬁes what interface methods call what helper methods

to run business logic. This allows us to trace any pos-

sible attempted CRUD operation back to its originat-

ing endpoint, generating the desired output mapping.

A summary of the general structure that we are match-

ing can be found in ﬁg. 4, it describes the ﬂow start-

ing from the @RestController that contains the end-

points’ implementations, then matched the @Service

related call to its implementation, then identiﬁes the

localCall that performs the CRUD operations calls.

3.1.3 CRUD Dependency Aggregation

Once we have the output for both the endpoint calls

and the CRUD operations per endpoint, we can be-

gin the ﬁnal step to infer CRUD operations for end-

points in the whole system. It analyzes the ﬂow of

calls through the system and their entity CRUD op-

erations. The approach introduces an algorithm as

shown in Listing 4. It iterates as follows for every

endpoint in every microservice controller: visit all of

the recorded calls to other endpoints that occur within

the endpoint. Merging the operations between the

callee is simply adding the operations from the called

endpoint to the callee endpoint, and never removing

entity CRUD operations. We continue this iterative

process over each endpoint until a full pass over all

of the endpoints results in no endpoint’s entity CRUD

operation changes, or until it has been repeated over

Towards Security-Aware Microservices: On Extracting Endpoint Data Access Operations to Determine Access Rights

@RestController

Controller

@Autowired

FooService service

contains-field

@*Mapping method()

contains-method

service.apiMethod()

contains-call

@Service

FooServiceImpl

@Autowired

*Repository repo

contains-field

@Override apiMethod

contains-method

this.localCall()

Contains call

superinterface-to

localCall

contains-method

repo.find*() or

repo.save(…) or

repo.delete(…)

contains-call

maps-to

Figure 4: Architecture of in-code structure containing CRUD accesses.

all the endpoints in the graph. This allows us to con-

tinue adding CRUD operations as changes are being

rippled throughout the endpoints in the services.

Listing 4: Pseudocode: identify the set of CRUD operations

using inter-service call ﬂow.

p r o c e d u r e m e r g e c r u d a c c e s s ( e1 , e2 ) :

i f ! e1 . c r u d a c c e s s :

e1 . c r u d a c c e s s = e2 . c r u d a c c e s s

r e t u r n

/ / Add eac h CRUD o p e r a t i o n f o r e v e r y e n t i t y

f o r ea c h e n t i t y i n e2 . c r u d a c c e s s :

f o r ea c h c r u d o p i n e n t i t y . c r u d o p e r a t i o n s :

e1 . c r u d a c c e s s [ e n t i t y ] += c r u d o p

/ / I n i t i a l i z e t h e s e r v i c e e n d p o i n t ’ s b a s e CRUD

a c c e s s

/ / o p e r a t i o n s

f o r ea c h s e r v i c e e n d p o i n t e :

e . c r u d a c c e s s = e n d p o i n t c r u d a c c e s s e s [ e .

code ma p ping ]

l e t c r u d a c c e s s c h a n g e d = f a l s e

f o r | e n d p o i n t s | :

f o r ea c h s e r v i c e e n d p o i n t e :

/ / Add a l l CRUD a c c e s s r u l e s fro m e v e r y c a l l e d

/ / s e r v i c e

f o r ea c h s e r v i c e c a l l c made by e :

l e t o l d c r u d a c c e s s = e . c r u d a c c e s s

m e r g e c r u d a c c e s s ( e , c . e n d p o i n t )

c r u d a c c e s s c h a n g e d =

( e . c r u d a c c e s s ! = o l d c r u d a c c e s s )

| | c r u d a c c e s s c h a n g e d

i f ! c r u d a c c e s s c h a n g e d : bre ak

r e t u r n e n d p o i n t s w i t h me rg ed CRUD o p e r a t i o n s

4 CASE STUDY

To test our proposed approach, we implemented a

proof-of-concept for our three-step process. We

then tested this proof-of-concept on the TrainTicket

testbed (Zhou et al., 2018)

. This testbed has a total

of 41 microservices that were implemented using the

Java Spring-Boot framework.

We ran the case study against TrainTicket’s code-

base and validated this against a ground truth that we

determined. This ground truth was partially recon-

structed by manually identifying where CRUD ac-

cesses were and what services called each other. A

simple script was created to tie user ﬂows together

and copy/paste CRUD operations as needed. It pro-

duces a total of 1364 CRUD operations identiﬁed.

The proposed technique identiﬁed 1322 of them au-

tomatically, yielding 96.9% accuracy overall.

4.1 Discussion and Limitations

Let us discuss more those 42 CRUD operations

that were missing in our identiﬁcation result. Four

CRUD operations were misinferred because they mis-

matched the heuristic naming convention technique

that we used to identify the entity names. Once in-

heritance hierarchy information is matchable within

ReSSA, this error will be resolved because it will be a

more reliable way to identify the targeted entity name.

The remaining 38 misinferred CRUD operations

are resulted from the classiﬁcation of CREATE and

UPDATE operations. In our initial implementation, we

TrainTicket testbed: https://github.com/

FudanSELab/train-ticket, used commit hash

a4ed2433b0b6ab6e0d60115fc19efecb2548c6cd, accessed

on 2/13/2023.

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

Table 1: The Matching Patterns for Spring-Boot Framework.

Identiﬁed Components Matching Patterns

CRUD Operations

find.*

remove

delete

save

Repository Instance

@Autowired .*Repository

Endpoint Methods

Class: @RestController

Method: @.*Mapping

attempted to delineate them based on a common pat-

tern of usage: that saving an object retrieved from a

database is always an UPDATE, and that saving an ob-

ject not retrieved from a database is always a CREATE,

as illustrated before in Listing 3. Comparing the total

set of CREATE and UPDATE operations that are inferred

using this heuristic yields 74% accuracy against the

ground truth. This is not a particularly compelling re-

sult. However, there are a few more cases that are

related to this CREATE and UPDATE heuristic.

One case is shown in Listing 5. This call to

save is both a CREATE and an UPDATE. The heuristic

fails to recognize it since it could depend on control

ﬂow (whether repository.findByIndex(0) is null

or not). This could be solved using a similar method

handling multiple endpoint targets for inter-service

calls in the service call-graph generating ReSSA. On

the other hand, recording it could be proposed in-

stead of attempting to classify it in a binary fashion.

However, this would not solve all misidentiﬁed entity

CRUD operations.

Listing 5: TrainTicket UPDATE not matching our heuristic

(from consignprice.service.ConsignPriceServiceImpl).

@O ve rri de

p u b l i c R e s p o n s e c r e a t e A n d M o d i f y P r i c e ( C o n s i g n P r i c e

c o n f i g ,

H t t p H e a d e r s h e a d e r s ) {

/ / . . . o m i t t e d f o r s p a c e . . .

/ / u p d a t e p r i c e

C o n s i g n P r i c e o r i g i n a l C o n f i g ;

i f ( r e p o s i t o r y . f i n d B y I n d e x ( 0 ) != n u l l ) {

o r i g i n a l C o n f i g = r e p o s i t o r y . f i n d B y I n d e x ( 0 )

;

} e l s e {

o r i g i n a l C o n f i g = new C o n s i g n P r i c e ( ) ;

}

o r i g i n a l C o n f i g . s e t I d ( c o n f i g . g e t I d ( ) ) ;

/ / . . . a s s i g n o v e r a t t r i b u t e s f r om p a r a m e t e r

c o n f i g . . .

r e p o s i t o r y . s a v e ( o r i g i n a l C o n f i g ) ;

r e t u r n new Res pon se <>(1, s u c c e s s ,

o r i g i n a l C o n f i g ) ;

}

Another case the heuristic did not account for is

shown in Listing 6. The update is performed by val-

idating that the database contains the desired infor-

mation, followed by creating a new data object con-

taining the validated information and saving this new

object to perform the update. While it is an odd way

of performing an UPDATE (and arguably risky, given

the chances of accidentally overwriting attribute val-

ues with null if the data schema changed and you

didn’t start setting the new attributes as well), it is still

a valid way of performing an UPDATE that we must

consider in the future.

Listing 6: TrainTicket UPDATE not matching our heuristic

(from conﬁg.service.ConﬁgServiceImpl).

@O ve rri de

p u b l i c R e s p o n s e u p d a t e ( C o n f i g i n f o , H t t p H e a d e r s

h e a d e r s ) {

i f ( r e p o s i t o r y . findByName ( i n f o . getName ( ) ) ==

n u l l ) {

S t r i n g r e s u l t = c o n f i g 0 + i n f o . getName ( ) +

” d o e s n ’ t e x i s t . ” ;

r e t u r n new Res pon se <>(0, r e s u l t , n u l l ) ;

} e l s e {

C o n f i g c o n f i g = new C o n f i g ( i n f o . getName ( ) ,

i n f o . g e t V a l u e ( ) , i n f o . g e t D e s c r i p t i o n ( )

) ;

r e p o s i t o r y . s a v e ( c o n f i g ) ;

r e t u r n new Res pon se <>(1, ” U p dat e s u c c e s s ” ,

c o n f i g ) ;

}

It is clear that the heuristic used to differentiate be-

tween the use of Spring’s save as a CREATE or UPDATE

is ﬂawed based on the noted cases and others. If this

heuristic were reﬁned, our approach would capitalize

on it immediately to produce stronger results. More-

over, we consider merging CREATE and UPDATE oper-

ations in the same group of access, thus the algorithm

does not differentiate between them. This leaves all

the other CRUD operations inferred property, except

those four that are related to the misidentiﬁed entities.

In conclusion, our case study shows very promis-

ing results for identifying CRUD entity access, while

raising some framework-speciﬁc challenges with our

current toolset. It is also only limited to accessing

database entities and does not support other technolo-

gies like Redis or message queues such as Kafka yet.

Towards Security-Aware Microservices: On Extracting Endpoint Data Access Operations to Determine Access Rights

5 THREATS TO VALIDITY

Using Wohlin’s taxonomy (Wohlin et al., 2000), we

examined four types of validity threats: construct va-

lidity, internal validity, external validity, and conclu-

sion validity. We also elaborate on our custom thresh-

olds used in the proposed method.

5.1 Construct Validity

Construct validity refers to the accuracy of measures

in reﬂecting real-world constructs. To assess this,

we used a third-party enterprise system benchmark

based on microservices and a well-established devel-

opment framework that adheres to up-to-date devel-

opment standards and components. This benchmark

is widely used by the microservice community to

demonstrate research outcomes, thus reﬂecting realis-

tic conditions for our approach. However, our results

should be considered in the context of other frame-

works that may yield alternative results. Moreover,

the selected benchmark may introduce a biased rep-

resentation of coding practice; we countered this by

performing manual analysis.

Our method evaluates components such as CRUD

operations, repositories, and endpoint methods that

are widely recognized across platforms. We also

considered REST calls to these endpoints, although

we omitted messaging systems from our assessment.

Therefore, our method is not suitable for general pro-

grams that do not consider those components (i.e.,

Java Standard Edition).

5.2 Internal Validity

Internal validity challenges the study methods and

data analysis. Our approach demonstrates a high level

of reliability in inferring entity CRUD operations by

following endpoint calls. However, it raises questions

that require further research, such as whether it is al-

ways possible to link CRUD accesses to the endpoint

that triggered them.

Another threat to validity is the lack of support

for tracing the control ﬂow and inheritance structures

within a program and the simplifying assumptions we

had to make to solve them. Consider, for example,

the way TrainTicket links its controllers to its busi-

ness logic using an @Autowired service implementa-

tion. This auto-wired ﬁeld is the generic interface for

the service, not the concrete service class itself. It is

a simple logical leap for a human to skip from the in-

terface to the implementation; however, at this time,

ReSSA does not support tracing and matching over

such control ﬂow structures. While one can perform

simple matching over class and method names in a

system, this is snarled up by duplicated class names

or method overloads. This makes it difﬁcult to trace

the execution from the controller to business logic or

among helper methods. Although adding support for

such a connection in ReSSA would be valuable, it was

not that critical in our approach to identifying CRUD

rights.

Our approach utilizes manual analysis as the

ground truth for evaluating the performance of the

proposed method. Speciﬁcally, two authors con-

ducted the manual analysis, and the results were later

validated by a third author to reduce any potential bias

in the outcomes.

5.3 External Validity

These threats concern the generalization of our re-

sults. Our case study focused on the Java platform in

this prototyping, given its signiﬁcant presence in the

microservice domain. However, this raises questions

about the generalization of our results. Speciﬁcally,

can we generate ﬁne-grained user ﬂow mappings for

every technology and programming language? While

microservice systems support heterogeneity, our case

study shows that we can analyze a Java-based sys-

tem following its standards, but we cannot conclude

that the method is generalizable in the same setting.

Nevertheless, our method, ReSSA, demonstrated po-

tential results working for a C++ microservice bench-

mark in a customized pattern.

On the other hand, it is difﬁcult for the method

to work for applications that do not adhere to stan-

dard components and best practices. In such cases,

modiﬁcations would be necessary to consider the

application-speciﬁc naming conventions used across

architectural layers.

5.4 Conclusion Validity

The threats concern whether the conclusions are

based on the available data and metrics. We measured

the accuracy between the manual analysis results and

the produced outcome in our work, but we did not

include the measurements of precision and recall be-

cause all operations that exist in the system were iden-

tiﬁed, which makes computing the precision and re-

call uninformative given 100% recall. Nevertheless,

to examine the signiﬁcance of the results statistically,

more experiments are required over the data distribu-

tion.

Our study’s trustworthiness may have been im-

pacted by the restricted variation in the chosen system

benchmark, restricting our conclusions to our obser-

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

vations in the case study. Nevertheless, we have made

our approach available as open-source, which facili-

tates the replication of the study.

6 CONCLUSION

We presented a novel methodology for identifying

the full set of entity CRUD operations needed for

each endpoint in microservices-based systems. Such

CRUD operations are fundamental to ensuring any

proper endpoint access control. While the system

may initially have had correct access rights on all end-

points, its distributed evolution can easily cause them

to be outdated, requiring periodic veriﬁcation of all

applied access rights to prevent vulnerability. Our

three-step solution generates a mapping of endpoint

methods to their needed CRUD operations. It then

identiﬁes the call paths present within a system and

synthesizes the preceding outputs to generate a map-

ping of all endpoint calls to the full set of implied

entity CRUD operations that are needed to call this

endpoint. We have approached the problem in a gen-

eralizable manner using ReSSA methodology simpli-

fying the extension to accommodate new platforms

by analyzing a uniﬁed intermediate program repre-

sentation. We tested the proposed approach against

the TrainTicket testbed, a Java microservice system

built on the Spring-Boot framework, and veriﬁed

the results against a manually-reconstructed ground

truth. This yielded promising accuracy for identify-

ing CRUD operations for each endpoint.

In future work, we will statically analyze busi-

ness rules from the system source code and combine

these two solutions to generate an authorization ser-

vice enforcing authorization throughout the system

uniformly. Such a service would allow the cross-

cutting concern of authorization to be factored out

and handled in an automated fashion by stopping any

CRUD operation mismatches between an endpoint

and what it executes before becoming a security vul-

nerability.

ACKNOWLEDGEMENTS

This material is based upon work supported by

the National Science Foundation under Grant No.

1854049 and a grant from Red Hat Research,

https://research.redhat.com.

REFERENCES

Bogner, J., Fritzsch, J., Wagner, S., and Zimmermann,

A. (2021). Industry practices and challenges for the

evolvability assurance of microservices. Empirical

Software Engineering, 26(5):104.

Cerny, T., Svacina, J., Das, D., Bushong, V., Bures, M.,

Tisnovsky, P., Frajtak, K., Shin, D., and Huang, J.

(2020). On code analysis opportunities and challenges

for enterprise systems and microservices. IEEE Ac-

cess, pages 1–22.

Das, D., Walker, A., Bushong, V., Svacina, J.,

Cern

y, T.,

and Matyas, V. (2021). On automated rbac assessment

by constructing a centralized perspective for microser-

vice mesh. PeerJ Computer Science, 7:e376.

Le, H. T., Nguyen, C. D., Briand, L., and Hourte, B.

(2015). Automated inference of access control poli-

cies for web applications. In Proceedings of the 20th

ACM Symposium on Access Control Models and Tech-

nologies, SACMAT ’15, page 27–37, New York, NY,

USA. ACM.

Schiewe, M., Curtis, J., Bushong, V., and Cerny, T.

(2022). Advancing static code analysis with language-

agnostic component identiﬁcation. IEEE Access,

10:30743–30761.

Son, S., McKinley, K. S., and Shmatikov, V. (2011). Role-

cast: Finding missing security checks when you do

not know what checks are. In Proceedings of the

2011 ACM International Conference on Object Ori-

ented Programming Systems Languages and Appli-

cations, OOPSLA ’11, pages 1069–1084, NY, USA.

ACM.

Son, S., McKinley, K. S., and Shmatikov, V. (2013). Fix

me up: Repairing access-control bugs in web applica-

tions. In 20th Annual Network and Distributed System

Security Symposium, NDSS 2013, San Diego, Califor-

nia, USA, February 24-27, 2013. The Internet Society.

Srivastava, V., Bond, M. D., McKinley, K. S., and

Shmatikov, V. (2011). A security policy oracle: De-

tecting security holes using multiple api implementa-

tions. SIGPLAN Not., 46(6):343–354.

Wohlin, C., Runeson, P., H

ost, M., Ohlsson, M., Regnell,

B., and Wessl

en, A. (2000). Experimentation in Soft-

ware Engineering: An Introduction. The Kluwer In-

ternational Series In Software Engineering. Springer,

Germany.

Xiang, C., Wu, Y., Shen, B., Shen, M., Huang, H., Xu, T.,

Zhou, Y., Moore, C., Jin, X., and Sheng, T. (2019). To-

wards continuous access control validation and foren-

sics. In Proceedings of the 2019 ACM SIGSAC Con-

ference on Computer and Communications Security,

CCS ’19, page 113–129, New York, NY, USA. Asso-

ciation for Computing Machinery.

Zhou, X., Peng, X., Xie, T., Sun, J., Xu, C., Ji, C., and

Zhao, W. (2018). Benchmarking microservice sys-

tems for software engineering research. In Chaudron,

M., Crnkovic, I., Chechik, M., and Harman, M., edi-

tors, Proceedings of the 40th International Conference

on Software Engineering: Companion Proceeedings,

ICSE 2018, Gothenburg, Sweden, May 27 - June 03,

2018, pages 323–324. ACM.

Towards Security-Aware Microservices: On Extracting Endpoint Data Access Operations to Determine Access Rights