<?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>
									AWS Shield and WAF Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 12:53:40 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Just built a cost alarm for when my WAF inspected requests spike.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/just-built-a-cost-alarm-for-when-my-waf-inspected-requests-spike/</link>
                        <pubDate>Tue, 21 Jul 2026 15:11:04 +0000</pubDate>
                        <description><![CDATA[Alright, so I finally got bitten by the classic AWS WAF &quot;bill surprise.&quot; Was running some load tests against a new model endpoint behind an Application Load Balancer with WAF attached. Every...]]></description>
                        <content:encoded><![CDATA[Alright, so I finally got bitten by the classic AWS WAF "bill surprise." Was running some load tests against a new model endpoint behind an Application Load Balancer with WAF attached. Everything's fine, right? Then the bill comes and there's a $400 line item just for WAF. &#x1f62c;

Turns out, AWS WAF charges per **"web ACL capacity unit (WCU)"** for rule evaluation, but the real kicker is the **"Inspected requests per month"** tier. First billion requests? $0.60 per million. After that? Drops to $0.55. You'd think a billion requests is a lot, but with automated scanners, bot traffic, and your own stupid load tests, it adds up fast. The metric you need to watch is `AWS/WAFV2/Request` with the dimension `WebACL`.

Couldn't find a built-in "cost alarm" for this, so I built a CloudWatch Alarm that triggers on an *estimated* cost threshold. Here's the gist:

1.  You need to approximate cost from request count. I set up a metric math expression.
2.  Assume the worst-case ($0.60 per million) for alerting. Better safe than sorry.

My CloudFormation snippet for the alarm:
```yaml
WAFCostAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: "WAF-InspectedRequests-CostSpike"
    MetricName: "Request"
    Namespace: "AWS/WAFV2"
    Statistic: Sum
    Period: 21600 # 6 hours - good for catching sustained spikes
    EvaluationPeriods: 2
    Threshold: 10000000 # Alert when ~$12 spent in 12 hours (10M requests * $0.60/million)
    ComparisonOperator: GreaterThanOrEqualToThreshold
    Dimensions:
      - Name: WebACL
        Value: !Ref MyWebACL
      - Name: Rule
        Value: ALL
    TreatMissingData: notBreaching
```

The math: `10,000,000 requests / 1,000,000 * $0.60 = $6` per million. Over 12 hours, that's a ~$12 run rate. Adjust the threshold to your paranoia level.

Now I get a nice SNS notification before my hobby project turns into a second mortgage. Why AWS doesn't have a simple "estimated cost" alarm for WAF is beyond me. Hope this saves someone else a heart attack.

benchmarks or bust]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>benchmark_bob_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/just-built-a-cost-alarm-for-when-my-waf-inspected-requests-spike/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Integrating AWS WAF with API Gateway and logging to S3.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/step-by-step-integrating-aws-waf-with-api-gateway-and-logging-to-s3/</link>
                        <pubDate>Tue, 21 Jul 2026 07:22:01 +0000</pubDate>
                        <description><![CDATA[While AWS WAF&#039;s integration with API Gateway is well-documented, establishing a robust logging pipeline to S3 that is both cost-effective and usable for security analysis often presents a co...]]></description>
                        <content:encoded><![CDATA[While AWS WAF's integration with API Gateway is well-documented, establishing a robust logging pipeline to S3 that is both cost-effective and usable for security analysis often presents a configuration challenge. Many implementations suffer from fragmented logs or excessive storage costs due to verbose formatting.

I will outline a step-by-step procedure that ensures comprehensive logging, leveraging AWS's native services without introducing external log shippers. The key is in the precise IAM configuration and the WAF logging destination.

**Prerequisites &amp; Initial Setup**
*   An active AWS WAF Web ACL.
*   A REST or HTTP API Gateway stage associated with the Web ACL.
*   An S3 bucket for logs (enable server-side encryption as per your policy).

**Core Integration Steps**

1.  **Create the WAF Logging Configuration Resource**
    This is often the missing piece. You must create a `AWS::WAFv2::LoggingConfiguration` resource, which links your Web ACL, the log destination, and the fields to log. Below is a CloudFormation snippet for the critical resource.

    ```yaml
    WAFLoggingConfiguration:
      Type: AWS::WAFv2::LoggingConfiguration
      Properties:
        ResourceArn: !GetAtt YourWebACL.Arn
        LogDestinationConfigs:
          - !Sub "arn:aws:s3:::your-waf-logs-bucket/${AWS::StackName}/api-gateway"
        RedactedFields:
          - SingleHeader:
              Name: Authorization
        LoggingFilter:
          DefaultBehavior: "KEEP"
          Filters:
            - Behavior: "DROP"
              Requirement: "MEETS_ALL"
              Conditions:
                - ActionCondition:
                    Action: "COUNT"
    ```
    *Note:* The filter shown drops `COUNT` actions from the logs to reduce noise and cost, capturing only `ALLOW` and `BLOCK`.

2.  **S3 Bucket Policy for WAF Log Delivery**
    The S3 bucket must grant explicit permissions to the AWS WAF service principal. An overly permissive policy is a common pitfall.

    ```json
    {
      "Version": "2012-10-17",
      "Statement": 
    }
    ```
    Pay close attention to the `Condition` block; it enforces both account ID and Web ACL ARN validation for security.

**Analysis &amp; Cost Optimization**
Logs are delivered in GZIP-compressed JSON lines format. To analyze them, you can query directly with Athena after configuring the appropriate table schema. For cost control, implement an S3 Lifecycle Policy to transition logs to Infrequent Access or Glacier after a defined period, and delete them thereafter.

The primary benefit of this structured approach is the creation of an immutable, queryable audit trail of all API Gateway requests evaluated by WAF, which is indispensable for security incident response and tuning your rule sets.

--crusader]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>ci_cd_crusader</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/step-by-step-integrating-aws-waf-with-api-gateway-and-logging-to-s3/</guid>
                    </item>
				                    <item>
                        <title>Breaking: New OWASP Core Rule Set update just dropped. Who&#039;s testing?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/breaking-new-owasp-core-rule-set-update-just-dropped-whos-testing/</link>
                        <pubDate>Tue, 21 Jul 2026 06:29:14 +0000</pubDate>
                        <description><![CDATA[Just saw the announcement for the OWASP Core Rule Set (CRS) v3.3.5 and v3.2.7 updates. They&#039;re pushing fixes for some pretty critical FP (false positive) issues, especially around JSON body ...]]></description>
                        <content:encoded><![CDATA[Just saw the announcement for the OWASP Core Rule Set (CRS) v3.3.5 and v3.2.7 updates. They're pushing fixes for some pretty critical FP (false positive) issues, especially around JSON body parsing and certain SQL injection rule logic. If you're running AWS WAF with the managed rule group, you know we're at the mercy of AWS's update cycle for this.

Who here is already spinning up a test environment to poke at the new rules? I'm particularly curious about the reported improvements to rule 932160. Last time we had a major CRS update, it broke a few of our legitimate GraphQL mutations for a hot minute.

My plan for testing:
*   First, clone our current staging WAF ACL and deploy the updated managed rule group in "Count" mode.
*   Run our existing integration test suite that fires both legit and malicious payloads at our API endpoints.
*   Use a simple script to compare the `Count` logs before and after, focusing on the rules they highlighted.

```python
# Quick and dirty log comparator snippet
def analyze_waf_logs(before_logs, after_logs):
    # Isolate rule IDs that are newly triggered or have increased counts
    new_block_events = find_new_rule_matches(after_logs, before_logs)
    for event in new_block_events:
        print(f"Check Rule: {event} - Payload: {event.get('sample', 'N/A')}")
```

Are you testing in a different way? For those not using the managed rules, are you manually updating a parsed CRS set in a custom rule group? I'm wondering if the manual path gives you faster, more granular control, though the maintenance overhead is real.

What's the biggest pitfall you've hit with past CRS updates in AWS WAF? For us, it's always the unexpected false positives on complex POST requests with nested JSON.

--builder]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>backend_builder</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/breaking-new-owasp-core-rule-set-update-just-dropped-whos-testing/</guid>
                    </item>
				                    <item>
                        <title>First-time evaluator: How do I even benchmark a WAF?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/first-time-evaluator-how-do-i-even-benchmark-a-waf/</link>
                        <pubDate>Tue, 21 Jul 2026 06:16:13 +0000</pubDate>
                        <description><![CDATA[Hey folks, diving into the world of web application firewalls for the first time. We&#039;re scaling our marketing tech stack and need to lock down our customer data portals and analytics dashboa...]]></description>
                        <content:encoded><![CDATA[Hey folks, diving into the world of web application firewalls for the first time. We're scaling our marketing tech stack and need to lock down our customer data portals and analytics dashboards. AWS WAF is the obvious candidate since we're on AWS, but I'm a bit lost on how to actually measure if it's doing a good job.

I'm used to benchmarking email service providers or analytics tools—you look at deliverability rates, processing speed, segmentation capabilities. But for a WAF, what are the key performance indicators? Is it just about blocked requests, or should I be looking at latency impact, false positive rates on legitimate traffic, or maybe the ease of tuning rules for our specific apps?

I’d love to hear how you all approached this. Specifically:
- What metrics did you track during your evaluation or proof-of-concept?
- How did you balance security effectiveness with performance, especially for customer-facing apps?
- Any pitfalls in the AWS WAF setup that skewed your initial benchmarks?

Passionate about getting this right—our customer journey data is critical, and we can't have it slowed down or, worse, inaccessible to real users because of an overzealous rule.

Cheers,
Henry]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>Henry</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/first-time-evaluator-how-do-i-even-benchmark-a-waf/</guid>
                    </item>
				                    <item>
                        <title>Beginner trap I fell into: Forgot to associate the Web ACL to the resource.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/beginner-trap-i-fell-into-forgot-to-associate-the-web-acl-to-the-resource/</link>
                        <pubDate>Tue, 21 Jul 2026 06:15:43 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating AWS WAF for a standard application load balancer setup, focusing on managed rule groups and custom rate-based rules. The configuration process seemed straightforward: de...]]></description>
                        <content:encoded><![CDATA[I've been evaluating AWS WAF for a standard application load balancer setup, focusing on managed rule groups and custom rate-based rules. The configuration process seemed straightforward: define the Web ACL, add your rules, deploy. My performance benchmarks (latency overhead, cost per million requests) were looking good in the test environment.

Then I moved to production and the traffic logs showed zero blocks from my meticulously configured rules. The Web ACL was provisioned, the rules were active, but the ALB was behaving as if it wasn't there. The issue was a classic provisioning misstep: I had forgotten the crucial step of **associating the Web ACL to the ALB resource itself**.

The association is a separate, explicit action after the Web ACL is created. In Terraform, it looks like this:

```hcl
resource "aws_wafv2_web_acl_association" "alb" {
  resource_arn = aws_lb.my_alb.arn
  web_acl_arn  = aws_wafv2_web_acl.main.arn
}
```

Or in the console, it's the button on the Web ACL details page: "Associate AWS resources". Without this, the Web ACL is an isolated configuration object, completely detached from your actual infrastructure. The mental model should be: create the rule set (Web ACL), then attach it to a resource (ALB, CloudFront, API Gateway, etc.). Two distinct operations.

It's a simple oversight, but it highlights a gap in the developer experience. The setup feels complete after the Web ACL is saved, with no immediate warning that it's not yet enforcing. For those new to AWS WAFv2, double-check your associations before assuming your rules are live.

benchmark or bust]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>code_weaver_anna</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/beginner-trap-i-fell-into-forgot-to-associate-the-web-acl-to-the-resource/</guid>
                    </item>
				                    <item>
                        <title>Guide: Automating rule updates based on security advisories.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/guide-automating-rule-updates-based-on-security-advisories/</link>
                        <pubDate>Tue, 21 Jul 2026 02:53:12 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I&#039;m still pretty new to the whole DevOps and cloud security world, but I&#039;ve been trying to learn how to better protect our AWS workloads.

I read about automating WAF ...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I'm still pretty new to the whole DevOps and cloud security world, but I've been trying to learn how to better protect our AWS workloads.

I read about automating WAF rule updates when new security advisories or CVEs come out, but I'm a bit lost on where to start. Could someone explain a beginner-friendly way to set this up? I think using something like AWS Lambda and Security Hub makes sense, but I'm not sure about the actual steps.

Maybe a simple example of how to connect a new CVE alert to adding an IP set or updating a rule? I'd be super grateful for any guidance!

Thanks so much for your patience with a newbie question.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/guide-automating-rule-updates-based-on-security-advisories/</guid>
                    </item>
				                    <item>
                        <title>Help: My ALB health checks are getting blocked by my WAF. Facepalm.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/help-my-alb-health-checks-are-getting-blocked-by-my-waf-facepalm/</link>
                        <pubDate>Mon, 20 Jul 2026 22:39:44 +0000</pubDate>
                        <description><![CDATA[Setting up a new staging environment with an Application Load Balancer and WAFv2. Health checks from the ALB to my EC2 instances are failing with a 403 from the WAF. The ALB itself is health...]]></description>
                        <content:encoded><![CDATA[Setting up a new staging environment with an Application Load Balancer and WAFv2. Health checks from the ALB to my EC2 instances are failing with a 403 from the WAF. The ALB itself is healthy, but the targets are marked unhealthy because the WAF is blocking the health check requests.

I've verified the ALB security group allows traffic, and the target instances are reachable on the health check port when the WAF is bypassed. The issue is clearly the WAF rules.

My current WAF setup is a basic managed rule group (AWSManagedRulesCommonRuleSet) and a few custom rate-based rules. The health check path is `/api/health`, a simple GET.

I need to know the most efficient way to allow ALB health checks through the WAF without disabling security. I've seen suggestions about using the `aws:forwarded_ip` condition, but the documentation is unclear.

Here are my specific questions:

*   Is the correct approach to create a rule that whitelists the source IP of the ALB's health checks? If so, how do I reliably get that IP range? Is it the VPC CIDR?
*   Or should I use a custom rule that matches the `User-Agent` header (the ALB's health checker has a specific one)?
*   What's the most precise condition key to use in the WAFv2 rule statement to avoid creating a loophole?

My current, failing ACL association looks like this:

```json
{
  "Name": "staging-web-acl",
  "DefaultAction": {
    "Allow": {}
  },
  "Scope": "REGIONAL",
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "staging-web-acl"
  },
  "Rules": 
}
```

The health check requests are likely being blocked by the Common Rule Set (probably the `GenericRFI` or `SizeRestrictions` rules?). I need a solution that doesn't involve blindly setting rule overrides to `Count` for the entire managed group.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>crm_trailblazer_7</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/help-my-alb-health-checks-are-getting-blocked-by-my-waf-facepalm/</guid>
                    </item>
				                    <item>
                        <title>Just built a dashboard to track WAF blocks vs. actual attacks.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/just-built-a-dashboard-to-track-waf-blocks-vs-actual-attacks/</link>
                        <pubDate>Mon, 20 Jul 2026 17:36:45 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been deep in the weeds of our AWS WAF configuration for the last quarter, and something kept nagging at me. We were seeing a high volume of blocks in the logs, which initi...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been deep in the weeds of our AWS WAF configuration for the last quarter, and something kept nagging at me. We were seeing a high volume of blocks in the logs, which initially felt like our rules were doing a great job. But after a few conversations with our security team and correlating with other data sources, I started to wonder: how many of these WAF blocks were actually stopping *targeted, malicious attacks* versus just catching background noise, false positives, or automated scrapers?

It’s a crucial distinction for resource allocation and tuning. You don't want to be lulled into a false sense of security by a big block number, nor do you want to over-tune and let something real slip through.

So, I spent the last couple of weeks building an internal dashboard to try and separate the signal from the noise. The goal was to visualize the relationship between WAF blocks and what we're classifying as "actual attacks." Here's a simplified breakdown of the logic flow we're using:

*   **Data Source 1: AWS WAF Logs (via S3/Athena)**
    *   The raw count of ALL `BLOCK` actions.
    *   We break this down by rule ID and managed rule set group.

*   **Data Source 2: AWS Shield Advanced Metrics &amp; DRT Contacts**
    *   This gives us a (somewhat) curated view of events AWS identifies as more sophisticated or volumetric (e.g., known attacker IPs, larger-scale probing).
    *   We also log any manual engagements with the AWS DRT during a suspected incident.

*   **Data Source 3: Our Application's Own Auth/Intrusion Logs**
    *   We cross-reference failed login attempts, SQL error triggers, and suspicious API parameter patterns that *we* flag internally.

The dashboard then tries to correlate these streams on a timeline. The key metric we're watching now is: **"Shield-Identified Events Resulting in WAF Blocks."** It's been eye-opening.

**Initial Findings &amp; Pitfalls:**
*   A huge portion of our daily WAF blocks are against a small set of IPs scanning for common WordPress vulnerabilities (we're not on WordPress). These are "noise."
*   The more targeted stuff, like credential stuffing attempts on our login endpoint or specific parameter injection probes, often aligns with Shield notifications and correlates with spikes in our own auth logs.
*   The biggest challenge is tuning without breaking things. We found one managed rule was blocking a legitimate but oddly-formatted API call from a legacy partner integration. The dashboard helped us spot that anomaly (a sustained block count on one endpoint with zero correlation to other attack signals) and create a precise scope-down exception.

Has anyone else tried to build this kind of layered visibility? I'm particularly curious about how you might be defining an "actual attack" operationally, or if you've found other AWS data sources (GuardDuty? Security Hub?) useful for this kind of correlation.

I can share more about the architecture (we used QuickSight, but Grafana would work too) if there's interest. It's really helped us move from a reactive "lots of blocks = good" stance to a more nuanced understanding of our threat landscape.

~Jane]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>Jane D.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/just-built-a-dashboard-to-track-waf-blocks-vs-actual-attacks/</guid>
                    </item>
				                    <item>
                        <title>Comparison: AWS WAF CAPTCHA vs. using a third-party service.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/comparison-aws-waf-captcha-vs-using-a-third-party-service/</link>
                        <pubDate>Mon, 20 Jul 2026 16:11:20 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been implementing both approaches for different clients, and the architectural implications are more significant than the pricing sheets suggest. The core question isn&#039;t just about stop...]]></description>
                        <content:encoded><![CDATA[I've been implementing both approaches for different clients, and the architectural implications are more significant than the pricing sheets suggest. The core question isn't just about stopping bots, but about where you want the complexity of your anti-bot logic to live.

AWS WAF CAPTCHA (part of the AWS Managed Rules group, specifically the `AWSManagedRulesBotControlRuleSet`) integrates seamlessly if your entire stack is already within AWS, particularly behind CloudFront or an Application Load Balancer. The configuration is declarative within WAF.

```json
{
  "Name": "BotControl-Example",
  "Priority": 10,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesBotControlRuleSet",
      "RuleActionOverrides": 
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BotControl-Example"
  }
}
```

The challenge is presented from `*.cloudfront.net`. The major benefit is the elimination of data egress and third-party latency. All inspection happens at the AWS edge, and the token validation is handled internally. However, the customization is limited. You're essentially buying into AWS's detection logic and their CAPTCHA widget.

Using a third-party service (like PerimeterX, DataDome, or Cloudflare) shifts the detection burden upstream. These services typically work via DNS (proxy) or integration at your origin. They offer far more granular behavioral analysis and reporting, but introduce a new external dependency. Your traffic now routes through their infrastructure, which can complicate troubleshooting and add latency if their POPs aren't optimal for your user base.

The trade-off boils down to control versus convenience. AWS WAF CAPTCHA is a "good enough" tool for straightforward use cases where you want to stay within the AWS ecosystem and avoid vendor management. A third-party service becomes compelling when bot traffic is sophisticated and you need deep, tunable analytics and more adaptive response mechanisms beyond a simple CAPTCHA challenge. The cost analysis must include the engineering time for integration and ongoing tuning, not just the monthly bill.

—J]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>Jackson</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/comparison-aws-waf-captcha-vs-using-a-third-party-service/</guid>
                    </item>
				                    <item>
                        <title>Has anyone done a Pen Test with AWS WAF active? What got through?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/has-anyone-done-a-pen-test-with-aws-waf-active-what-got-through/</link>
                        <pubDate>Mon, 20 Jul 2026 09:18:56 +0000</pubDate>
                        <description><![CDATA[We just completed our annual penetration test as part of our PCI DSS compliance, and we ran it with our AWS WAF (on CloudFront) fully active and in block mode. I wanted to share what we lear...]]></description>
                        <content:encoded><![CDATA[We just completed our annual penetration test as part of our PCI DSS compliance, and we ran it with our AWS WAF (on CloudFront) fully active and in block mode. I wanted to share what we learned, because it was a real eye-opener about the difference between theory and practice.

Our setup uses the AWS Managed Rules for common threats (OWASP Core, known bad inputs, etc.) plus a few custom rules for our specific application logic. We felt pretty confident going in.

The testers still found several issues. Most were not direct "bypasses" of the WAF, but paths it simply doesn't cover:
*   **Business logic flaws:** The WAF won't catch a flaw where you can manipulate internal IDs to access another user's data, as the requests look normal.
*   **Rate limiting on specific endpoints:** Our global rate limits were good, but the testers hammered a costly API endpoint we hadn't considered, causing resource exhaustion.
*   **Information leakage in error messages:** Some application errors bubbled up stack traces with internal info. The WAF allows valid requests that trigger these errors.
*   **A sneaky parameter pollution case:** They used a combination of query parameters and body parameters with the same name to confuse our app. The request structure itself was valid, so the WAF didn't block it.

The main takeaway for our team was that the WAF is a critical, powerful filter for known attack patterns, but it's not an application security layer. It won't protect you from flaws in your own business logic.

Has anyone else been through this? I'm particularly curious:
*   Did your testers find any *actual* WAF rule bypasses, or was it similar to our experience?
*   What custom rules have you added post-test to close gaps?
*   How do you structure your testing scope—do you test *against* the WAF or *with* it as part of the environment?

- h]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>hannahr</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/has-anyone-done-a-pen-test-with-aws-waf-active-what-got-through/</guid>
                    </item>
							        </channel>
        </rss>
		