Site icon 지락문화예술공작단

Secure Your API Gateway with NGINX App Protect WAF

Secure Your API Gateway with NGINX App Protect WAF

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:

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, they can stop attacks before it affects the entire network, and provide 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.

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 everchanging 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 between 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 could have hundreds of endpoints and a single application could 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 200 – 1,000 apps, with 77% running applications in multiple clouds. And 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

Businesses operating today 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 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 gateway 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 providing authenticating and authorizing API clients to secure your APIs, and rate limiting to secure your API-based services from overload. These tools also secure your APIs from top OWASP API vulnerabilities:

Fortify Your APIs With F5 NGINX App Protect WAF

Securing your API gateway with 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 (XXS), and several 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 SIEMs 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) then this is 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 sensitive data (i.e. Personally Identifying Information [PII]) handling for 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, allows for the payload to remain fully encrypted until it gets decrypted at the API gateway. Thus, your APIs can stay protected while meeting sensitive data handling requirements.

Multi-layer Protection with F5 NGINX App Protect WAF

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 when moving from a load balancer with a WAF at the edge, to inside your environment using an API gateway with a WAF, is you have tighter and more granular security control. This can then be handed off to an API team to make the security 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 security control changes on a WAF that is centralized and maintained by a security team. Changes in that WAF will require approval and testing, so it could have an impact on other APIs and apps.

NGINX App Protect WAF can perform OpenAPI schema validation, verifying if requests are compliant with what the API can support (methods, endpoints, parameters, etc.). This is why it’s ideal to have NGINX App Protect WAF providing positive security at the API gateway, behind a centralized WAF at the load balancer.

“Security as Code” to Keep Pace with API Deployments

The CI/CD pipeline was 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 moving security earlier into the app development lifecycle, DevOps moves towards a DevSecOps culture and security is treated as code.

Whether your WAF is located at the API gateway and/or the load balancer, WAF configurations need to be deployed in an automated fashion to keep up with the 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 appear as an afterthought.

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

When automating the API schema, any time you update an API you also need the configuration and code to be updated 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 want to put a WAF to protect your APIs, having 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 compute in the cloud.

In GigaOm’s High-Performance Application Security Testing Report, the performance of NGINX App Protect WAF was tested against the AWS WAF, Azure WAF, and ModSecurity OSS 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 our WAF into our NGINX API gateway, resulting in one less hop for API traffic. Fewer hops between layers reduces both 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 and part of the CI/CD pipeline and the entire software development lifecycle (SDLC). Not only does this help to support release velocity, but it also helps organizations build reliable and protected APIs while bridging gaps between DevOps and SecOps teams, enabling a cultural shift towards achieving 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.

The post Secure Your API Gateway with NGINX App Protect WAF appeared first on NGINX.

Source: Secure Your API Gateway with NGINX App Protect WAF

Exit mobile version