Protecting Your MCP Server From Secret Exposure With F5 BIG-IP Advanced WAF's Data Guard
The Threat of Token Mismanagement in MCP Servers Tokens and credentials serve as the backbone for authentication and authorization in MCP servers, yet their mishandling presents a significant security risk. Developers sometimes store these secrets insecurely, embedding them in configuration files or leaving them easily accessible. The inherent features of MCP—such as long-lived sessions, stateful agents, and persistent context—add complexity to this risk. Tokens can inadvertently be stored, retrieved, or indexed through user prompts, system recalls, or log inspections. This introduces a new vulnerability: contextual secret leakage, where the model or protocol layer unknowingly becomes a repository for sensitive information. Attackers can exploit this vulnerability to extract and misuse these exposed credentials, gaining unauthorized access production systems. Mitigating OWASP MCP01 with F5 BIG-IP Advanced WAF Data Guard Recognizing the gravity of this issue, OWASP has officially categorized Token Mismanagement and Secret Exposure in MCP servers under the MCP01 vulnerability class. This classification highlights the widespread nature of the threat and underscores the urgent need for tools like F5 BIG-IP Advanced WAF’s Data Guard. Although the long term solution is to correct token mismanagement at the backend servers, the F5 BIG-IP Advanced WAF’s Data Guard offers a quick and easy way to mitigate this vulnerability. By sanitizing server responses, Data Guard ensures that sensitive data—such as tokens—is never inadvertently exposed to unprivileged users. In the following video, we will see how token mismanagement can result in system error logs containing sensitive data. Subsequently, we demonstrate how we can utilize BIG-IP Advanced WAF Data Guard to sanitize these responses, thus mitigating OWASP MCP 01: Token Mismanagement & Secret Exposure. For more information on F5 Data Guard, click here. For a list of OWASP MCP Top 10 vulnerabilities, click here
Malware Protection with F5 Distributed Cloud Web App & API Protection
F5 Distributed Cloud WAAP comes with robust malware protection built with the precision and scope to address the unique challenges of safeguarding file uploads. Allowing users to upload files is a staple of web applications. Whether it's uploading images for insurance claims, profile photos for social networks, or text files like tax documents, file uploads play an essential role in modern digital workflows. However, this convenience comes with a hidden and significant risk: file upload endpoints can be a vector for injecting and executing malicious code. While traditional web application firewalls (WAFs) often excel at detecting code injection attacks in textual request bodies or URL parameters, they falter when it comes to binary files. Binary files represent a unique challenge—malware can be embedded in hard-to-detect formats like images, PDFs, or other file types, making traditional WAF signatures and detection models unable to detect such attacks. Compounding the problem, many organizations face significant hurdles when using WAFs to monitor file uploads. To prevent excessive false positives that disrupt legitimate user activity, development and security teams often opt to bypass WAF protection for file uploads or define overly broad exclusions for upload paths. These exclusions create blind spots in application defenses, effectively leaving upload endpoints and, by extension, the wider application ecosystem vulnerable to exploitation. F5 Distributed Cloud WAAP is available with robust malware protection that has been built with the precision and scope to address the unique challenges of safeguarding file uploads. In this demo we will show you how to enable Malware Protection on your F5 Distributed Cloud Load Balancer to detect and block malicious file uploads. For more info on configuring Malware Protection on your F5 Distributed Cloud Load Balancer, see Create HTTP Load Balancer > Configure Malware Protection.
Making WAF Monitoring Mode Powerful
In a nutshell, the current state of the F5 Distributed Cloud WAF considers several factors before making a block/allow decision. The default configuration does the following: Operates in a monitoring mode, which logs WAF hits but doesn't block matches requests against high and medium attack signature accuracy classes Automatic Attack Signature tuning automatically suppresses likely false positives Bot Signature fill drop requests from clients that match known malicious bot signatures The focus here is that the default is to match based on signature accuracy, an approach that has been leveraged for years until the introduction of the AI-enhanced WAF. This deserves its own article, but to summarize here it pivots to a risk-based enforcement model instead of a pure signature match model. This decision is based on a custom model trained by F5 to identify requests that were riskier regardless of signature accuracy which improves both the block rate while lowering false positives further. But this isn't why you came here. Stepping outside of AI functions that have reduced false positives and better blocking, let's pivot to the challenge that many security teams face in actual businesses: you get stuck with a WAF forever in monitoring mode. Many on the security side of this equation might feel that watching malicious actors walk through the wide open front door has very little utility before the fact. There is a growing stash of events that could have been blocked or maybe get analyzed downstream to enforce a blocking mechanism (perhaps a SOC engineer maintaining a deny list?) in a purely reactive fashion. What if there was a better way? This is how we recently helped a customer find the best balance: Enter Malicious User Detection/Mitigation When Malicious User Detection is enabled, instead of looking at each request in isolation like a WAF or Firewall does, we look at the behavior of a particular client over time. This includes detecting anomalous behavioral changes, failed logins, unauthorized access, and most importantly for this article, all other Distributed Cloud security engine detections including but not limited to a WAF in monitoring mode. Why does this matter? An Application Firewall looks at the requests in their own context. We can assess risk inside the context of a given request, across all accuracy classes of signatures, but that context exists constrained to the request. Malicious User Detection adds the context of the user behavior over time. For instance, we will look at things that may never trigger a WAF block but because they are anomalous in time we can change the risk level of that user; with Malicious User Mitigation we can make a subtler decision to challenge a user with proportional responses. For instance, when a user transitions from no risk to low risk behavior, we can ensure they are running a browser with a javascript challenge. When they transition from low to medium risk we can present a captcha challenge. When they transition into high risk we can temporarily block that user. We can even identify users with a wide set of criteria than simple source IP. We can use XFF source IP, TLS fingerprints, headers, JWT claims, and other things, in a cascading list, to provide those mitigations in a very targeted way at an individual level. This means that one user that sends a request that triggers a WAF violation through a monitoring policy will be allowed through while another attacker that commits multiple WAF violations (or even just anomalous requests) will have mitigation applied in a progressive manner proportional to their risk. This is more subtle and targeted than a pure WAF block. An example Malicious User log from an Apache Bench test against an application with WAF monitoring mode and MUM: Configuration: App Firewall in Monitoring mode Enable Malicious User Detection and Mitigation in the HTTP Load Balancer 3. Save the HTTP Load Balancer Summary and Conclusions Pros: Mitigation are applied per-user instead of per signature A true false positive will be allowed through for a well-behaved user because where it might otherwise be blocked with a blocking WAF policy A malicious user can be stopped with mitigations based on anomalous behavior before they ever trigger a WAF block Cons: It takes a little more time to come to a decision to mitigate because behavior is a time-dependent variable Using behavioral analysis costs more than using WAF alone Key Point: Malicious User Detection/Mitigation with a monitoring WAF policy means you shift a block decision from a request context to a user-behavioral context which dramatically narrows the scope of impact from an application-related false positive. It is a safer middle ground to start doing something with all that WAF logging when you aren't allowed to turn on a blocking policy.
Guest Role User Lost Visibility in ASM/WAF Module – LTM Working Fine
Hi community, I'm troubleshooting a strange issue on our F5 BIG-IP and hoping someone has run into this before. Environment: - Module: ASM (WAF) - User Role: Guest - Partition Access: All Partitions Problem: A user with the Guest role and access to all partitions suddenly lost the ability to view any information in the ASM module. When navigating to Security > Application Security > Policies, the table shows "No records to display" — even though policies exist and are active and viewable from other non-guest accounts. The strange part: LTM is working perfectly fine for this user. They can view virtual servers, pools, nodes, etc. without any issue. The problem is isolated to ASM only. Any pointers would be greatly appreciated. Happy to share outputs if needed. Thanks!AI-Enabled Risk Scoring Helps Reduce Risks
Risk Categories AI-enabled Risk Scoring for F5 Distributed Cloud WAF reduces key risk categories: Security, Business/availability, and Operational. Security risk (missed attacks / false negatives): F5 Distributed Cloud's AI-Powered WAF Risk Scoring improves detection by combining multiple signals per request so you don't miss attacks that traditional WAFs may not catch: High-confidence signatures Curated signature combinations (with LLM labeling to improve precision) Attack indicators (e.g., SQLi signals, libinjection, multiple signatures) A real-time ML model—to catch attacks that traditional WAFs may miss Business/availability risk (false positives blocking real users) By assigning High/Medium/Low risk outcomes using layered analysis, teams can enforce blocking with more confidence and keep false positives low, reducing accidental customer impact such as blocking legitimate users. Staged workflows are enabled, such as: Block High Review Medium (implicitly allow Low while continuing to observe) Operational risk (slow time-to-protection and heavy tuning burden) F5 Distributed Cloud's AI-Powered WAF Risk Scoring reduces manual exceptions and case-by-case policy tuning, enabling teams to deploy the WAF in blocking mode sooner, with less ongoing friction across SecOps, dev, and platform teams. Outcome-based scoring enables: Improved consistency of enforcement across distributed apps/APIs Standardization of protection by reducing bespoke tuning per app How the system makes a risk decision Risk level is computed from layering multiple complementary analyses: High Risk or High Accuracy Signature matches Heuristics – such as injection attacks, multiple attack signatures detected, predictable resource exploitation, other risk indicators Neural network - Signatures can sometimes lead to false positives. To address that, a neural network acts as a secondary classifier to determine whether attack fragments flagged by signatures signal an attack, improving accuracy while maintaining real-time performance. Key system scope The ML model analyzes behavioral patterns to refine risk assessment, ensuring accurate classification and enabling effective threat prioritization. Calling the ML model will adhere to the following scope: The ML model is called only if at least one enabled (not excluded/disabled) signature triggers in these categories: Server-Side Code Injection, SQL Injection, XSS, Command Execution, Path Traversal, LDAP Injection, XPath Injection The model analyzes only HTTP request fragments that trigger signatures (not full raw requests). If signatures are excluded or disabled, they are not considered for invoking the model. Model output: 1 = malicious → request risk level set to High 0 = benign → request risk level set to False Positive A primer on Signature Accuracy vs Signature Risk Accuracy Indicates the ability of the attack signature to identify the attack including susceptibility to false-positive alarms: Low: Indicates a high likelihood of false positives. Medium: Indicates some likelihood of false positives. High: Indicates a low likelihood of false positives. Risk Indicates the level of potential damage this attack might cause if it is successful: Low: Indicates the attack does not cause direct damage or reveal highly sensitive data. Medium: Indicates the attack may reveal sensitive data or cause moderate damage. High: Indicates the attack may cause a full system compromise. Does AI-enabled Risk Scoring add latency? AI-enabled Risk Scoring works in line with F5 Distributed Cloud WAF, inspecting real-time traffic without adding noticeable latency in our tests.Implementing Risk-Based Actions with AI-Powered WAF: Customer Policy Paths
Why Custom policy is where risk-based actions matter most The default policy is straightforward: it applies a broad mix of signatures, threat campaigns, and violations; “Enhance with AI” is an optional add-on. Custom policies are where customers can accidentally recreate the same problems Risk Scoring is designed to solve—usually by combining: Overly broad/noisy signature selection (especially low-accuracy signatures) Aggressive enforcement (blocking Medium too early) Disabling/excluding key signatures and unintentionally reducing ML invocation So the rest of this blog is a tight, configuration-oriented walkthrough of the Custom path. Custom policy: configuration walkthrough (decision points → operational outcomes) Baseline: Navigate to the Custom controls LB Config → Web Application Firewall Create/edit the WAF object (Metadata `Name`, etc.) Set Security Policy = Custom Choose Signature Selection by Accuracy Optionally enable Enhance with AI (Risk Scoring) If enabled, optionally configure Action by Risk Score (risk-based enforcement) Step 1: Signature Selection by Accuracy (choose your baseline level) Accuracy indicates susceptibility to false positives: Low: high likelihood of false positives Medium: some likelihood of false positives High: low likelihood of false positives Note: This setting is foundational: it determines which signatures are active, and therefore the quality and volume of detection signals that feed into downstream risk evaluation. Operationally: High accuracy tends to support faster, safer enforcement. Medium/Low accuracy can expand coverage but increases the chance you’ll need exceptions, investigations, or staged rollout discipline. Step 2: Enhance with AI (turn on Risk Scoring) Enhance with AI = On enables AI-powered risk scoring and assigns each request a High/Medium/Low risk score using layered signals. Two implementation details to make explicit in your blog because they affect customer expectations: ML invocation depends on enabled signatures firing in the specified injection/execution categories. If teams disable/exclude those signatures, they may reduce when the model runs—changing practical behavior of risk evaluation. Step 3: Action by Risk Score (map risk levels to enforcement) When Action by Risk Score is enabled: By default, high-risk requests are blocked Users can choose whether Medium-risk requests are blocked (via dropdown) This is the primary knob that determines how quickly a user decides to move from “safe enforcement” to “broad enforcement.” Recommended rollout path: Day 0 → Day 7 → Steady state This is the most common and safest operational progression for customers Day 0 (safe enforcement baseline) Custom → Signature Selection by Accuracy = High (or High + Medium if you need broader coverage immediately) Enhance with AI = On Action by Risk Score = High Outcome Gets to blocking quickly while minimizing availability risk. High is blocked. This is the “prove safety while stopping obvious bad” posture. Day 7 (controlled expansion) Keep Custom + Enhance with AI + Action by Risk Score Optionally widen Signature Selection from High → High + Medium if coverage is insufficient Enhance with AI = On Action by Risk Score = High + Medium Outcome Expands detection inputs without immediately expanding enforcement. Teams focus on what’s landing in Medium and whether exclusions/disabled signatures are reducing ML invocation in key categories Steady state (mature enforcement) Custom → signature selection set to the broadest set Widen Signature Selection from High + Medium → High + Medium + Low Action by Risk Score = High + Medium Enhance with AI = On Action by Risk Score = High + Medium Outcome Risk outcomes become the enforcement interface. Broad, consistent blocking across apps/APIs with reduced per-app tuning and fewer signature-level decisions Common Pitfalls: Avoid Block Medium on Day 0 when including low-accuracy signatures—this is the fastest way to recreate false-positive outages. If you disable/exclude signatures in the key injection/execution categories, you can reduce ML invocation and change risk evaluation behavior. Summary Custom policies traditionally scale poorly because every app ends up with bespoke signature decisions and exception handling. Risk Scoring is designed to invert that: keep signatures as key signals but standardize enforcement via risk outcomes. If you implement Custom with the Day 0 → Day 7 → Steady state progression above, you get a predictable path from “block safely now” to “enforce broadly later” without returning to signature-by-signature tuning as your primary operating model.
Cloud Apps Protection
Hello Everyone, I hope you're well, I realize a deploy A F5 Big-IP. I have two doubts: Can the Big-IP on-premise solution protect external web applications hosted on AWS and Azure? Can the WAF module in Big-IP on-premise protect mobile applications (APP Mobile)? Would it be possible in scenarios On-Premise , or I need to opt for a Distributed Cloud or Hybrid solution?
F5 bot defense - false positives
I'm hoping someone can offer some advice. We have a Bot defense service (ex Volterra I think?) running on our WAF, and we're getting a lot of false positives, far greater than what we'd initially expected or what I've seen estimated online. It's an angular application with a .NET back end. There's a range of services, mostly internal that are also running. At the moment, we're only covering a small range of endpoints as a test, but the results have not been great and at some point in the use of the application, almost every customer is being flagged as a bot while tracking through the user experience. I have read elsewhere that we might need to force the application to load the interstitial JavaScript file. It's currently marked as synchronous, then it loads a couple of other JS files asynchronous, these seem to be called from the first js file. The tag is first in line after the HEAD html tag. I am currently concerned that loading order could be the cause? But might only account for the false positives at the startup/entry point of the application. There's nothing else particularly special happening with the application, it's a publicly accessible Angular web app with a range of backend services, some called internally, some called directly through an API. As it is at the moment, I'm not exactly sure how we can trust the results and what the point even is if the false positives are so much higher than expected. I realise this is a complicated problem to get 100% right, but I'd expected a lot more for what I believe is a significant annual cost. Can anyone please confirm if this is a common concern or if it is expected and normal? or if there is something we're missing here? Any pointers for what we can do at the application level to resolve this? Thanks a lot. Dudley.
Need step-by-step guidance for migrating BIG-IP i2800 WAF to rSeries (UCS restore vs clean build)
Hello DevCentral Community, We are planning a hardware refresh migration from a legacy BIG-IP i2800 running WAF/ASM to a new rSeries platform and would like to follow F5 recommended best practices. Could you please advise on the step-by-step process for this migration, specifically around: o Whether UCS restore is recommended versus building config fresh o BIG-IP version compatibility considerations during the migration o Interface/VLAN mapping differences between iSeries and rSeries hardware o Best approach to migrate WAF/ASM policies and tuning after migration o Common issues or lessons learned during real-world cutovers Current environment: " BIG-IP model: i2800 " BIG-IP version: 17.1.3 " WAF module: ASM / Advanced WAF " Deployment: Active/Active Thank you .
