BLOG | NGINX

Secure Your API Gateway with NGINX App Protect WAF

Thelen Blum Thumbnail
Thelen Blum
Published May 26, 2022
Daphne Won Thumbnail
Daphne Won
Published May 26, 2022

As monoliths move to microservices, applications are developed faster than ever. Speed is necessary to stay competitive and APIs sit at the front of these rapid modernization efforts. But the popularity of APIs for application modernization has significant implications for app security. APIs are vulnerable attack targets, exposing application logic and sensitive data to other apps or third parties. As API usage grows, so does the need for API gateways.

According to F5’s 2021 State of Application Strategy Report, organizations are using various methods to modernize, and APIs top these modernization efforts:

  • 58% are adding a layer of APIs to enable modern user interfaces
  • 51% are adding modern application components (for example, Kubernetes)
  • 47% are refactoring (modifying application code itself)
  • 40% are moving to public cloud (lifting and shifting) without modernizing

Horizontal bar graph showing percentage of organizations modernizing in four different ways

As organizations grow, they can mitigate API risks by adopting an API gateway. In F5’s updated 2022 State of Application Strategy Report, we see API gateways performing best on or near the edge. Here, API gateways can stop attacks before they affect the entire network, providing uniform and consistent protection for multiple APIs. API gateways encapsulate the internal structure of an app, streamlining communication between client and API. Rather than invoking specific services, clients simply connect to the API gateway. This provides the client with a specific API, reduces the number of roundtrips between client and API, and simplifies the client code.

F5 NGINX customers have successfully deployed API gateways across distributed environments. But if your API gateway is not secure, bad actors can still get through. At NGINX, we have strong security tools to ensure your apps behind API gateways remain secure in this ever‑changing landscape.

More APIs Means More Attack Surface

APIs are not new. Web‑based APIs go back to the 1990s, and versions of APIs even existed before the Internet we know today, as communication among small, distributed networks. What we are seeing now – what has changed the game – are the modern architectures using APIs.

While APIs play a vital role in accelerating modernization, they are simultaneously becoming easier to exploit. In microservices architectures, a single API can have hundreds of endpoints and a single application can consist of many microservices that use APIs to connect to each other. This differs from monolithic apps of the past, where there was just one entry point to secure. With each microservice exposing multiple sets of API endpoints, the potential attack surface has multiplied tenfold.

F5’s 2022 report also found most organizations have between 200 and 1,000 apps and 77% run applications in multiple clouds. The more apps and APIs added to a portfolio across distributed environments, the larger your possible attack surface.

OWASP API Security Top 10 Vulnerabilities

Characteristically, APIs are open and can expose sensitive data. The Open Web Application Security Project (OWASP) highlights the most prevalent vulnerabilities in their OWASP API Security Top 10 project:

API1. Broken Object Level Authorization
API2. Broken User Authentication
API3. Excessive Data Exposure
API4. Lack of Resources & Rate Limiting
API5. Broken Function Level Authorization
API6. Mass Assignment
API7. Security Misconfiguration
API8. Injection
API9. Improper Assets Management
API10. Insufficient Logging & Monitoring

 

Today’s businesses require agility and speed as development cycles hasten. Security solutions in this vulnerable, API‑driven landscape must be adaptable, lightweight, and incorporated as part of an API’s automated deployment processes.

Start Your API Security with F5 NGINX Plus

High profile API attacks regularly grab headlines. In 2019, rideshare company Uber had a critical bug discovered in its API – a vulnerable API endpoint allowed bad actors to steal valuable data, including the authentication tokens of riders. Thankfully, this bug was discovered before any harm occurred. In 2021, LinkedIn was not as lucky – due to an API vulnerability, hackers breached data belonging to over 700 million LinkedIn users, which was then offered for sale on the dark web.

By deploying F5 NGINX Plus as your API gateway, you can enter this rapid API landscape with high performance when handling API routing and delivery. GigaOm, an independent tech research and analysis firm, benchmarked NGINX against other API gateway solutions. The benchmark results showed that NGINX was able to deliver 30,000 requests per second at less than 30ms latency, which is 1000x lower latency than the API gateways of hyperscalers.

NGINX Plus provides out-of-the-box protection against not only OWASP API vulnerabilities – its additional security protection also includes checks for malformed cookies, JSON, and XML, and validates allowed file types and response status codes. It ensures compliance with HTTP RFCs and detects evasion techniques used to mask attacks.

NGINX Plus routes API requests quickly, while authenticating and authorizing API clients to secure your APIs, and rate limiting traffic to secure your API‑based services from overload. These tools also secure your APIs from OWASP API Security Top Ten vulnerabilities:

  • Authentication and authorization mechanisms – Ensure that only clients with the right access privileges can consume your APIs. One such mechanism is claims in JSON Web Tokens (JWTs). This addresses multiple vulnerabilities in the OWASP API Security Top 10: Broken Object Level Authorization (API1), Broken User Authentication (API2), Broken Function Level Authorization (API5), and Insufficient Logging & Monitoring (API10).
  • Rate limiting policies – Protect your APIs from being overwhelmed and mitigate DDoS attacks by setting a limit on the number of requests the API gateway accepts from each API client within a defined time period. With NGINX Plus, rate limits can be specific to the source (based on the value of a JWT claim, for instance), so valid users aren’t impacted. This helps address the Lack of Resources & Rate Limiting (API4) vulnerability.

Fortify Your APIs With F5 NGINX App Protect WAF

