Roadmap for a Winning API Security Strategy for Fintech

Roadmap for a Winning API Security Strategy for Fintech

A resounding 94% of IT company leaders reported they have experienced API security problems in production APIs, the SALT, a leading security research firm that identifies API security vulnerabilities, report highlights. Among the critical API, security problems are vulnerability (47%), authentication (38%), data exposure (31%), and breach (19%) over a period from July 2021 to July 2022. (Fig. 1). Malicious API attack traffic surged 117% over the past year, from an average of 12.22M malicious calls per month to an average of 26.46M calls.

kinds of attacks

In a global and growing API ecosystem Postman users signed in from an impressive 234 different countries and geographies while making 855 million API requests in the year 2021 (up 56% from the prior year). Speaking specifically of India regarding the Country-by-country API growth, the country is in the third spot for the fastest growing geographies (Fig. 2).

API Security Request Collection at Global Level

Industry-wise, Technology (29%) represents the largest industry that makes use of APIs, followed by business/IT services (28%), banking/finance/insurance (11%), and healthcare (5%). In our previous blog, we mentioned how API attacks are causing significant security concerns among fintech companies that are heavily reliant on APIs to build applications. The result? Unfortunately, 54% of respondents indicate that they have had to slow the rollout of a new application because of an API security concern.

While the reliance on APIs is pointedly high, still unfortunately only 9% of respondents can confidently state that they have an advanced API security strategy that includes dedicated API testing and protection. Meanwhile, an alarming 61% admit that they lack any API security strategy or have only basic protections. API security is considered the most important component of web application security, but before we dig deeper into the best practices for API security posture, let us first understand what defines Application Programming Interface (API) security.

What is API Security?

Application Programming Interface or API enables software applications to communicate with each other, thus enhancing interoperability, among offering other advantages. API security, therefore, means protecting APIs from vulnerable attacks. Since Application Programming Interface, also called API, is so commonly used among industries now, they also carry sensitive software data and functions, thus becoming bait for attackers.

API security is especially critical for the fintech industry which extensively embraces the API-first philosophy. We have already written a detailed insight about Open Web Application Security Project (OWASP) top 10 challenges of API security for fintech companies. This article, therefore, extends further to present several tools, methods, and best practices for securing your APIs.

Architectural Styles Used for Modern APIs: Mitigating Security Risks

Postman’s survey underscores that as many as 94% of its respondents use REST or REpresentational State Transfer as their main architectural style. Some of the other architectural styles used for engineering APIs include webhooks, WebSockets, GraphQL, and SOAP. Among these the most commonly used is also SOAP or Simple Object Access Protocol.

Among specifications, JSON Schema (used by 47%) is the top specification in use, followed by Swagger 2.0 (54%) and OpenAPI 3.0 (40%).

While REST is considered a simpler approach (and therefore most popular) and uses HTTP/S as the transport protocol, it makes use of JSON format for transferring data. SOAP in the meanwhile is the highly structured message protocol to APIs, and supports multiple low-level protocols. Both these types of architectural styles for APIs can support HTTP requests and Secure Sockets Layer (SSL). However, the difference lies in the level of security they offer.

SOAP vs REST API: Which is more secure?

Before explaining which of the two- SOAP vs REST APIs architectural styles is more secure, let us first understand the difference through the table below.

 SOAPREST
Organized in terms ofenveloped message structurecompliance with six architectural constraints
FormatXML onlyXML, JSON, HTML, plain text
Learning curve and usageDifficultEasy
Preferred for CommunitySmallLarge
Use casesPayment gateways, identity management CRM solution, financial and telecommunication services, legacy system supportPublic APIs simple resource-driven apps

API security would remain a priority regardless of the architectural approach you choose. While REST is faster and has a simpler learning curve and ease of use than SOAP, the latter is more secure, and here’s why-

Both REST and SOAP use Secured Socket Layer or SSL for data protection during API call requests, but SOAP also supports Web Services Security. This ensures adding a double layer of protection for the API security. In the case of REST, the security must be built-in for deployment, transmission, and interaction with clients.

SOAP is based upon OASIS and W3C recommendations, and includes XML encryption and signatures, and SAML tokens. Meanwhile, REST does not have its own built-in security capabilities, and the security is based on the API itself.

SOAP supports WS-ReliableMessaging that enables built-in error handling, while REST APIs have no in-built error handling and need to resend the data in case of error.

SOAP can support Web Services (WS) specifications, which enables you to use WS-Security kind of extensions. This provides enterprise-grade security for web services. On the other hand, developers’ architectural choice is deploying REST APIs behind API gateway. So, when the clients send requests for gateway connection, it acts as a proxy and does not directly go to the REST API. This poses security concerns that must be addressed by the API gateway.

The technologies associated with APIs that are most commonly preferred now include Microservices (58%) and Kubernetes (50%), followed by containers (46%), serverless architecture (44%), and GraphQL (35%). This brings us to the segment of GraphQL, the query language that describes how clients request information through APIs.

Mitigating GraphQL Security Risks

Some of the strategies that can help pacify the API security risks arising from GraphQL include-

  • Timeout: It can help you secure against large query requests. Among the simplest of all strategies, in this case, the server only needs to understand the maximum time set for a query and not the details about incoming queries.
  • Maximum Query Depth: Analysis of abstract syntax tree (AST of query document to understand what is acceptable is called the maximum query depth, and it can help in preventing clients from abusing a query depth. GraphQL server can make use of Maximum Query Depth to function requests by either accepting or rejecting them.  
  • Query Complexity- It can be used as a strategy to define the complexity level of certain schema fields which may be more complex to compute. By defining query complexity, you can also restrict those queries which do not fit into the complexity threshold bill.
  • Throttling- It can be an ideal strategy for stopping clients requesting medium-sized queries. By estimating the required server time for completing each query type, throttling can be done.

API Security Best Practices

For improving the overall API security the following best practices can be implemented-

  • Understand and Identify Vulnerabilities- Even while this could be a complex process, the only way one can effectively secure APIs is by understanding the risks at the API lifecycle steps. Organizations, especially fintech companies, must treat APIs as software artifacts that must also pass through the security stage during their own SDLC.
  • Access Control- Non-public REST services must perform access control at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorization logic, and session management. OAuth, the token-based authentication framework, could be a powerful tool for controlling API access. OAuth does not expose user credentials and also completes third-party service requests for information.
  • Encrypt Data for Database Security- Sensitive data, especially personally identifiable information or PII- all of which is managed by APIs- must be protected by way of encryption, by also considering regulations and compliance. Data encryption during rest, and also in transit, with the help of Transport Layer Security (TLS) can ensure that attackers do not compromise with API servers.
  • Consider Anti-DoS Approach- With denial of service (DoS) attacks becoming primary in API security leak, it's necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. The core essence of a DoS is to affect the availability of instances or objects and eventually render them inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.
  • Use Service Mesh- With the increase in the use of microservices, the importance of using a service mesh has increased too. Similar to the API gateways, service mesh uses different layers of control and management while routing requests. It is an ideal way for the service communication layer. In API security, service meshes can be used for automation and providing security for larger projects that require deploying multiple APIs.

Test Your API Security

It is suggested to adopt a DevSecOps approach to test web applications, with a critical focus on testing API security. With a range of API architectures, you should test your legacy or contemporary applications including REST API, GraphQL, and SOAP.

Leveraging various discovery mechanisms and tools to ensure dynamic API security, Valuebound has helped multiple fintech clients in deploying secure apps.

If you need to discuss API security with us, drop us a hello and let us wrap our head around your query to develop a feasible solution.

 

comments powered by Disqus