Securing gRPC APIs with NGINX App Protect

Original: https://www.nginx.com/blog/securing-grpc-apis-with-nginx-app-protect/

In the beginning was the monolith. It served software developers well for a long time, and still does for some use cases. But as applications grew, monoliths became unwieldy to develop, secure, and maintain. Microservices came on the scene as an alternative – the monolith is broken into small and autonomous services that perform a single business function and communicate over a network to provide the full functionality of the application. Initially, web developers used SOAP as the communication protocol and XML to encode data, but many found the combination cumbersome and slow. That inspired a switch to REST‑based architectures and the widespread adoption of HTTP and JSON as the protocol and data‑serialization method, respectively.

But as is often the case with technology, developers continued to look for even better ways to design applications, for example to overcome limitations inherent to the text‑based orientation of SOAP and REST. One such system is gRPC, which Google developed to connect its vast array of independent, autonomous services. gRPC uses protocol buffers (protobufs) as a platform‑ and language‑neutral mechanism for serializing structured data, and HTTP/2 as the communication protocol.

Benefits of gRPC

Among gRPC’s advantages over other API frameworks are its low‑latency throughput, support for multiple languages, compact data representation, and real‑time streaming, all of which make it especially suitable for communication among microservices and over low‑power, low‑bandwidth networks. The popularity of gRPC has increased significantly in recent years because it makes it easier to build new services faster and more efficiently, with higher reliability and scalability, and with language independence for both clients and servers.

A prominent example of the benefits of gRPC is open banking, which uses open source technologies to build and deliver APIs, enabling third‑party developers to offer additional services to customers of a bank or other financial institution. The entire foundation of open banking is built on the ideal of delivering financial information more effectively and efficiently. gRPC helps achieve this goal because the compact format of protocol buffers and multiplexing in HTTP/2 make transfer of a given payload much faster than with REST APIs: roughly 7 times faster when receiving data and 10 times faster when sending data. As a result, financial institutions are adopting gRPC for their interservice communications to provide services faster, and with greater efficacy, reliability, and scale.

One specific use case where gRPC’s speed is a big advantage is the customer onboarding process, which in open banking is paramount for success. With other API frameworks, creating a new account can be cumbersome and time‑consuming for financial institutions and customers alike. With gRPC, speedy data transfer means customers can create a new account in minutes. This greatly boosts customer satisfaction while substantially decreasing costs for the financial institution.

Securing gRPC

The gRPC standard and the protocol buffers format are implemented as an open source library. Protocol buffers are considered to be more secure against cyberattacks than other data representations, as the library parser rejects malformed requests and looks more carefully into how the library behaves.

But some disconcerting opportunities for attacks against gRPC remain. For example, the parser:

An attacker can exploit these gaps in the gRPC protocol to compromise an application. Protocol buffers also allow the creation of fields that are not defined in the message definitions. This ensures design extensibility – enabling compatibility with future extended versions of a message – but it can also make applications vulnerable to smuggling attacks, in which attackers incorporate fields into their requests that are not explicitly coded as permitted in the application.

NGINX App Protect Secures gRPC APIs

NGINX App Protect is designed to protect modern gRPC‑based applications closer to the service application. This empowers AppDev, DevOps, and DevSecOps teams to manage application security as a code and to leverage native tools.

For example, NGINX App Protect ensures financial institutions and their services comply with open banking standards when implementing gRPC for their interservice communications. NGINX App Protect’s engine runs deep inspection of gRPC messages on wire requests, parses protocol buffer messages, and detects malicious data in the message headers and payloads, including in all nested and complex data structures. The inspection is performed against any request and applies an attack detection mechanism for each API call parameter.

With gRPC APIs, you use the gRPC interface to set security policy in the type library file (IDL file) and the proto definition files for protocol buffers. When the updated files are loaded, NGINX App Protect immediately starts applying the new security policies without the need for any changes to its configuration. gRPC proto files are frequently updated as a part of CI/CD pipelines, so updating security policies doesn’t disrupt or add overhead to your processes, and your applications are always protected by the latest, most up-to-date policy.

As well as protecting east‑west traffic between gRPC‑based microservices, NGINX App Protect secures the north‑south traffic among your publicly exposed assets.

While gRPC enhances the speed, efficiency, and scale of service-to-service communications, it’s crucial to protect and secure API data (URLS, headers, and payloads) and application services that expose gRPC APIs. That’s why NGINX App Protect is vital for your modern application architecture.

For more about gRPC with NGINX App Protect, check out our lightboard video:

Try NGINX App Protect for Free

For more information on gRPC support in NGINX App Protect, see the documentation.

To try NGINX Plus and NGINX App Protect with your gRPC APIs, start a free 30-day trial or contact us to discuss your use cases.

Retrieved by Nick Shadrin from nginx.com website.