Securing your API gateway with F5 NGINX App Protect WAF provides additional API security and mitigates against OWASP attacks like Injection (API8). Unlike other API gateway and management providers who offer the bare minimum for OWASP API protection, NGINX App Protect WAF delivers additional protection against vulnerabilities such as Remote Code Execution (RCE), Cross‑Site Scripting (XSS), and other attack vectors. NGINX App Protect WAF also provides the necessary attack visibility for Insufficient Logging & Monitoring (API10). These logged attack details can be sent to security information and event management (SIEM) systems or other customer data lakes for additional analysis.

If you’re using NGINX Plus as an API gateway and load balancer (for routing APIs that need to be exposed to the Internet and for external developers and partners), it’s a prime place to deploy NGINX App Protect WAF for protection. With one less hop for API traffic, the protection can be added with the least amount of complexity and lowest latency.

Under PCI compliance requirements for handling sensitive data (personally identifying information [PII]) in certain industries, the payload must be encrypted end-to-end across open, public networks. Having NGINX App Protect WAF at the API gateway, behind a load balancer or CDN, means the payload remains fully encrypted until it gets decrypted at the API gateway. Thus, your APIs can stay protected while meeting requirements for handling sensitive data.

Multi-Layer Protection with F5 NGINX App Protect WAF

Topology diagram of three options for deploying NGINX App Protect WAF with API gateways

You might have a load balancer, and you might have a WAF – such as F5 Advanced WAF – on that load balancer. Behind those, you’ve deployed an API gateway. So, why do you need a WAF on your API gateway if you already have one on your load balancer?

One main benefit of moving from a load balancer‑WAF combination at the edge to an API gateway‑WAF combination inside your environment is tighter and more granular control over security. Responsibility for security can be handed off to an API team to make the policies more API‑specific.

With this two‑tier approach, you can ensure your APIs stay protected even in the fastest API development and release cycles.

Adding Positive Security with OpenAPI Schema Validation

A key area where protection must be API‑specific is the validation of Swagger’s OpenAPI Specification. OpenAPI schemas are unique to each API and change with each API version. Protection based on an API’s OpenAPI schema can’t wait for an IT team to update security controls on the centralized WAF it maintains, which requires approval and careful testing to avoid unexpected effects on other APIs and apps.

NGINX App Protect WAF can validate OpenAPI schemata, verifying that requests are compliant with what the API supports (methods, endpoints, parameters, etc.). This is why it’s ideal to have NGINX App Protect WAF provide positive security at the API gateway behind a centralized WAF at the load balancer.

“Security as Code” to Keep Pace with API Deployments

CI/CD pipelines are built for speed, not security. APIs are also published more frequently than apps of the past. This is why we’re seeing a shift left movement in the API‑driven landscape. By shifting left, or applying security controls earlier in the app development life cycle, DevOps moves towards a DevSecOps culture where security is treated as code.

Icon with infinity symbol showing the DevSecOps workflow

Whether you locate a WAF at the API gateway, the load balancer, or both, WAF configurations need to be deployed in an automated fashion to keep up with API version changes. When organizations adopt a shift‑left culture and integrate “security as code” into the CI/CD pipeline, security can be built into each stage of application and API development, rather than bolted on as an afterthought.

There are many benefits to security policy and configurations being consumed as code:

  • Code can easily be pulled from a source code repository.
  • Your SecOps team can create and maintain declarative security policies to ensure the controls needed to protect the business are in place.
  • Declarative policies can be coded repeatedly into new apps and APIs.
  • Security becomes automated into the CI/CD pipeline.

When automating the API schema, any time you update an API you also need to update the configuration and code in that file. Again, automation is key. Once a shift‑left or “security first” philosophy is fully adopted, developers can easily grab that code from the repo – maintaining agility, increasing velocity, and accelerating time to market.

High-Performance Protection for Your APIs

Regardless of where you put a WAF to protect your APIs, high performance and low latency are requirements that enable your APIs to quickly respond to customers for a richer user experience. NGINX App Protect WAF’s lightweight architecture provides this high performance and low latency with extremely low computing demands in the cloud.

In its High-Performance Application Security Testing Report, GigaOm reports the result of performance testing for NGINX App Protect WAF, AWS WAF, Azure WAF, and ModSecurity Open Source WAF. GigaOm found NGINX App Protect WAF has 4.7x lower latency than the ModSecurity OSS WAF on NGINX, and 128x lower latency than AWS WAF for applications requiring high performance.

NGINX is the only vendor that embeds a WAF into an NGINX API gateway, resulting in one less hop for API traffic. Fewer hops between layers reduces latency, complexity, and points of failure. This is in stark contrast with typical API management solutions that do not integrate with a WAF (you must deploy the WAF separately and, once it is set up, API traffic has to traverse the WAF and API gateway separately). NGINX’s tight integration means high performance without compromising on security.

Conclusion

At NGINX, we offer strong API security with NGINX Plus and NGINX App Protect WAF. With the lightweight scalability of NGINX and the robustness of F5’s Advanced WAF engine, you can enter the API‑driven world confident that your modern apps are secure.

True to NGINX’s core values, NGINX App Protect WAF is a modern application software security solution that is platform agnostic and seamlessly integrates with common DevOps toolchains to remove friction and accelerate secure deployments. With declarative configuration capabilities, security can become automated as part of the CI/CD pipeline and the entire software development life cycle (SDLC). Not only does this help to speed release velocity, but it also helps organizations build reliable and protected APIs while bridging gaps between DevOps and SecOps teams and enabling a cultural shift towards DevSecOps.

Ready to try NGINX App Protect WAF for yourself? Start a free 30-day trial today, or contact us to discuss your use cases.


"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."