Use F5 Distributed Cloud to service chain WAAP and CDN
The Content Delivery Network (CDN) market has become increasingly commoditized. Many providers have augmented their CDN capabilities with WAFs/WAAPs, DNS, load balancing, edge compute, and networking. Managing all these solutions together creates a web of operational complexity, which can be confusing. F5’s synergistic bundling of CDN with Web Application and API Protection (WAAP) benefits those looking for simplicity and ease of use. It provides a way around the complications and silos that many resource-strapped organizations face with their IT systems. This bundling also signifies how CDN has become a commodity product often not purchased independently anymore. This trend is encouraging many competitors to evolve their capabilities to include edge computing – a space where F5 has gained considerable experience in recent years. F5 is rapidly catching up to other providers’ CDNs. F5’s experience and leadership building the world’s best-of-breed Application Delivery Controller (ADC), the BIG-IP load balancer, put it in a unique position to offer the best application delivery and security services directly at the edge with many of its CDN points of presence. With robust regional edge capabilities and a global network, F5 has entered the CDN space with a complementary offering to an already compelling suite of features. This includes the ability to run microservices and Kubernetes workloads anywhere, with a complete range of services to support app infrastructure deployment, scale, and lifecycle management all within a single management console. With advancements made in the application security space at F5, WAAP capabilities are directly integrated into the Distributed Cloud Platform to protect both web apps and APIs. Features include (yet not limited to): Web Application Firewall: Signature + Behavioral WAF functionality Bot Defense: Detect client signals, determining if clients are human or automated DDoS Mitigation: Fully managed by F5 API Security: Continuous inspection and detection of shadow APIs Solution Combining the Distributed Cloud WAAP with CDN as a form of service chaining is a straightforward process. This not only gives you the best security protection for web apps and APIs, but also positions apps regionally to deliver them with low latency and minimal compute per request. In the following solution, we’ve combined Distributed Cloud WAAP and CDN to globally deliver an app protected by a WAF policy from the closest regional point of presence to the user. Follow along as I demonstrate how to configure the basic elements. Configuration Log in to the Distributed Cloud Console and navigate to the DNS Management service. Decide if you want Distributed Cloud to manage the DNS zone as a Primary DNS server or if you’d rather delegate the fully qualified domain name (FQDN) for your app to Distributed Cloud with a CNAME. While using Delegation or Managed DNS is optional, doing so makes it possible for Distributed Cloud to automatically create and manage the SSL certificates needed to securely publish your app. Next, in Distributed Cloud Console, navigate to the Web App and API Protection service, then go to App Firewall, then Add App Firewall. This is where you’ll create the security policy that we’ll later connect our HTTP LB. Let’s use the following basic WAF policy in YAML format, you can paste it directly in to the Console by changing the configuration view to JSON and then changing the format to YAML. Note: This uses the namespace “waap-cdn”, change this to match your individual tenant’s configuration. metadata: name: buytime-waf namespace: waap-cdn labels: {} annotations: {} disable: false spec: blocking: {} detection_settings: signature_selection_setting: default_attack_type_settings: {} high_medium_low_accuracy_signatures: {} enable_suppression: {} enable_threat_campaigns: {} default_violation_settings: {} bot_protection_setting: malicious_bot_action: BLOCK suspicious_bot_action: REPORT good_bot_action: REPORT allow_all_response_codes: {} default_anonymization: {} use_default_blocking_page: {} With the WAF policy saved, it’s time to configure the origin server. Navigate to Load Balancers > Origin Pools, then Add Origin Pool. The following YAML uses a FQDN DNS name reach the app server. Using an IP address for the server is possible as well. metadata: name: buytime-pool namespace: waap-cdn labels: {} annotations: {} disable: false spec: origin_servers: - public_name: dns_name: webserver.f5-cloud-demo.com labels: {} no_tls: {} port: 80 same_as_endpoint_port: {} healthcheck: [] loadbalancer_algorithm: LB_OVERRIDE endpoint_selection: LOCAL_PREFERRED With the supporting WAF and Origin Pool resources configured, it’s time to create the HTTP Load Balancer. Navigate to Load Balancers > HTTP Load Balancers, then create a new one. Use the following YAML to create the LB and use both resources created above. metadata: name: buytime-online namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.waap.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true port: 443 tls_config: default_security: {} no_mtls: {} default_header: {} enable_path_normalize: {} non_default_loadbalancer: {} header_transformation_type: default_header_transformation: {} advertise_on_public_default_vip: {} default_route_pools: - pool: tenant: your-tenant-uid namespace: waap-cdn name: buytime-pool kind: origin_pool weight: 1 priority: 1 endpoint_subsets: {} routes: [] app_firewall: tenant: your-tenant-uid namespace: waap-cdn name: buytime-waf kind: app_firewall add_location: true no_challenge: {} user_id_client_ip: {} disable_rate_limit: {} waf_exclusion_rules: [] data_guard_rules: [] blocked_clients: [] trusted_clients: [] ddos_mitigation_rules: [] service_policies_from_namespace: {} round_robin: {} disable_trust_client_ip_headers: {} disable_ddos_detection: {} disable_malicious_user_detection: {} disable_api_discovery: {} disable_bot_defense: {} disable_api_definition: {} disable_ip_reputation: {} disable_client_side_defense: {} resource_version: "517528014" With the HTTP LB successfully deployed, check that its status is ready on the status page. You can verify the LB is working by sending a basic request using the command line tool, curl. Confirm that the value of the HTTP header “Server” is “volt-adc”. da.potter@lab ~ % curl -I https://buytime.waap.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:23:55 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 136 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049035840-557942247; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:23:55 GMT set-cookie: 1f9403=viJrSNaAp766P6p6EKZK7nyhofjXCVawnskkzsrMBUZIoNQOEUqXFkyymBAGlYPNQXOUBOOYKFfs0ne+fKAT/ozN5PM4S5hmAIiHQ7JAh48P4AP47wwPqdvC22MSsSejQ0upD9oEhkQEeTG1Iro1N9sLh+w+CtFS7WiXmmJFV9FAl3E2; path=/ x-volterra-location: wes-sea server: volt-adc Now it’s time to configure the CDN Distribution and service chain it to the WAAP HTTP LB. Navigate to Content Delivery Network > Distributions, then Add Distribution. The following YAML creates a basic CDN configuration that uses the WAAP HTTP LB above. metadata: name: buytime-cdn namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true tls_config: tls_12_plus: {} add_location: false more_option: cache_ttl_options: cache_ttl_override: 1m origin_pool: public_name: dns_name: buytime.waap.f5-cloud-demo.com use_tls: use_host_header_as_sni: {} tls_config: default_security: {} volterra_trusted_ca: {} no_mtls: {} origin_servers: - public_name: dns_name: buytime.waap.f5-cloud-demo.com follow_origin_redirect: false resource_version: "518473853" After saving the configuration, verify that the status is “Active”. You can confirm the CDN deployment status for each individual region by going to the distribution’s action button “Show Global Status”, and scrolling down to each region to see that each region’s “site_status.status” value is “DEPLOYMENT_STATUS_DEPLOYED”. Verification With the CDN Distribution successfully deployed, it’s possible to confirm with the following basic request using curl. Take note of the two HTTP headers “Server” and “x-cache-status”. The Server value will now be “volt-cdn”, and the x-cache-status will be “MISS” for the first request. da.potter@lab ~ % curl -I https://buytime.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:24:04 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 63 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049044863-471593352; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:24:04 GMT set-cookie: 1f9403=aCNN1JINHqvWPwkVT5OH3c+OIl6+Ve9Xkjx/zfWxz5AaG24IkeYqZ+y6tQqE9CiFkNk+cnU7NP0EYtgGnxV0dLzuo3yHRi3dzVLT7PEUHpYA2YSXbHY6yTijHbj/rSafchaEEnzegqngS4dBwfe56pBZt52MMWsUU9x3P4yMzeeonxcr; path=/ x-volterra-location: dal3-dal server: volt-cdn x-cache-status: MISS strict-transport-security: max-age=31536000 To see a security violation detected by the WAF in real-time, you can simulate a simple XSS exploit with the following curl: da.potter@lab ~ % curl -Gv "https://buytime.f5-cloud-demo.com?<script>('alert:XSS')</script>" * Trying x.x.x.x:443... * Connected to buytime.f5-cloud-demo.com (x.x.x.x) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=buytime.f5-cloud-demo.com * start date: Oct 14 23:51:02 2022 GMT * expire date: Jan 12 23:51:01 2023 GMT * subjectAltName: host "buytime.f5-cloud-demo.com" matched cert's "buytime.f5-cloud-demo.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multiplexing * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x14f010000) > GET /?<script>('alert:XSS')</script> HTTP/2 > Host: buytime.f5-cloud-demo.com > user-agent: curl/7.79.1 > accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 200 < date: Sat, 22 Oct 2022 01:04:39 GMT < content-type: text/html; charset=UTF-8 < content-length: 269 < cache-control: no-cache < pragma: no-cache < set-cookie: 1f945=1666400679155-452898837; Path=/; Domain=f5-cloud-demo.com; Expires=Fri, 22 Oct 2032 01:04:39 GMT < set-cookie: 1f9403=/1b+W13c7xNShbbe6zE3KKUDNPCGbxRMVhI64uZny+HFXxpkJMsCKmDWaihBD4KWm82reTlVsS8MumTYQW6ktFQqXeFvrMDFMSKdNSAbVT+IqQfSuVfVRfrtgRkvgzbDEX9TUIhp3xJV3R1jdbUuAAaj9Dhgdsven8FlCaADENYuIlBE; path=/ < x-volterra-location: dal3-dal < server: volt-cdn < x-cache-status: MISS < strict-transport-security: max-age=31536000 < <html><head><title>Request Rejected</title></head> <body>The requested URL was rejected. Please consult with your administrator.<br/><br/> Your support ID is 85281693-eb72-4891-9099-928ffe00869c<br/><br/><a href='javascript:history.back();'>[Go Back]</a></body></html> * Connection #0 to host buytime.f5-cloud-demo.com left intact Notice that the above request intentionally by-passes the CDN cache and is sent to the HTTP LB for the WAF policy to inspect. With this request rejected, you can confirm the attack by navigating to the WAAP HTTP LB Security page under the WAAP Security section within Apps & APIs. After refreshing the page, you’ll see the security violation under the “Top Attacked” panel. Demo To see all of this in action, watch my video below. This uses all of the configuration details above to make a WAAP + CDN service chain in Distributed Cloud. Additional Guides Virtually deploy this solution in our product simulator, or hands-on with step-by-step comprehensive demo guide. The demo guide includes all the steps, including those that are needed prior to deployment, so that once deployed, the solution works end-to-end without any tweaks to local DNS. The demo guide steps can also be automated with Ansible, in case you'd either like to replicate it or simply want to jump to the end and work your way back. Conclusion This shows just how simple it can be to use the Distributed Cloud CDN to frontend your web app protected by a WAF, all natively within the F5 Distributed Cloud’s regional edge POPs. The advantage of this solution should now be clear – the Distributed Cloud CDN is cloud-agnostic, flexible, agile, and you can enforce security policies anywhere, regardless of whether your web app lives on-prem, in and across clouds, or even at the edge. For more information about Distributed Cloud WAAP and Distributed Cloud CDN, visit the following resources: Product website: https://www.f5.com/cloud/products/cdn Distributed Cloud CDN & WAAP Demo Guide: https://github.com/f5devcentral/xcwaapcdnguide Video: https://youtu.be/OUD8R6j5Q8o Simulator: https://simulator.f5.com/s/waap-cdn Demo Guide: https://github.com/f5devcentral/xcwaapcdnguideEnhance your Application Security using Client-side signals
In this two-part post, I’m describing the concept of Client-side signals and how they can be used to enhance your web and mobile application security strategy. As is well known, API and application security are currently at the forefront of today's CISO agenda. These are real concerns, especially due to the accelerated digital transformation that has forced all companies to adapt and quickly build new applications to stay competitive and keep their relevance through the stormy times we have lived these past 3 years. According to the World Bank, over 40% of adults who made merchant in-store and online payments using a card, phone, or the internet did so for the first time since the start of the pandemic. This is an attestation of how much more people are consuming online applications. Delving further into the “adapt and quickly build” of new applications, what transpired was the creation of numerous new APIs, Web and Mobile applications, and an entire ecosystem facilitating deep interdependency between them. When you visit any online application today, be it Web or Mobile, it is highly likely that this application is constructed using APIs and is leveraging a broad array of 3rd-party integrations in the form of APIs or other web components. Below, you will find a simple example of a Web page calling external entities as it loads in a browser: Figure 1. Waterfall The figure above illustrates what we could characterize as an ecosystem comprising internal and external web components. These components provide the necessary services to enable the application to fulfill its intended purpose. A browser loading components of web applications isn’t something new; in fact, browsers are created to perform exactly this function; what is new is the fact that this application requires a whole set of external components that are fetched directly or indirectly by the browser, and, despite these external dependencies being transparent for the end-user, they represent a real challenge from the application security strategy point of view. At F5, we embody what I personally refer to as the “web proxy mindset”. For the past 27 years, a substantial part of our work, of course, in an oversimplified way, has to do with proxying network communications between a client and a server; thereby, proxying these communications gives us the ability to guarantee that all requirements for an application or API are met, whether related to security or connectivity. Figure 2. Typical client-server communication If you search online for the definition of a proxy server, you will find that it is defined as “a server application that acts as an intermediary between a client requesting a resource and the server providing the resource, and it improves privacy, security, and performance in the process.” The paradigm shift for protecting modern applications To fight the new generation of attackers and fraudsters, the ones that usually sell the attack as-a-Service on the dark forums, F5 has enhanced its solutions by integrating our web proxy approach with the client-side signals. We will get into deeper details later in this post, but it could be seen as having a magnified glass to closely monitor the activities within the browser as a person interacts with the application prior to having the actual request sent to the application server. Combining both techniques is a strong strategy to enhance your application security. When discussing the concept of client-side signals with CISOs and their teams, I often find that this methodology is not widely known and is largely underutilized by companies seeking to bolster their security detection capabilities. What are the Client-side signals? Client-side signals are the telemetry that can be pulled from the browser or mobile app while a person or an entity interacts with the application. These signals can typically be categorized into three main groups: a) human interaction signals, b) device environment signals, and c) network signals. Human Interaction Signals This category of signals will allow us to determine if what is using an application is a person or not and if this person is bad or good intended. But how and why is this relevant to your security strategy? Is this a person or not? When this question is raised, how confidently can you answer that? It is well-known in the application security industry that bots are a real problem. These software entities are created for several different purposes; one of them is to “mimic” a person's behavior and, by doing that, imitate the steps and behaviors a human would do while interacting with a page or app. Distinguishing if an entity visiting your application is a Human or a Bot before having your application servers process an HTTP request will automatically improve the overall user experience, as you will offload the burden of processing noise from your servers. It is important to emphasize that Bots are not typically created to overload your servers; they’re created to “mimic” humans with the intention of abusing a legit business logic your application provides and do not get caught as they do that. The examples below were extracted from a real Login application and can give a visual perspective of how Bots can “mimic” humans: Figure 3. - Bot Figure 4. - Human Is this person good or bad intended? I must admit that this is a very tricky question to answer; however, answering it at an initial stage of interaction can significantly enhance your security strategy. Determining intention is a typical methodology used by fraud prevention solutions, but having a glimpse of how a person behaves while interacting with the application and using it to either permit or deny a request is also applicable for the application security teams as it can help detect the initial stages of an attack, which usually involves reconnaissance techniques. What distinguishes a human performing an attack reconnaissance technique from a regular human using your application? There are several factors at play here, and employing AI strategies can probabilistically determine the typical behavior of well-intended users on your application by analyzing things like: How common is having users often leave the active browser tab while interacting with the application? How typical is having users press unusual keys while filling out forms? What is the average time a user spends on each step of your application? How frequently does a user change or use different devices to access the application? Is the mouse moving like an untrained human? Is this person actively submitting any data while using the application or sitting there and clicking randomly, or, maybe, apparently doing nothing? …and several others. Device Environment Signals This category of signals is based on fingerprinting techniques. Device fingerprinting isn’t something new, and there are known ways to get around fingerprinting. However, the goal here isn’t only to fingerprint a device but also to check if the collected signals are contradicting somehow, thus giving the signs that something has been spoofed to avoid real identification. Remember, we are looking for lies! Application security teams should be looking for signals like: Screen Size Fonts Plugins/Extensions CPU/GPU capabilities Graphic rendering capabilities Canvas configurations Browser configurations Time zones …and hundreds of others. Figure 5. Emoji rendering Examples of questions to help identify spoofed devices using these signals could be: Why is this browser saying it is a certain version of Firefox for MacOS, but some properties are only found on Windows OS? Why is this browser rendering a certain emoji as if it were for a different browser or OS? Why is this mobile app showing properties as if it is an emulator? Why is this session coming from a remote desktop? Why is this a Virtual Machine? …and several other questions that can lead to identifying a spoofed device and eventually trigger a security policy. Network Signals This category of signals will provide insights into where this request is coming from. Typically, security solutions rely on IP addresses to determine if a request is permitted or denied, but today, relying only on IP addresses is a very ineffective way of determining the real source of a request. Numerous companies provide VPN and forward proxy services, commonly found in the attacker's toolkit, but the real danger lives on the Botnets. Today’s Botnets are comprised of regular end-users who willingly participate in the network and compromised devices acting as internet proxies without the owner's knowledge. In such cases, relying on a Geo-blocking or IP reputation database may not flag these requests as malicious since the source IP address is often associated with a regular ADSL or LTE/5G mobile network and is not necessarily engaged in malicious activities. Additional effort is required to enhance your ability to identify the true source of a request. Collecting network-based signals, including IP addresses, HTTP headers, TLS fingerprints, and a portion of the request's payload, and combining these signals with device environment and human interaction signals can provide robust insights into the malicious or non-malicious nature of a request. It is important to note that these alone are not a solution to detect a malicious source. More advanced techniques like TCP handshake timing, TCP-related variances and others can also come into play and enhance the overall detection. Also, every browser has its own way of crafting an HTTP request, so the goal here is to detect inconsistencies in the HTTP requests and enhance anomaly detection capabilities. Now that you know some capabilities of the Client-side signals, the next questions might be: How to collect Client-side Signals? How can you guarantee the signals are not altered or faked while they are collected? Making decisions based on bad data leads to false positives and false negatives. How can you confidently say that after collecting the signals, they are sent to your backend in a protected way and are not altered while in transit? What happens when no signals are collected? What practical improvements will you get when you start using the client-side signals? What if you have a compromised 3rd-party component? How can you detect a potential supply-chain issue? These are all interesting questions, and the answers are coming in the second part of this article. Please stay tuned, and thank you for your interest and time to read this article. References: World Bank https://www.worldbank.org/en/news/press-release/2022/06/29/covid-19-drives-global-surge-in-use-of-digital-payments Proxy Server https://en.wikipedia.org/wiki/Proxy_serverMitigating OWASP 2023 API Security Top 10 Risks Using F5 NGINX App Protect
The OWASP API Security Top 10 highlights the most critical security risks facing APIs, as a global standard for understanding and mitigating vulnerabilities. Based on extensive data analysis and community contributions, the list identifies prevalent vulnerabilities specific to the unique attack surface of APIs. The 2023 edition introduces new vulnerabilities like Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Unsafe Consumption of APIs and highlights emerging threats related to modern API architectures and integrations. For detailed information, please visit: OWASP API Security Top 10 - 2023. F5 products provide essential controls to secure APIs against these specific risks. F5 NGINX App Protect delivers comprehensive API security capabilities, employing both positive and negative security models. The positive security model validates API requests against defined schemas (like Open API) and enforces strict data formats, while the negative security model uses updated signatures to detect and block known API attack patterns and OWASP API Top 10 threats, including injection flaws and improper asset management. This guide outlines how to configure and implement effective protection for your APIs based on their specific requirements and the risks identified in the OWASP API Security Top 10. Note: The OWASP risks below are successfully tested on both NGINX App Protect Version 4 and Version 5. The set up and configurations for both the Versions are different. To bring up the setup for NGINX Version 5, follow the below links: https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/install/ https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/compiler/ API2:2023 – Broken Authentication Broken Authentication is a vulnerability that refers to incorrectly implemented authentication mechanisms or session management for APIs. Attackers exploit these flaws (like weak credentials, flawed token validation, or missing checks) to impersonate legitimate users and gain unauthorized access to data or functionality. Problem Statement: Broken Authentication is a big risk to API security. It happens when problems with the API’s identity verification process let attackers get around the authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. This demonstration uses the Damn Vulnerable Web Application (DVWA) to show the exploitability of Broken Authentication. We will execute a brute-force attack against the login interface, iterating through potential credential pairs to achieve unauthorized authentication. Below is the selenium automated script to execute a brute-force attack, submitting multiple credential combinations to attempt authentication. The brute-force attack successfully compromised authentication controls by iterating through multiple credential pairs, ultimately granting access. Solution: To mitigate the above vulnerability, NGINX App Protect is deployed and configured as a reverse proxy in front of the application, and NAP first validates requests for the vulnerabilities. The NGINX App Protect Brute Force WAF policy is utilized as shown below. Re-attempt to gain access to the application using the brute-force approach is rejected and blocked. Support ID verification in the Security logs shows request is blocked because of Brute Force Policy. API3:2023 – Broken Object Property Level Authorization Broken Object Property Level Authorization is a key vulnerability listed that occurs when an API fails to properly validate if the current user has permission to access or modify specific fields (properties) within an object. This can lead to unauthorized data exposure or modification, even if the user has access to the object itself. This category combines API3: 2019 - Excessive Data Exposure and API6: 2019 - Mass Assignment. Excessive Data Exposure Problem Statement: A critical API security risk, Broken Authentication occurs when weaknesses in the API's identity verification process permit attackers to circumvent authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. Solution: To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration. dataguard_blocking WAF Policy Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches. If needed, we can update configurations to block this vulnerability, after which all incoming requests for this endpoint will be blocked. Fig: The request is blocked when block mode in blocking_settings is "true" If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section. Mass Assignment Problem Statement: API Mass Assignment vulnerability arises when clients can modify immutable internal object properties via crafted requests, bypassing API Endpoint restrictions. Attackers exploit this by sending malicious HTTP requests to escalate privileges, bypass security mechanisms, or manipulate the API Endpoint's functionality. Placing an order with quantity as 1: Bypassing API Endpoint restrictions and placing the order with quantity as -1 is also successful. Solution: To overcome this vulnerability, we will use the WAF API Security Policy in NGINX App Protect which validates all the API Security events triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked, as shown below. Restricted/updated swagger file with .json extension is added as below: api.json file is updated with minimum Product Quantity Policy used: App Protect API Security Re-attempting to place the order with quantity as -1 is getting blocked. Attempt to place order with product count as -1 Validating the support ID in Security log as below: API4:2023 – Unrestricted Resource Consumption Unrestricted Resource Consumption refers to APIs that don't adequately limit the resources (e.g., CPU, memory, network bandwidth) a client can request or utilize. This can lead to performance degradation or Denial of Service (DoS) attacks, impacting availability for all users and potentially increasing operational costs significantly. Lack of Resources and Rate-Limiting Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. The above-mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute-force attacks. Solution: NGINX App Protect provides different ways to rate-limit the requests as per user requirements. A simple rate-limiting use case configuration can block requests after reaching the limit, which is demonstrated below. API6:2023 – Unrestricted Access to Sensitive Business Flows When an API lets people perform key business actions too easily without limits, attackers can automate abuse. This might mean hoarding products, causing financial damage, or spamming, giving them an unfair advantage. Problem Statement: Within the product purchasing flow, a critical vulnerability allows an attacker to execute a rapid, large-scale acquisition. They target a high-demand product, bypassing any intended quantity limits, and effectively corner the market by buying out the complete stock in one swift operation. This leaves genuine buyers frustrated and empty-handed, while the attacker capitalizes on the artificially created scarcity by reselling the goods at a steep markup. Below is the checkout POST call for the product. Below is the Python script to generate product checkout in bulk; provided quantity as 9999. Script to generate bulk product checkout requests Solution: The above vulnerability can be prevented using NGINX App Protect Bot Defense WAF Policy, which is blocking the bulk bot-generated product checkout request using the malicious script. Requests sent to check out the product using the above selenium script are blocked successfully as shown below. Bot request for bulk order is blocked Validating the support ID in Security log as below: Request captured in NGINX App Protect security log API7:2023 – Server-Side Request Forgery A new entrant to the OWASP API Security Top 10 in 2023, Server-Side Request Forgery (SSRF) vulnerabilities occur when an API fetches a remote resource (like a URL) without properly validating the user-supplied destination. Attackers exploit this by tricking the API into sending crafted requests to the server itself, leading to information disclosure or interaction with sensitive backend services. Problem Statement: Within the product purchasing flow, a critical vulnerability allows an attacker to execute a rapid, large-scale acquisition. They target a popular product, going past any planned limits, and effectively control the market by buying all the stock in one quick move. This makes real buyers angry and empty-handed, while the attacker makes money from the fake shortage by reselling the goods at a high price. In the application below, click on ‘Contact Mechanic’ and provide required details like Mechanic name, Problem Description and send Service Request. Contact Mechanic Request Payload Below image shows that ‘contact_mechanic’ endpoint is internally making a call to ‘mechanic_api’ URL. Since ‘mechanic_api’ parameter accepts URL as data, this can be vulnerable to SSRF attacks. Exploiting the vulnerable endpoint by modifying ‘mechanic_api’ URL call to www.google.com in POST data call got accepted by returning 200 OK as response. This vulnerability can be misused to gain access to internal resources. POST Call with incorrect mechanic_api endpoint in request body Solution: To prevent this vulnerability, we will use the WAF API Security Policy in NGINX App Protect, which validates all the API request parameters and will block the suspicious requests consisting of irrelevant parameters, as shown below. Restricted/updated swagger file with .json extension is added as below: Updated the Swagger file with restricted pattern for mechanic_api endpoint Policy used: App Protect API Security API Security Policy Retrying the vulnerability with ‘mechanic_api’ URL call to www.google.com in POST data now getting blocked. mechanic_api endpoint in request body Validating the support ID in the security log below: API8:2023 – Security Misconfiguration Security problems happen when people don’t follow security best practices. This can lead to problems like open debug logs, old security patches, wrong CORS settings, and unnecessary allowed HTTP methods. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. Problem Statement: Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often reveal a range of HTTP methods (such as PUT, DELETE, PATCH) that are not required for the application's functionality. These unused methods, if not properly disabled, can provide attackers with additional attack surfaces, increasing the risk of unauthorized access or unintended actions on the server. Properly limiting and configuring allowed HTTP methods is essential for reducing the potential impact of such security vulnerabilities. Let’s dive into a demo application which has exposed “PUT” method., this method is not required as per the design and attackers can make use of this insecure, unintended method to modify the original content. modified using PUT method Solution: NGINX App Protect makes it easy to block unnecessary or risky HTTP methods by letting you customize which methods are allowed. By easily configuring a policy to block unauthorized methods, like disabling the PUT method by setting "$action": "delete", you can reduce potential security risks and strengthen your API protection with minimal effort. As shown below, the attack request is captured in security log, which conveys the request was successfully blocked because of “Illegal method” violation. API9:2023 – Improper Inventory Management Improper Asset Management in API security signifies the crucial risk stemming from an incomplete awareness and tracking of an organization’s full API landscape, including all environments like development and staging, different versions, both internal and external endpoints, and undocumented or "shadow" APIs. This lack of comprehensive inventory leads to an expanded and often unprotected attack surface, as security measures cannot be consistently applied to unknown or unmanaged assets. Consequently, attackers can exploit these overlooked endpoints, potentially find older, less secure versions or access sensitive data inadvertently exposed in non-production environments, thereby undermining overall security posture because you simply cannot protect assets you don't know exist. Problem Statement: APIs do not have any restrictions on the size or number of resources that can be requested by the end user. The above-mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute-force attacks. We’re using a flask database application with multiple API endpoints for demonstration. As part of managing API assets, the “/v1/admin/users” endpoint in the demo Flask application has been identified as obsolete. The continued exposure of the deprecated “/v1/admin/users” endpoint constitutes an Improper Asset Management vulnerability, creating an unnecessary security exposure that could be used for exploitation. <public_ip>/v1/admin/users The current endpoint for user listing is “/v2/users”. <public_ip>/v2/users with user as admin1 Solution: To mitigate the above vulnerability, we are using NGINX as an API Gateway. The API Gateway acts as a filtering gateway for API incoming traffic, controlling, securing, and routing requests before they reach the backend services. The server’s name used for the above case is “f1-api” which is listening to the public IP where our application is running. To query the “/v1/admin/users” endpoint, use the curl command as shown below. Below is the configuration for NGINX as API Gateway, in “api_gateway.conf”, where “/v1/admin/users” endpoint is deprecated. api_gateway.conf The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”. api_json_errors.conf Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response. https://f1-api/v1/admin/users is deprecated Conclusion: This article explains the OWASP 2023 Top 10 API security risks. It also shows how NGINX App Protect can be used to stop these OWASP API security risks. Related resources for more information or to get started: F5 NGINX App Protect OWASP API Security Top 10 2023Technical Impacts of Open Banking and Financial Data Exchange on Financial Systems
Determine your baseline requirements and dissect essential compliance requirements in Open Banking. Discuss with the DevCentral community to dissect gap analysis to prepare security and platform teams to build plans for safely deploying digital first financial services.Protecting APIs with Access Policy Manager and custom iRules
The problem: Unprotected API - Vulnerable to Overload Without Rate-Limiting Enforcement Our customer in the B2B sector is encountering a challenge with their public API. Despite having implemented a custom method for generating long-lived API keys, they find themselves unable to enforce rate-limiting effectively. This absence of rate-limiting mechanisms poses significant challenges, potentially resulting in the overloading of their system due to excessive requests or the exploitation of their API by unauthorized users. Without proper rate-limiting controls in place, the customer faces risks to both the performance and security of their API infrastructure, necessitating a solution to mitigate these concerns and ensure the smooth operation of their services for their clients. Our customers wants to offer two tiers of service level agreements (SLAs) - gold and standard. Complicating matters further, the API key, integral to authentication, is transmitted via a custom HTTP header. The solution: BIG-IP APM and Custom iRules for Effective Rate-Limiting My solution involves leveraging the API Protection feature of BIG-IP APM in conjunction with a custom iRule. By utilizing this combination, our customer can effectively extract the API Keys from HTTP requests and enforce rate limiting on specific API endpoints. As for now they only want to enforce rate limiting on the POST endpoints. This approach empowers the customer to secure their API while efficiently managing and controlling access to critical endpoints, ensuring optimal performance and safeguarding against abuse or overload. With this iRule we can to extract the API key from the HTTP Requests and store it in a variable, that can later be used by the API Protection feature of the APM. API Keys and the associated SLA level are stored in a Data Group of the type string. # Enable (1) or disable (0) logging globally when RULE_INIT { set static::debug 1 } # Access and analyze the HTTP header data for SLA value when HTTP_REQUEST { set sla [class lookup [HTTP::header value apikey] dg_apikeys] if { $static::debug } {log local0. "Made it to HTTP_REQUEST event with SLA value $sla."} } # Evaluate SLA value during per-request access policy execution when ACCESS_PER_REQUEST_AGENT_EVENT { set id [ACCESS::perflow get perflow.irule_agent_id] if { $id eq "read-sla" } { if { $static::debug } {log local0. "Made it to iRule agent in perrequest policy with SLA value $sla."} ACCESS::perflow set perflow.custom "$sla" } } And this is how the Per Request Policy in the API Protection profile looks. It uses the value of the API Key (extracted with the help of the the iRule) and the Source IP of the client to enforce Rate Limiting on the POST endpoints, using two different SLAs. In the APM log you should see the following message, once the client exceeds his quota defined in the SLA. Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 01870075:5: (null):/Common: API request with weight (1) violated the quota in rate limiting config(/Common/demo_api_ratelimiting_auto_rate_limiting_standard). Apr 28 20:12:42 ltm-apm-16.mylab.local notice tmm[11094]: 0187008d:5: /Common/demo_api_ratelimiting_ap:Common:6600283561834577940: Execution of per request access policy (/Common/demo_api_ratelimiting_prp) done with ending type (Reject) Further reading: You can find a more detailed write-up on my GitHub page: https://github.com/webserverdude/f5_APM_API_Protection There you can find the Per Request Policy explained in all details. The Data Group with for the iRule. A demo API for testing my solution. A Postman Collection for working with my demo API.F5 Distributed Cloud (XC) API Security in Out-of-Band Mode using BIG-IP
Introduction There are API Security use cases, which need to be deployed in out-of-band mode. An example of such use cases is an existing very high-critical API deployment, which cannot risk a new inline point. Another example is API security visibility deployment with so many deployment points, which renders new inline/proxy points becoming too expensive. F5 Distributed Cloud (XC) API Security solution by default, requires an inline deployment to be the most effective solution. It needs a different approach if out-of-band deployment is required. Out-of-band mode in this context, means that F5 XC is deployed outside of the API traffic path flow. This implies that F5 XC is in monitoring mode by receiving the API traffic from mirroring devices or API logging systems. While in monitoring mode, it cannot provide any protection or enforcement without any integration with existing security solutions; inline or F5 XC deployment is changed to be inline mode. The best deployment position for F5 XC API Security remains the inline mode. Architecture F5 XC is designed to be an inline solution. It receives the API request traffic, analyzes it, and forwards it to the backend/origin servers. Receives the API response traffic, analyzes it, and forwards it to the clients. F5 XC is not designed to handle API logs or mirrored traffic. Hence, it requires a separate component to receive the API logs or mirrored traffic and translate them into API request and response traffic, and send them to F5 XC. The architecture below uses BIG-IP as the separate component carrying out the needed functions. The above architecture takes an example of Apigee API Gateway platform, which sends an API trace in XML format containing the request and response traffic of an API call passing through it to a BIG-IP VE (Virtual Edition) deployed in AWS. The BIG-IP VE is licensed with LTM and configured with 3 virtual servers and 3 iRules to carry out the required functions. Step (1): BIG-IP VE receives the uploaded API trace in XML format via vs_log_receiver VS attached with an iRule 01_incoming_xml_to_log_converter. The iRule parses the trace, captures the API request and response traffic, create+save the simulated API response in the cache, create a unique link ID, create a simulated API request, and send the simulated API request to vs_http_to_https using Sideband iRule. Step (2): The vs_http_to_https VS receives the simulated API request traffic and forwards it as an HTTPS request to F5 Distributed Cloud (XC). F5 XC receives the simulated API request and forwards it back to the BIG-IP VE. Step (3): The BIG-IP VE receives the simulated API request from F5 XC, finds the corresponding API response from the cache using the unique link ID inside the request header, and sends the simulated API response to F5 XC. F5 XC then forwards the simulated API response to the BIG-IP VE completing the traffic flow cycle. With those steps, they mimic the situation where F5 XC receives normal API request and response traffic. The difference here is that the client and the server are the simulated one, not the real client and server. F5 XC processes the API traffic according to the API security configuration in a more passive role instead of an active role. The iRules are available at this link. Benefits The benefits of this architecture are: Deploy F5 XC API Security in out-of-band mode without disturbing/changing the existing API traffic flow, which makes the deployment faster and less intrusive. Get the API Discovery from F5 XC to discover API traffic endpoints and provide the analysis. Verify the API Authentication in each API request traffic. Conduct API Security posture management. Display the API security visibility in centralized manner without changing the API environment. Create the right justification cases for the higher-management approval to deploy the F5 XC API Security solution in inline mode. Get full support for the solution from F5 ecosystem because the solution uses standard F5 solution components. Scaling If significant capacity is required to process the mirrored API traffic, it is possible to deploy multiple BIG-IP VE instances and load-balance them using AWS Network Load Balancer. A specific iRule to synchronize the response cache entries between BIG-IP VE instances needs to be developed. I leave this scope for further details on implementation. Let me know your thoughts by leaving a comment or two below 🙂Mitigation of OWASP API Security Risk: Unrestricted Access to Sensitive Business Flows using F5 XC
We have already covered different OWASP API risks in our previous articles (check reference section for more details). OWASP continuously analysed API threats in the last few years and has identified new types of risks which are not part of API Security Top 10 - 2019 edition. So, they added these new ones in the 2nd edition of OWASP API Security Top 10 2023 list and this article will cover the nuances of the newly added risk: Unrestricted Access to Sensitive Business Flows. Introduction: API owners should be very cautious of all the API endpoint’s exposed to users and they should identify each endpoint’s business justification. When developing an API Endpoint, we shall understand API use case and its intended scope of user action. Some business flows need to be monitored, restricted or blocked depending on the sensitivity of endpoint data. If any sensitive business flow is not protected, attackers can exploit them and cause some serious damage to the business. Using wide variety of automated tools available in market, hackers can automate the manual process thereby adversely impacting the genuine business workflows. That’s all the theory I have !!. Let’s plunge into a demo application use case and discover how F5 Distributed Cloud Platform (XC) can detect and guard our API application endpoints against this vulnerability. Use case: As part of testing, I was exploring the options available in one of the demo application “F5AIR” which is used for booking some dummy flight tickets and as a promotion this application is also offering 200$ as account balance after every user signup. In the 3rd tab we observed that this balance can be used to create gift cards which can be redeemed by users. After doing thorough research we have identified there are no restrictions on this workflow and it can be exploited using automated tools. Automated tools can be used to create multiple users, generate gift cards from each user and then redeem them into a single valid account to further book flight tickets without paying anything. Because of this risk, businesses can incur losses and so this is marked as a sensitive business flow. Artificial Intelligence is a truly disruptive technology spreading like wildfire and so for the purpose of today’s demo, I am using AXIOM.AI browser extension to automate the above manual workflow steps. It just took me around 30 minutes to understand how it works and was able to automate the above exploited manual steps. After 10 user creations and redeeming their gift cards valid main user will have around 2000$ which can be used to book flight tickets. Note: To showcase how AI tools can be leveraged to exploit modern applications we are using axiom ai tool and intended only for educational purposes. Mitigation Steps: A straightforward one-point solution may not be appropriate for different types of these vulnerabilities. Secops team should dig deeper into their incoming application traffic, differentiate genuine & malicious security data and then identify the API endpoints which are sensitive to their business flows. Once they have analyzed the traffic then they can apply below solutions as per their requirements Configure API Discovery to detect different API vulnerabilities like sensitive Data, API Attributes like Login page, Zombie API, security Posture, etc. You can find more details in this article Configure rate limiting on the sensitive business end points to keep a limit on number of requests - check here for more details on rate limiting Configure API Protection rules for these business API’s to restrict access to applications – check here for more details on API rules Configure Bot Defense to prevent bot attacks – check here for more details on bot protection As an example, let’s consider the above demonstrated AI tool example, to block any bots from accessing demo application we can apply bot defense configurations in root folder location “/” as shown below after which bot AI exploit requests can be mitigated. Note: Above config is for this article’s use case, but users must understand the API endpoint’s which should be protected and apply configs appropriately. We can also try other automation tools like postman which may also be blocked as below In F5 XC console if we navigate to this load balancer security events and bot defense dashboards, we can see these requests are blocked. Conclusion: In this article we explored some insights on this newly added OWASP API Security Top 10 risk, then we shed some light on how AI tools have opened floodgates to a new approach of application threats. Finally, we also revealed the final puzzle of how F5 XC Bot defense can become our elixir in identifying and protecting against this OWASP API risk along with novel AI threats. For more information or to get started check links below: OWASP API Security Top 10 2023 OWASP API Security Top 10 - 2019 F5 Distributed Cloud WAAP
OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
The threat of broken authentication poses a significant risk to organizations, potentially leading to unauthorized access and data breaches. In the face of this formidable challenge, F5's Access Policy Manager (APM) emerges as a robust and indispensable solution. By seamlessly integrating advanced authentication mechanisms and comprehensive access controls, F5 BIG-IP APM stands as a stalwart guardian against the vulnerabilities associated with broken authentication. This article explores the pivotal role played by BIG-IP APM in fortifying authentication protocols, mitigating risks, and ensuring a resilient defense against unauthorized access, ultimately safeguarding the integrity and security of sensitive data in today's dynamic digital environment. Broken Authentication Authentication mechanism is an exposed target due to the nature of this function, as authentication is the first point of entry to any platform. The difficulty to exploit authentication weaknesses differs based on how the authentication platform is secured. In the current digital era the security perimeters are very fluid, and so are the trust boundries for our authentication platforms those require more cautions from the developers and security architects regarding authentication flows. Not only we need to protect authentication endpoints and flows, but also some overlooked items like forget and reset password endpoints. How can we consider endpoint to be vulnerable? Credential stuffing. Brute force attacks targetting users' accounts. Weak Passwords. Sensitive details in the URL (passwords, Tokens). Allow users sensitive actions without confirmation. No validation for the tokens authenticity. Accept unsigned or weak jwt tokens. No validation for jwt expiration. Use of plain-text, non-encrypted or non-hashed passwords. Use of weak encryption algorithms. Endpoint can access each other without proper authentication. Use weak or predictable tokens for intra-endpoint authentication. Broken Authentication Examples Making use of GraphQL query patching to bypass API ratelimiting and brute force user's login. POST /graphql [ {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, ... {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, ] Update / modify user's sensitive information without API authorization token. PUT /account Authorization: Bearer <token> { "newpassword": "<new_password>" } BIG-IP APM and Broken Authentication We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. The ability to create whitelist / blacklist for API Access tokens, JSON Web Tokens ID (JTI) or a different element based on the used authentication method, below example steps for JWT: Extract JTI value from Access token. Add JTI value to whether Allow/Block lists. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)
F5 powered API security and management
Editor's Note: The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here. Introduction Application Programming Interfaces (APIs) enable application delivery systems to communicate with each other. According to a survey conducted by IDC, security is the main impediment to delivery of API-based services. Research conducted by F5 Labs shows that APIs are highly susceptible to cyber-attacks. Access or injection attacks against the authentication surface of the API are launched first, followed by exploitation of excessive permissions to steal or alter data that is reachable via the API. Agile development practices, highly modular application architectures, and business pressures for rapid development contribute to security holes in both APIs exposed to the public and those used internally. API delivery programs must include the following elements : (1) Automated Publishing of APIs using Swagger files or OpenAPI files, (2) Authentication and Authorization of API calls, (3) Routing and rate limiting of API calls, (4) Security of API calls and finally (5) Metric collection and visualization of API calls. The reference architecture shown below offers a streamlined way of achieving each element of an API delivery program. F5 solution works with modern automation and orchestration tools, equipping developers with the ability to implement and verify security at strategic points within the API development pipeline. Security gets inserted into the CI/CD pipeline where it can be tested and attached to the runtime build, helping to reduce the attack surface of vulnerable APIs. Common Patterns Enterprises need to maintain and evolve their traditional APIs, while simultaneously developing new ones using modern architectures. These can be delivered with on-premises servers, from the cloud, or hybrid environments. APIs are difficult to categorize as they are used in delivering a variety of user experiences, each one potentially requiring a different set of security and compliance controls. In all of the patterns outlined below, NGINX Controller is used for API Management functions such as publishing the APIs, setting up authentication and authorization, and NGINX API Gateway forms the data path. Security controls are addressed based on the security requirements of the data and API delivery platform. 1. APIs for highly regulated business Business APIs that involve the exchange of sensitive or regulated information may require additional security controls to be in compliance with local regulations or industry mandates. Some examples are apps that deliver protected health information or sensitive financial information. Deep payload inspection at scale, and custom WAF rules become an important mechanism for protecting this type of API. F5 Advanced WAF is recommended for providing security in this scenario. 2. Multi-cloud distributed API Mobile App users who are dispersed around the world need to get a response from the API backend with low latency. This requires that the API endpoints be delivered from multiple geographies to optimize response time. F5 DNS Load Balancer Cloud Service (global server load balancing) is used to connect API clients to the endpoints closest to them. In this case, F5 Cloud Services Essential App protect is recommended to offer baseline security, and NGINX APP protect deployed closer to the API workload, should be used for granular security controls. Best practices for this pattern are described here. 3. API workload in Kubernetes F5 service mesh technology helps API delivery teams deal with the challenges of visibility and security when API endpoints are deployed in Kubernetes environment. NGINX Ingress Controller, running NGINX App Protect, offers seamless North-South connectivity for API calls. F5 Aspen Mesh is used to provide East-West visibility and mTLS-based security for workloads. The Kubernetes cluster can be on-premises or deployed in any of the major cloud provider infrastructures including Google’s GKE, Amazon’s EKS/Fargate, and Microsoft’s AKS. An example for implementing this pattern with NGINX per pod proxy is described here, and more examples are forthcoming in the API Security series. 4. API as Serverless Functions F5 cloud services Essential App Protect offering SaaS-based security or NGINX App Protect deployed in AWS Fargate can be used to inject protection in front of serverless API endpoints. Summary F5 solutions can be leveraged regardless of the architecture used to deliver APIs or infrastructure used to host them. In all patterns described above, metrics and logs are sent to one or many of the following: (1) F5 Beacon (2) SIEM of choice (3) ELK stack. Best practices for customizing API related views via any of these visibility solutions will be published in the following DevCentral series. DevOps can automate F5 products for integration into the API CI/CD pipeline. As a result, security is no longer a roadblock to delivering APIs at the speed of business. F5 solutions are future-proof, enabling development teams to confidently pivot from one architecture to another. To complement and extend the security of above solutions, organizations can leverage the power of F5 Silverline Managed Services to protect their infrastructure against volumetric, DNS, and higher-level denial of service attacks. The Shape bot protection solutions can also be coupled to detect and thwart bots, including securing mobile access with its mobile SDK.5 Technical Sessions That Should Be Great: F5 AppWorld 2025
These F5 Academy sessions explore modern app delivery, security, and operations. The full list of sessions is on the F5 AppWorld 2025 Academy page - if you haven't yet registered you can do so here: Register for F5 AppWorld 2025 LAB - F5 Distributed Cloud: Discovering & Securing APIs API security has never been more critical, and this lab dives straight into the tough stuff. Learn how to find hidden endpoints, detect sensitive data and authentication states, and apply integrated API security measures to keep your environment locked tight. TECHNICAL BRIEFING - LLM Security and Delivery with F5’s Distributed Cloud Security Ecosystem AI is fueling the next wave of applications—but it’s also introducing new security blind spots. This briefing explores how to secure LLMs and integrate the right solutions to ensure your AI-driven workloads remain fast, cost-effective, and protected. LAB - F5 NGINX Plus Ingress as an API Gateway for Kubernetes Containerized environments and microservices are here to stay, and this lab helps you navigate the complexity. Configure NGINX Plus Ingress as a powerful API gateway for your Kubernetes workloads, enabling schema enforcement, authorization, and rate-limiting all in one streamlined solution. LAB - Zero Trust at Scale With F5 NGINX Zero trust principles become a whole lot more meaningful when you can scale them. Get hands-on with NGINX Plus and BIG-IP GTM to build a robust, scalable zero trust architecture, ensuring secure and seamless app access across enterprises and multi-cluster Kubernetes environments. LAB - F5 Distributed Cloud: Security Automation & Zero Day Mitigation In this lab, you’ll learn how to leverage advanced matching criteria and custom rules to quickly respond to emerging threats. Shore up your defenses with automated policies that deliver frictionless security and agile zero-day mitigation. Session Updates Coming in January 🚨 AppWorld's Breakout Sessions officially drop in January 2025 but here is a sneak preview! Check back in January to add these to your agenda. Global App Delivery With a Global Network How Generative AI Breaks Traditional Application Security and What You Can Do About It The New Wave of Bots: A Deep Dive into Residential IP Proxy Networks From ZTNA to Universal ZTNA: Expanding Your App Security Strategy --- See you at F5 AppWorld 2025! #AppWorld25
