Modern Apps, MSA, and APIs Within
![]() <Figure 1> Architecture of Modern Apps Today, companies have strived to develop applications that reduce time and cost while improving innovation and stability to keep pace with a rapidly changing world. And we call the applications born from this effort "Modern Applications" (hereinafter Modern Apps). As such, most web applications, mobile applications, and IoT devices developed today are being developed using the MSA method. And just as MSA is at the center of Modern Apps, there is an important technical concept at the center of MSA, which is the API (Application Programming Interface). APIs are interfaces that connect different applications, playing an important role in bundling individual services into one. Ultimately, APIs are naturally included in most of the applications developed today mentioned above.
Mandatory Financial MyData and Standard APIs
APIs not only provided the innovative development concepts of Modern Apps and MSA but also have high reliability because they have been consistently used and verified as Web APIs since the 2000s. Furthermore, they are excellent in terms of security because SSL communication is possible. Thus, APIs, which are equipped with innovation, reliability, and security, have been recognized for their functions and are being used as the standard specification for Financial MyData, which became mandatory in Korea starting January 5, 2022.
![]() <Figure 2> Financial MyData Conceptual Diagram (Source: MyData Comprehensive Portal)
In other words, when providing services related to personal information in the financial sector, the use of the existing scraping method is prohibited, and services must be developed and provided solely through the API method.
Of course, the reasons for changing from the scraping method to the API method include the advantages of APIs mentioned above, but the reason for resolving the vulnerabilities of scraping—which has a high risk of customer account information leakage by retrieving all paged data and can collect excessive personal information—is also significant.
However, can we say that using APIs as a standard makes them safe without vulnerabilities? As everyone expects, that is not the case. Just as API usage has increased, various vulnerabilities are appearing, and as a representative example, a total of 2,942 CVE vulnerabilities were registered by 2021.
Then, let's examine together how to approach API security from now on.
WAAP와 OWASP API Security Top 10
The content we will examine now is about how representative global organizations and companies define the concept of API security and respond to it. Even security managers who have not yet established an API security policy will find the following introduction very helpful in strengthening API security.
First, let's look at the content presented and analyzed by Gartner, a global IT market research firm.
In 2019, emphasizing the importance of API security, Gartner presented the concept of WAAP (Web Application and API Protection), an evolved model of the Web Application Firewall equipped with four core functions: Application Protection, DDoS Protection, Bot Management, and API Protection. And in 2021, by publishing a market analysis report called ‘Magic Quadrant for WAAP 2021’, they officially introduced WAAP to the market as an independent product family.
In this way, Gartner summarized API security as an expanded concept of Web Application Firewalls that must be managed together with application protection, DDoS defense, and bot management.
In the same year that Gartner presented the WAAP concept, the Open Web Application Security Project (OWASP) also released the OWASP API Security Top 10:2019. OWASP is an organization that analyzes web application security vulnerabilities and provides vulnerability reports every 3 to 4 years. OWASP released separate vulnerabilities due to the increased usage and importance of APIs in application environments.
![]() <Figure 3> Comparison of OWASP Top 10:2021 and OWASP API Security Top 10:2019 Items
![]() <Figure 4> OWASP API Security Top 10:2019
However, looking at the content, many vulnerabilities similar to the existing OWASP Top 10 stand out.
Also, in the OWASP Top 10:2021 released in 2021, as the application development trend shifted to the cloud, a number of vulnerabilities encompassing the OWASP API Security Top 10:2019 were selected and ranked. The message that the above contents show in common is ultimately that the basis of API security is Web Application Security. And many institutions and companies are already responding excellently to web application security with security equipment called Web Application Firewalls.
Of course, the functions of a traditional Web Application Firewall may be insufficient for API security. However, like the WAAP introduced by Gartner, Web Application Firewalls have already evolved to combine API security functions, and PIOLINK's Web Application Firewall, WEBFRONT-K, is also already equipped with API security functions in line with the global market.
Then, let's find out based on which core technologies WEBFRONT-K performs API security.
Core Technologies for API Security (6 Types)
As mentioned earlier, the basis of API security is web application security. Therefore, a certain level of API security is possible just with functions such as response to representative attacks on web applications like Buffer Overflow, Injection, and XSS, prevention of sensitive information leakage, allowlists, blocklists, access log management, and blocking credential stuffing. However, to respond to OWASP vulnerabilities, which are the top priority in application security, the following technologies must be equipped.
1. mTLS (Mutual TLS)Since TLS has been used for secure connections between clients and servers for a long time, those working in information security and IT fields will know the concept well. Servers with existing TLS applied could be accessed by all clients. However, in the era of Zero Trust security like today, allowing access to all clients can be seen as security-wise vulnerable. Especially for servers that mainly provide sensitive information through APIs, allowing access only to specific clients can be the best answer. That is why the technology called mTLS appeared. mTLS is a technology where the process of the server verifying the client is added, in addition to the client verifying the server. In other words, after storing both client and server certificates in the Web Application Firewall, it performs authentication as a server when communicating with the client, and as a client when communicating with the server.
mTLS is a very important technology in API security, enough to be included as a recommended measure in the ‘Financial Sector MyData Technical Guidelines’ issued by the Financial Security Institute.
2. Identification Information CloakingWhen identification information is needed at an API endpoint, the client requests it by including the corresponding identification information. If the request field is exposed to an attacker in this process and the identification information can be easily distinguished, the attacker can use this to perform a Broken Object Level Authorization attack (OWASP API Security Top 10:2019 A1).
For example, assuming shopName is information identifying a store name as shown below, one could change this information to another name to view sensitive information such as revenue.
Example) /shops/{shopName}/revenue_data.json
Since such easily decipherable identification information has a high possibility of being abused, the Web Application Firewall must respond to the threat of such vulnerabilities through functions that encrypt or mask this information.
3. API Token Authentication and Integrity Check
Vulnerabilities regarding authentication are classified as the most fatal vulnerabilities not only in APIs but in all application environments, and indeed, vulnerabilities related to authentication are located in OWASP API Security Top 10:2019 A2 and OWASP Top 10:2021 A7. Then, what is the difference between APIs and existing authentication-related vulnerabilities?
APIs, which often use JSON, mainly use JWT (JSON Web Token) to manage user authentication and permissions. Since JWT consists of a Header (token type and algorithm), Payload (client information), and Signature (hash value created with the header, payload, and server's secret key), even if the JWT is forged or altered, it will not match the JWT issued by the server without the secret key used to create the signature.
4. Threshold and Method Limiting per APIServers require resources such as network bandwidth, server CPU, memory, and storage to process service requests normally. Since these resources are not supplied infinitely, if they are not managed with appropriate policies, attacks like DoS/DDoS can occur due to resource shortage and lack of rate limiting vulnerabilities (OWASP API Security Top 10:2019 A4).
To protect resources from such vulnerabilities, a policy that can set allowable thresholds for requests is needed. In particular, for APIs, it is necessary to limit allowable thresholds per API transaction according to the purpose of use and limit HTTP methods suitable for the purpose.
5. JSON Response CloakingDepending on the implementation form, APIs have vulnerabilities where excessive information is provided differently from the client's intention, potentially exposing sensitive information (OWASP API Security Top 10:2019 A3, A6).
For such vulnerabilities, one must check the permission of the information and, if excessive information is included, cloak it to prevent information exposure. An important point in API security is that the cloaking function must be applicable even to the JSON content type, which is the transmission format mainly used in APIs.
6. JSON Request Field InspectionNo matter how safe a system is introduced, inexperienced operation can lead to serious vulnerabilities. And one can know how dangerous this vulnerability is just by seeing that it is listed under the same name, Security Misconfiguration, in OWASP API Security Top 10:2019 A7 and OWASP Top 10:2021 A5.
Then, with what function does the Web Application Firewall respond to this vulnerability? Representative among various functions is the function that inspects the fields of the request received from the client to judge whether it is a legitimate request. And as explained in JSON Response Cloaking earlier, the key point for API security is whether technology to analyze and respond to the JSON content type is supported.
WEBFRONT-K Equipped with Core Technologies of API Security
WEBFRONT-K Equipped with Core Technologies So far, we have looked at the core technologies that WEBFRONT-K uses for API security.
To recap, if equipped with the 6 core technologies introduced above (mTLS, Identification Information Cloaking, API Token Authentication & Integrity Check, Threshold & Method Limiting per API, JSON Response Cloaking, JSON Request Field Inspection) along with the detection and response technologies of existing Web Application Firewalls, it is possible to respond to overall API-related vulnerabilities including OWASP API Security Top 10:2019.of API Security
![]() <Figure 5> WEBFRONT-K's 6 Core Technologies for API Security
API Security - Essential, Not Optional
API security is, in fact, an area of web application security that most institutions and companies were already doing best. It just felt unfamiliar because we haven't watched that part with interest until now. However, as introduced in this white paper, if you respond one by one focusing on OWASP vulnerabilities, it is not a security area that will become a major problem.
Now, in web application security, API security is an essential item, not an option. And coincidentally, 2022 is a good time to think about API security as the MyData business using APIs as a standard becomes mandatory.
Hoping that this white paper will be helpful to companies preparing for API security, we recommend those who want to receive more information to consult with PIOLINK's API security experts. |