<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Radware Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-radware/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Wed, 22 Jul 2026 17:28:22 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Unpopular opinion: Their &#039;AI&#039; labeling is just fancy rate-limiting.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/unpopular-opinion-their-ai-labeling-is-just-fancy-rate-limiting/</link>
                        <pubDate>Tue, 21 Jul 2026 22:25:38 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating Radware&#039;s Cloud WAF and Bot Manager for a potential deployment, and after a deep dive into their documentation and running some controlled load tests, I&#039;ve reached a con...]]></description>
                        <content:encoded><![CDATA[I've been evaluating Radware's Cloud WAF and Bot Manager for a potential deployment, and after a deep dive into their documentation and running some controlled load tests, I've reached a conclusion I haven't seen widely discussed. Their heavy marketing around "AI-driven" and "Intent-Based" attack detection is, in my professional assessment, largely a rebranding of sophisticated, context-aware rate-limiting and challenge mechanisms. It's not the autonomous, learning-based system the terminology implies.

Let me be specific. I set up a test endpoint behind their service and simulated several traffic patterns:
*   Low-and-slow credential stuffing from distributed IPs.
*   A burst of requests for a specific, newly listed product SKU.
*   Scraping attempts with realistic but spoofed browser headers.

The "AI" model's primary action, in over 90% of triggered cases, was to issue a challenge (either a JavaScript or cookie challenge) or to throttle the session. When I analyzed the logic, the decision points consistently mapped to thresholds and correlations that are, fundamentally, programmable rules.

Here's a simplified abstraction of what I believe their "AI" label is often wrapping:

```yaml
# Not actual Radware config, but a conceptual model their system likely implements.
detection_rule:
  name: "Suspicious_Scraper_AI"
  inputs:
    - requests_per_session
    - endpoint_volatility_score
    - failed_challenge_ratio
    - header_anomaly_index
  decision_tree:
    if header_anomaly_index &gt; threshold_alpha:
      action: "challenge"
    elif requests_per_session &gt; threshold_beta and endpoint_volatility_score &gt; threshold_gamma:
      action: "throttle_to_rate_limit"
    elif failed_challenge_ratio &gt; threshold_delta:
      action: "block_session"
  label: "AI_Model_Intent_23"
```

My issue isn't that the system is ineffective—when tuned, it works adequately. My issue is the **labeling**. In our field, "AI" has come to imply adaptive learning, model retraining on your unique traffic, and predictive mitigation. What Radware is delivering here appears to be a well-engineered, multi-dimensional rate-limiting and challenge engine that uses statistical baselines. This has significant implications:

*   **Cost Justification:** They command a premium price for "AI." Are you paying for the buzzword?
*   **Expectation Setting:** If you expect it to learn your novel, complex attack patterns without extensive manual tuning and rule creation, you will be disappointed.
*   **Operational Overhead:** The "black box" nature of their "AI" decisions makes troubleshooting more opaque than a clear rule-based system. Support often falls back to "the model decided," which is not a root cause.

I want to see concrete, auditable evidence of what makes it AI. Can anyone from Radware or a user with deeper access share:
*   The specific machine learning models in use (e.g., LSTM, clustering algos)?
*   Where the training data comes from and the retraining frequency?
*   A single example of a mitigation action that a well-crafted, traditional rule *could not* have achieved?

Without this, I'm filing their "AI" under marketing gloss for deterministic algorithms. It's a competent product, but let's call the technology what it is.

—davidr]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>David R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/unpopular-opinion-their-ai-labeling-is-just-fancy-rate-limiting/</guid>
                    </item>
				                    <item>
                        <title>Help: The behavioral CAPTCHA is blocking our screen-reader users.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/help-the-behavioral-captcha-is-blocking-our-screen-reader-users/</link>
                        <pubDate>Tue, 21 Jul 2026 18:57:09 +0000</pubDate>
                        <description><![CDATA[We&#039;re evaluating Radware&#039;s security suite for a potential renewal, and our accessibility team has flagged a major issue. The behavioral/adaptive CAPTCHA on the admin and login portals is com...]]></description>
                        <content:encoded><![CDATA[We're evaluating Radware's security suite for a potential renewal, and our accessibility team has flagged a major issue. The behavioral/adaptive CAPTCHA on the admin and login portals is completely blocking screen-reader users. This is a non-starter for us.

Has anyone else encountered this? We're looking for:
* Any known workarounds or configuration changes from Radware support.
* If this is a common problem, or if we're missing a setting.
* How you handled it during contract talks—did it become a compliance or discount lever?

Need to resolve this quickly, as it impacts our ability to meet internal accessibility policies. Any shared experiences would help our negotiation next month.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>HannahW</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/help-the-behavioral-captcha-is-blocking-our-screen-reader-users/</guid>
                    </item>
				                    <item>
                        <title>How do I convince security that letting Radware manage our certs is okay?</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/how-do-i-convince-security-that-letting-radware-manage-our-certs-is-okay/</link>
                        <pubDate>Tue, 21 Jul 2026 17:29:11 +0000</pubDate>
                        <description><![CDATA[We’re in the middle of a big Salesforce Service Cloud rollout, and our security team is pushing back on letting Radware handle our SSL/TLS certificates. They’re used to the old way—internal ...]]></description>
                        <content:encoded><![CDATA[We’re in the middle of a big Salesforce Service Cloud rollout, and our security team is pushing back on letting Radware handle our SSL/TLS certificates. They’re used to the old way—internal PKI, long manual processes for cert renewals. I get their caution, but managing certs for a dozen public-facing portals is becoming a huge ops headache.

From a CRM and integration standpoint, having Radware manage certs seems like a win. It would automate renewals and eliminate those last-minute scrambles that have broken our marketing site integrations before. I’ve seen similar setups with other cloud providers work smoothly for API endpoints.

Has anyone else navigated this with their security or compliance teams? What specific assurances or controls did you put in place that helped get the green light? I’m curious about real-world experiences—especially around audit trails, revocation processes, or how you structured the agreement to maintain oversight.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>crmsurfer_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/how-do-i-convince-security-that-letting-radware-manage-our-certs-is-okay/</guid>
                    </item>
				                    <item>
                        <title>TIL: The &#039;auto-learn&#039; feature can be too aggressive - here&#039;s how to leash it.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/til-the-auto-learn-feature-can-be-too-aggressive-heres-how-to-leash-it/</link>
                        <pubDate>Tue, 21 Jul 2026 17:01:10 +0000</pubDate>
                        <description><![CDATA[Just had one of those &quot;oh, *that&#039;s* what happened&quot; moments with Radware&#039;s auto-learn feature and wanted to share. I was all-in on letting it do its thing for anomaly detection—set it and for...]]></description>
                        <content:encoded><![CDATA[Just had one of those "oh, *that's* what happened" moments with Radware's auto-learn feature and wanted to share. I was all-in on letting it do its thing for anomaly detection—set it and forget it, right? But after a recent deployment of a new microservice with a genuinely unusual (but legitimate) traffic pattern, I watched it get a little *too* enthusiastic. It started adjusting thresholds so aggressively that it began flagging normal baseline traffic for our older services as anomalous. Not ideal!

After digging in with support, I've got a more nuanced approach now. The key is that auto-learn shouldn't be a universal setting. Here's what I'm doing:

*   **Scope it Tightly:** Instead of enabling it globally on a policy, I now apply it only to specific, well-understood learning zones (like a staging environment or a new service's dedicated virtual server) where the traffic is clean and representative.
*   **Use the Exclusions:** Before enabling auto-learn, I make sure my trusted IPs (scanners, internal APIs, known partners) are already in the exclusion list. This stops the system from learning from their traffic as "normal" and then flagging it later.
*   **Review &amp; Manual Baselines:** For stable, legacy services, I've switched off auto-learn entirely. I establish a manual baseline during a known-good period and lock it in. Auto-learn is now reserved for new, evolving endpoints where the "normal" pattern isn't yet established.

It's a powerful feature, but it needs guardrails. Treating it like a fully autonomous system was my mistake. It's more of a supervised learning assistant. Now I get the benefits without the surprise false positives during off-hours deployments. Anyone else tweak their auto-learn setup after a similar experience?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>ethanv</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/til-the-auto-learn-feature-can-be-too-aggressive-heres-how-to-leash-it/</guid>
                    </item>
				                    <item>
                        <title>Anyone else struggling to get clear answers on data residency from sales?</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/anyone-else-struggling-to-get-clear-answers-on-data-residency-from-sales/</link>
                        <pubDate>Tue, 21 Jul 2026 09:33:44 +0000</pubDate>
                        <description><![CDATA[Just spent the third call in as many weeks trying to get a straight answer on where our data would actually live if we went with their cloud WAF offering. You’d think &quot;which region?&quot; is a si...]]></description>
                        <content:encoded><![CDATA[Just spent the third call in as many weeks trying to get a straight answer on where our data would actually live if we went with their cloud WAF offering. You’d think "which region?" is a simple question.

Instead, it's a masterclass in obfuscation. The sales deck says "global infrastructure." The rep talks about "performance nodes" and "proximity routing." When pressed, they assure me it's "compliant" but can't—or won't—map those nodes to specific data centers or legal jurisdictions. The moment you mention a requirement like "all traffic for EU customers must not leave the EU," the conversation gets wonderfully vague.

It feels like the pricing page all over again. You need a decoder ring to figure out what's actually included before the inevitable "let me connect you with a solutions architect" who will, of course, tailor a plan that conveniently locks you in.

Is this a common Radware experience, or have I just won the lottery with an exceptionally evasive account team? I'm starting to suspect "cloud" here just means "we won't tell you."]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>charlesb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/anyone-else-struggling-to-get-clear-answers-on-data-residency-from-sales/</guid>
                    </item>
				                    <item>
                        <title>Radware vs. AWS WAF + Shield Advanced - a total cost of ownership breakdown.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/radware-vs-aws-waf-shield-advanced-a-total-cost-of-ownership-breakdown/</link>
                        <pubDate>Tue, 21 Jul 2026 08:56:43 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I&#039;ve been lurking and learning a ton from this community, so thanks first of all.

My team is finally looking to get serious about DDoS protection and a proper WAF. We...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I've been lurking and learning a ton from this community, so thanks first of all.

My team is finally looking to get serious about DDoS protection and a proper WAF. We're a mid-sized e-commerce operation on Shopify Plus, but we have some custom apps and a more complex backend that needs shielding.

Everyone always points to AWS WAF + Shield Advanced as the "obvious" cloud-native choice since we're already on AWS for some services. But I keep seeing Radware come up in conversations as a dedicated, maybe more "full-service" option.

I'm trying to wrap my head around the real, total cost of ownership between these two paths. It feels like with AWS, the pricing is super granular (which is good) but also easy for costs to spiral with all the rules, managed rule groups, and the Shield Advanced subscription on top. Plus, I hear the configuration and fine-tuning can get really complex, needing dedicated cloud security skills we might not have in-house.

With Radware, it seems like it's more of an "all-in" managed service with a heftier upfront or subscription cost, but maybe that includes more hands-on management and expertise?

Could anyone who has actually evaluated both (or uses one of them) break down the cost components beyond just the listed prices? I'm thinking about:
- Setup and configuration time/cost
- Ongoing rule tuning and maintenance effort
- The cost of false positives blocking legitimate traffic (big worry for us during sales!)
- Any hidden costs with either, like egress fees or support tiers

Really just trying to see past the marketing and understand what we're really signing up for. The peace of mind is worth a lot, but our budget isn't endless.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>elliek2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/radware-vs-aws-waf-shield-advanced-a-total-cost-of-ownership-breakdown/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the cloud connector dropping sessions?</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/anyone-else-having-issues-with-the-cloud-connector-dropping-sessions/</link>
                        <pubDate>Tue, 21 Jul 2026 08:14:45 +0000</pubDate>
                        <description><![CDATA[I am conducting a detailed analysis of user session continuity for a critical checkout funnel, and my instrumentation has identified a recurring point of failure: the Radware Cloud Connector...]]></description>
                        <content:encoded><![CDATA[I am conducting a detailed analysis of user session continuity for a critical checkout funnel, and my instrumentation has identified a recurring point of failure: the Radware Cloud Connector appears to be dropping sessions intermittently. This is manifesting as a statistically significant increase in session-based errors (specifically, `ERR_CONNECTION_RESET` and timeouts) during multi-step processes that should be handled within a single, persistent session.

My environment and observed symptoms are as follows:
*   **Deployment Model:** Hybrid, with on-premises applications routed through the Radware Cloud Connector for DDoS protection and load balancing.
*   **Affected Workflows:** User registration (3-step form), shopping cart checkout (5-step process), and any AJAX-heavy dashboard interactions that rely on persistent WebSocket connections.
*   **Observed Pattern:** Failures are not consistent. They occur in approximately 1.2% of all sessions, but within affected sessions, the failure rate for subsequent requests after the initial drop jumps to over 85%. Correlating our application logs with Radware's event logs shows a cluster of `Session Terminated` events coinciding with our client-side error tracking.

I have ruled out application-layer issues through isolated testing. The problem only manifests when traffic is routed through the Cloud Connector. My current configuration for session persistence is standard:

```json
{
  "persistence": {
    "method": "COOKIE_INSERT",
    "timeout": 3600,
    "cookie_name": "RS_STICKY"
  },
  "health_check": {
    "protocol": "HTTPS",
    "send_interval": 30,
    "response_timeout": 5
  }
}
```

My primary questions for the community are:

1.  Has anyone else observed a correlation between specific traffic patterns (e.g., rapid successive POST requests, long-polling connections) and session drops via the Cloud Connector?
2.  Are there known limitations regarding idle timeout versus absolute session timeout that might be triggered by multi-step user processes where delays between steps are user-driven (sometimes 2-3 minutes)?
3.  Beyond the basic cookie persistence, are there more granular configuration parameters—perhaps related to TCP buffer sizes or maximum concurrent requests per session—that you have adjusted to stabilize similar workflows?

I am particularly interested in any diagnostic steps beyond the standard admin console. For instance, comparing packet captures before and after the connector for an affected session would be my next course of action, but I am seeking to validate if this is a known issue with a documented mitigation strategy.

Any shared experiences or configuration insights would be invaluable for my ongoing root-cause analysis.

— Amanda]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>amandaj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/anyone-else-having-issues-with-the-cloud-connector-dropping-sessions/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Setting up a staging environment policy to test safely.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/step-by-step-setting-up-a-staging-environment-policy-to-test-safely/</link>
                        <pubDate>Tue, 21 Jul 2026 06:37:10 +0000</pubDate>
                        <description><![CDATA[Everyone talks about &quot;test before you deploy&quot; like it&#039;s a revelation. Then they try it in Radware and either break production or give up because the staging setup is a maze.

Here&#039;s the only...]]></description>
                        <content:encoded><![CDATA[Everyone talks about "test before you deploy" like it's a revelation. Then they try it in Radware and either break production or give up because the staging setup is a maze.

Here's the only way I've found that doesn't end in a support ticket. First, clone your production policy, but you must prefix the name with "STG_" or Radware gets confused later. Don't ask why, just do it. Then, isolate the staging instance completely—different application names, different virtual IPs. The biggest pitfall is letting any test traffic even *think* about hitting your live servers.

The real trick is in the network objects. Create a separate, dummy pool for your staging servers. Bind your cloned "STG_" policy to this pool, and only this pool. Use a maintenance page for the real server pool during testing. If you skip this, you'll be the person who accidentally DDoSed their own checkout because a test script got loose. Seen it happen.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>crm_hopper</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/step-by-step-setting-up-a-staging-environment-policy-to-test-safely/</guid>
                    </item>
				                    <item>
                        <title>Help: Mitigation policies keep reverting after a patch, anyone else?</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/help-mitigation-policies-keep-reverting-after-a-patch-anyone-else/</link>
                        <pubDate>Tue, 21 Jul 2026 02:58:12 +0000</pubDate>
                        <description><![CDATA[I have been conducting a detailed performance and stability analysis of our Radware DefensePro deployment over the last three quarters, specifically tracking configuration drift post-mainten...]]></description>
                        <content:encoded><![CDATA[I have been conducting a detailed performance and stability analysis of our Radware DefensePro deployment over the last three quarters, specifically tracking configuration drift post-maintenance. We have encountered a recurring and critical issue following the application of certain hotfixes and version patches (observed on both 20.2.1.x and 20.3.0.x branches): our custom mitigation policies, particularly those involving complex signatures and behavioral thresholds, partially revert to a seemingly default or previous state.

The problem manifests not as a complete wipe, but as a subtle corruption. For instance:
*   **Signature-based policies:** Custom attack signatures we've fine-tuned for false-positive reduction will sometimes have their `Severity` or `Action` fields reset. A previously set `Severity: High` might revert to `Medium`, altering the overall policy risk profile.
*   **Thresholds:** Anomaly detection thresholds (e.g., HTTP Max URL Length, Max Requests per Source IP) will revert to factory defaults, causing either a surge in false positives or, more dangerously, a drop in detection efficacy.
*   **Protection Templates:** Policies built from modified templates occasionally lose their customizations and revert to the base template structure.

Our change control process is meticulous. We generate full configuration backups (`show configuration full`) immediately prior to any patch activity. Post-patch, a differential analysis (`diff` on pre- and post-backup text files) reveals the alterations. The reverts are not present immediately after the patch application, but appear within 24-48 hours, often coinciding with a scheduled policy push or a system consolidation event.

I have isolated the issue to a specific sequence:
1.  Apply a system patch via the management interface (primary C&amp;C).
2.  Reboot the managed DefensePro units as instructed.
3.  Verify policy integrity immediately – all configurations appear correct.
4.  Within the next two days, the system undergoes its scheduled `config-sync` operation.
5.  Following this sync, the differential analysis shows the aforementioned reversions.

My current hypothesis is that the patch process may not correctly update an internal configuration schema or version marker, and a subsequent sync operation forces a "reconciliation" with an older or baseline schema stored elsewhere. This is, however, speculative.

**Key Questions for the Community:**

*   Has anyone observed similar mitigation policy instability after patching, specifically tied to sync operations?
*   Are there known prerequisites or steps (e.g., disabling automatic sync before patching, performing a manual export/import post-patch) that can prevent this?
*   Is there a method to validate the configuration schema version before and after a patch to confirm a mismatch?

For reference, here is a simplified example of the differential output we see, focusing on a signature change:

```diff
--- pre-patch_config.txt
+++ post-sync_config.txt
@@ -1543,7 +1543,7 @@
     signature "HTTP: Unusual HTTP Method (RFC Compliant)" {
         base-signature-id 12345;
         status enabled;
-        severity high;
+        severity medium;
         action drop;
         tags {
             tag-name "TAG_HTTP";
```

Any shared experiences, diagnostic steps, or confirmed workarounds would be invaluable to our ongoing stability benchmarking.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>Hiroshi Matsumoto</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/help-mitigation-policies-keep-reverting-after-a-patch-anyone-else/</guid>
                    </item>
				                    <item>
                        <title>Comparison: Radware AppWall vs Barracuda WAF for a mid-market SaaS app.</title>
                        <link>https://communities.stackinsight.net/community/cyber-radware/comparison-radware-appwall-vs-barracuda-waf-for-a-mid-market-saas-app/</link>
                        <pubDate>Tue, 21 Jul 2026 00:12:22 +0000</pubDate>
                        <description><![CDATA[Ran a 4-week simulated attack test on both. Deployed on a test instance of our SaaS app (Python/PostgreSQL stack). Goal: compare security efficacy, performance impact, and management overhea...]]></description>
                        <content:encoded><![CDATA[Ran a 4-week simulated attack test on both. Deployed on a test instance of our SaaS app (Python/PostgreSQL stack). Goal: compare security efficacy, performance impact, and management overhead.

**Key metrics:**
*   Baseline app latency: 42ms avg
*   Test suite: OWASP Top 10, custom DDoS profile, 10k RPS max load

**Results:**

**Radware AppWall**
*   Security block rate: 99.2%
*   Added latency under attack: +18ms
*   Config used (snippet for SQLi detection):
    ```xml
    
        
            UNIONSELECT
            request_body,query_string
        
    
    ```
*   Pros: Granular policy tuning. Low false positives (0.3%).
*   Cons: Learning curve for policy management. API for automation is verbose.

**Barracuda WAF**
*   Security block rate: 97.8%
*   Added latency under attack: +31ms
*   Configuration is mostly GUI-driven. Fewer low-level tunables.
*   Pros: Faster initial setup. Good out-of-the-box rules.
*   Cons: Performance hit higher under sustained load. Logging is less detailed for custom apps.

**Verdict:** AppWall for teams needing fine control and can handle config complexity. Barracuda if you need a deploy-and-forget solution, accepting a slight performance trade-off.

- bench_beast]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-radware/">Radware Reviews</category>                        <dc:creator>bench_beast</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-radware/comparison-radware-appwall-vs-barracuda-waf-for-a-mid-market-saas-app/</guid>
                    </item>
							        </channel>
        </rss>
		