Generated banner for Waf
Generated logo for Waf

Waf

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Security
  • Apache-2.0
  • No issues found

From the author

Configures AWS WAF to filter web traffic: creating web access control lists (web ACLs) on CloudFront, Application Load Balancers, API Gateway, and AppSync; AWS Managed Rules tuned in Count mode; rate-based rules for HTTP floods; IP set and geographic match rules; Bot Control (Common and Targeted); turning bot labels into a confidence signal; stripping spoofed inbound x-amzn-waf-* headers; recovering the real client IP behind a CDN; Fraud Control (account takeover and account creation fraud prevention); and logging and request sampling. Use when the user wants to protect a web application or API from common exploits, bots, credential stuffing, fake-account creation, or HTTP floods at the application layer (layer 7). Routes to the right per-task procedure in references. Do NOT use for L3/L4 DDoS protection (shieldadvanced skill), multi-account WAF rollout (firewallmanager skill), CloudFront configuration (cloudfront skill), or Route 53 health checks or records (route53 skill).
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill acts as a central router for configuring AWS WAF to secure web applications and APIs. It provides structured procedures for creating web ACLs, managing rule sets, implementing bot and fraud control, and configuring logging. The skill emphasizes a secure-by-design approach, requiring logging to be enabled before tuning and enforcing strict header-stripping to prevent spoofing. It covers the full lifecycle of WAF management, from initial setup and association with resources like CloudFront and ALB to advanced mitigation strategies for volumetric abuse and credential stuffing.

What it does

  • Creates and associates web ACLs with CloudFront, ALB, API Gateway, and AppSync.
  • Configures AWS Managed Rules, rate-based rules, and custom IP or geographic match rules.
  • Implements Bot Control and Fraud Control to prevent account takeover and fake-account creation.
  • Provides workflows for logging, request sampling, and tuning rules in Count mode.
  • Enforces security best practices like header stripping and least-privilege IAM.
  • Routes users to specific, self-contained procedures for complex WAF tasks.

When to use it

  • When you need to protect a web application or API from layer 7 exploits and HTTP floods.
  • When implementing bot detection or fraud prevention for login and signup endpoints.
  • When you need to tune managed rules to reduce false positives without blocking legitimate traffic.
  • When you need to recover the real client IP or secure forwarded headers behind a CDN.
  • When you need to manage AI and LLM crawler traffic.

Advantages

  • Reduces risk of misconfiguration by enforcing a logical, step-by-step tuning workflow.
  • Prevents accidental blocking of legitimate traffic through mandatory Count-mode tuning.
  • Ensures security consistency by mandating header-stripping when forwarding signals.
  • Provides clear guidance on WCU budget management and rule group selection.
  • Centralizes complex WAF procedures into a single, reliable reference source.

Usage examples

“How do I set up AWS WAF to block HTTP floods on my Application Load Balancer?”
The agent will guide you through creating a regional web ACL, associating it with your ALB, and configuring a rate-based rule to throttle requests based on IP or session token.
“I am seeing false positives from the Core Rule Set. How do I fix this?”
The agent will instruct you to check your WAF logs to identify the specific rule ID triggering the block, then use the RuleActionOverrides feature to set that specific rule to Count mode.
“How can I protect my login page from credential stuffing?”
The agent will guide you through enabling Fraud Control (Account Takeover Prevention) and configuring the necessary logging and signal-forwarding rules.
“I need to allow traffic only from specific countries. What is the procedure?”
The agent will provide the steps to create a geographic match rule and configure the web ACL's default action to block traffic outside of your allowed list.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/waf/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip waf.zip -d .agents/skills

Documentation by AWS

AWS WAF

Overview

Domain expertise for configuring AWS WAF, the web application firewall that filters HTTP and HTTPS traffic to CloudFront distributions, Application Load Balancers, API Gateway REST APIs, and AppSync GraphQL APIs. Covers web ACL creation and association, AWS Managed Rules, rate-based rules, match rules (IP set and geographic), Bot Control and the signal-forwarding workflows built on top of it, Fraud Control for logins and signups, AI and LLM crawler management, and the logging that every tuning workflow depends on.

This skill is a router. Each customer task maps to a procedure file under references/. Read the matching reference in full before acting, then follow its constraints and steps. The reference files are self-contained: each carries its own decision tables, constraints, procedure, and troubleshooting.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise. A web ACL's scope is fixed at creation: a CloudFront web ACL must be created in us-east-1 with CLOUDFRONT scope, while a regional web ACL (Application Load Balancer, API Gateway, AppSync) is created in the resource's Region with REGIONAL scope.

Which WAF task do you need?

GoalReference
Create a web ACL and attach it to a resourcecreating a web ACL and associating it with a resource
Set up logging and sampling before tuning anythingsetting up logging and request sampling
Add AWS Managed Rules and tune false positivesadding managed rules and tuning with count mode
Throttle HTTP floods and brute forceadding rate-based rules
Allow or block by IP range or countryusing ip sets and geographic match rules
Detect and control bots (the on-ramp)protecting against bots with bot control
Collapse bot labels into one confidence signalturning bot control labels into a confidence signal
Forward all signals to the origin with one ruleforwarding signals with dynamic label interpolation
Decide what the app does with the forwarded signaladaptive mitigation playbook for forwarded signals
Stop attackers from spoofing forwarded headersstripping inbound waf headers before trusting them
Recover the real client IP behind a CDNrecovering the real client ip behind a cdn
Protect logins and signups from fraudprotecting logins and signups with fraud control
See and manage AI and LLM crawler trafficseeing and managing ai crawler traffic

Routing notes

  • Logging comes before tuning. Every Count-mode tuning workflow assumes logging and request sampling are on. If the customer has not set up logging, run that reference first; otherwise Count-mode tuning has nothing to read.

  • Web ACL scope is fixed at creation. A CloudFront web ACL is CLOUDFRONT scope in us-east-1; a regional resource needs a REGIONAL web ACL in its own Region. Scope cannot be changed later, so the creating reference settles it before anything is built.

  • Bot Control is a chain, not one task. Protecting against bots is the on-ramp (turn on, choose Common vs Targeted, observe). Turning labels into a confidence signal, forwarding that signal, and deciding what the application does with it are three separate references that build on it in that order. The header-stripping reference is the mandatory safety companion whenever a signal is forwarded to the origin.

  • Common vs Targeted is not a soft choice. Common only catches self-identifying bots and known-bad IPs. For login, checkout, or any high-value endpoint facing evasive bots, Targeted with the application integration SDK is required. The bots reference pushes Targeted for real bot threats rather than presenting it as optional.

  • Rate limiting vs Fraud Control. Rate-based rules blunt volumetric HTTP floods. Credential stuffing and fake-account creation are account-based abuse that rate limiting misses; those go to the Fraud Control reference (ATP and ACFP), not the rate-based reference.

  • Forwarded headers need the strip rule. Any time the customer forwards a signal or the client IP to the origin in x-amzn-waf-* headers, the inbound-header-stripping reference is required to prevent spoofing. The confidence-signal, interpolation, and client-IP references all point at it.

  • What lives in other skills. L3/L4 DDoS protection and Shield cost-protection credits are the shieldadvanced skill. Multi-account WAF rollout is the firewallmanager skill. CloudFront and Application Load Balancer configuration are their own skills. This skill builds the WAF rules; it does not configure the resources it protects.

Security Considerations

AWS WAF is itself a security control, so misconfiguration directly weakens an application's defenses. Apply these across every reference:

  • Least-privilege IAM. You MUST grant only the specific wafv2: actions a task needs (for example wafv2:CreateWebACL, wafv2:GetWebACL, wafv2:UpdateWebACL, wafv2:AssociateWebACL, wafv2:PutLoggingConfiguration) rather than wafv2:* or the AWSWAFFullAccess managed policy.

  • Ephemeral credentials. You MUST use IAM roles with temporary credentials (such as an EC2 instance profile, SSO session, or aws sts assume-role) rather than long-lived IAM user access keys when running these WAF CLI commands.

  • Monitor configuration changes. You SHOULD enable AWS CloudTrail on wafv2 management events and set CloudWatch alarms on critical web ACL configuration changes (such as DeleteWebACL and UpdateWebACL rule removals) and on the web ACL's BlockedRequests and CountedRequests metrics, so rule changes and sudden spikes in blocked or counted traffic are detected.

  • Misconfiguration opens access. A web ACL that is created but never associated, or one whose default action is left at Allow with no enforcing rules, filters nothing. You MUST confirm the web ACL is associated and that its posture matches the intended default (block vs allow) before reporting setup complete.

  • Protect log destinations. Logs can capture credentials and session data. You MUST redact sensitive fields (such as the authorization header and cookie) and MUST enable encryption at rest on the log destination (CloudWatch Logs, Amazon S3, or Amazon Data Firehose).

  • Header-spoofing risk. Any x-amzn-waf-* signal forwarded to the origin can be forged inbound. You MUST add the inbound-header-stripping rule whenever a signal or client IP is forwarded (see stripping-inbound-waf-headers-before-trusting-them).

Additional Resources

Files

references/turning-bot-control-labels-into-a-confidence-signal.md

Turning Bot Control Labels into a Confidence Signal

Overview

Domain expertise for collapsing the many Bot Control Targeted labels into a single application-facing confidence signal. Covers overriding the Targeted rules to the non-terminating Challenge action, mapping many TGT_* labels into one x-amzn-waf-bot-confidence header with label-match rules, defining the mapping in the web ACL so the application contract stays fixed, and the mandatory inbound-header-stripping companion.

Does not cover turning Bot Control on (that is the protecting-against-bots reference), forwarding a whole namespace with interpolation (its own reference), or the application's response (the adaptive mitigation reference).

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise.

Table of Contents

  • Overview

  • Workflow

  • Override Targeted rules to Challenge

  • Collapse labels into one confidence header

  • Define the mapping in the web ACL

  • Strip inbound headers

  • Troubleshooting

  • Procedure

  • Security Considerations

  • Additional Resources

Workflow

To turn Bot Control labels into a confidence signal end to end, follow the procedure exactly. See the Procedure section below.

The procedure covers:

  • Overriding the Targeted rules to Challenge so evaluation continues

  • Mapping label groups to low, medium, and high with OR label-match rules

  • Forwarding one x-amzn-waf-bot-confidence header to the origin

  • Adding the inbound-header-stripping rule

Override Targeted rules to Challenge

Block or CAPTCHA terminate evaluation, so later rules that forward the signal never run. Challenge is non-terminating with a valid token.

Constraints:

  • You MUST override the Targeted rules to Challenge when the goal is to forward a signal rather than block at the edge, so AWS WAF keeps evaluating later rules

  • You MUST NOT use a terminating action (Block, CAPTCHA) on the rules whose labels feed the signal

Collapse labels into one confidence header

Targeted produces hundreds of TGT_* labels. The application cannot act on all of them, so map groups of labels to a small set of confidence levels.

Constraints:

  • You MUST collapse the labels into a single confidence signal (low, medium, high) using OR label-match rules, rather than exposing raw labels to the application

  • You MUST place the label-match rules at a higher priority number than the Bot Control group, so the labels exist when the matches run

Define the mapping in the web ACL

If the application keys on specific label names, it has to change whenever AWS adds or renames a label. Defining the mapping in the web ACL keeps the application contract fixed.

Constraints:

  • You MUST define the label-to-confidence mapping inside the web ACL and forward one stable header (x-amzn-waf-bot-confidence), so the application contract does not change as labels evolve

Strip inbound headers

The confidence header is an x-amzn-waf-* header, which an attacker can set inbound unless it is stripped first.

Constraints:

  • You MUST pair this workflow with the inbound-header-stripping rule (see stripping-inbound-waf-headers-before-trusting-them), placed before the forwarding rules, so the signal cannot be forged

  • You MUST forward x-amzn-waf-bot-confidence only to an HTTPS-only origin and SHOULD have the application set HSTS, so the confidence signal is not exposed in cleartext. You SHOULD use AWS Certificate Manager (ACM) to provision and manage the origin's TLS certificate (for example on an Application Load Balancer), so the certificate is validated and automatically renewed

Troubleshooting

The forwarding rule never runs

A terminating action on an earlier rule stopped evaluation. Override the Targeted rules to Challenge (Override Targeted rules to Challenge).

The label-match rules do not see the labels

They are at a lower priority number than the Bot Control group. Move them after it (Collapse labels into one confidence header).

The application receives a spoofed confidence value

No inbound stripping rule is in place. Add it before the forwarding rules (Strip inbound headers).

Procedure

Overview

This procedure overrides the Targeted rules to Challenge, maps labels to a confidence header, strips spoofed inbound headers, and surfaces the console link.

Parameters
  • web_acl_name, web_acl_id, scope (required): Identify the web ACL.

  • confidence_mapping (required): Which label groups map to low, medium, and high.

Constraints for parameter acquisition:

  • You MUST ask for all required parameters upfront in a single prompt

  • You MUST confirm Bot Control Targeted is already enabled (see the protecting-against-bots reference)

Steps
1. Verify dependencies

Constraints:

  • You MUST confirm credentials with aws sts get-caller-identity

  • You MUST confirm Bot Control Targeted is enabled and producing labels

2. Override Targeted rules to Challenge

Constraints:

  • You MUST override the Targeted rules to Challenge so evaluation continues to the forwarding rules

  • You MUST fetch the current LockToken before update-web-acl and pass the full rule set

  • You MUST preserve the web ACL's existing DefaultAction from the get-web-acl response and pass it back as {default_action}; do not assume Allow={}, since that would silently open all unmatched traffic on a web ACL whose default action is Block. For example, the Bot Control group with RuleActionOverrides setting Targeted rules to Challenge:

    aws wafv2 get-web-acl --name {web_acl_name} --scope {scope} --id {web_acl_id} --region {region}
    aws wafv2 update-web-acl --name {web_acl_name} --scope {scope} --id {web_acl_id} \
      --lock-token {lock_token} --default-action {default_action} \
      --rules '[{"Name":"AWS-BotControl","Priority":1,"Statement":{"ManagedRuleGroupStatement":{"VendorName":"AWS","Name":"AWSManagedRulesBotControlRuleSet","ManagedRuleGroupConfigs":[{"AWSManagedRulesBotControlRuleSet":{"InspectionLevel":"TARGETED"}}],"RuleActionOverrides":[{"Name":"TGT_VolumetricSession","ActionToUse":{"Challenge":{}}}]}},"OverrideAction":{"None":{}},"VisibilityConfig":{"SampledRequestsEnabled":true,"CloudWatchMetricsEnabled":true,"MetricName":"AWS-BotControl"}}]' \
      --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName={web_acl_name} \
      --region {region}
3. Map labels to a confidence header

Constraints:

  • You MUST add OR label-match rules that map label groups to low, medium, and high, at a higher priority number than the Bot Control group

  • You MUST forward one x-amzn-waf-bot-confidence header via custom request handling. For example, a Count rule that matches a label group and inserts the header (insert this rule with a fresh LockToken alongside the rest of the rule set):

    --rules '[{"Name":"ConfidenceHigh","Priority":10,"Action":{"Count":{"CustomRequestHandling":{"InsertHeaders":[{"Name":"x-amzn-waf-bot-confidence","Value":"high"}]}}},"Statement":{"LabelMatchStatement":{"Scope":"LABEL","Key":"awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:maximum"}},"VisibilityConfig":{"SampledRequestsEnabled":true,"CloudWatchMetricsEnabled":true,"MetricName":"ConfidenceHigh"}}]'

Constraints:

  • You MUST add the inbound x-amzn-waf-* stripping rule before the forwarding rules

  • You MUST present the web ACL console link and tell the customer to confirm the rule order:

    https://us-east-1.console.aws.amazon.com/wafv2/homev2/web-acls?region={region}
Example
Example input
{
  "web_acl_name": "example-webacl",
  "web_acl_id": "abc",
  "scope": "REGIONAL",
  "confidence_mapping": {"low": ["TGT_VolumetricSession"], "high": ["TGT_VolumetricSessionMaximum"]}
}
Example output
Overrode Targeted rules to Challenge so evaluation continues.
Mapped label groups to x-amzn-waf-bot-confidence (low/medium/high) and added an inbound strip rule first.
Open the web ACL and confirm the rule order:
https://us-east-1.console.aws.amazon.com/wafv2/homev2/web-acls?region=us-east-1
Troubleshooting
The forwarding rule never runs

An earlier terminating action stopped evaluation. Use Challenge (Step 2).

Labels are not visible to the match rules

Priority order is wrong. Move the label-match rules after the Bot Control group (Step 3).

Security Considerations

This procedure modifies a security control, so misconfiguration directly weakens the application's defenses.

  • Least-privilege IAM. You MUST grant only the specific wafv2: actions a task needs (for example wafv2:GetWebACL and wafv2:UpdateWebACL) rather than wafv2:* or the AWSWAFFullAccess managed policy.

  • Ephemeral credentials. You MUST use IAM roles with temporary credentials (such as an EC2 instance profile, SSO session, or aws sts assume-role) rather than long-lived IAM user access keys when running these WAF CLI commands.

  • Monitor configuration changes. You SHOULD enable AWS CloudTrail on wafv2 management events and set CloudWatch alarms on critical web ACL configuration changes (such as DeleteWebACL and UpdateWebACL rule removals) and on the web ACL's BlockedRequests and CountedRequests metrics, so rule changes and sudden spikes in blocked or counted traffic are detected.

  • Header-spoofing risk. Any x-amzn-waf-* signal forwarded to the origin can be forged inbound. You MUST add the inbound-header-stripping rule whenever a signal or client IP is forwarded (see stripping-inbound-waf-headers-before-trusting-them); without it the origin trusts a spoofable value.

  • Encrypted transport. You MUST forward the signal only to an HTTPS-only origin and the application MUST validate the origin's TLS certificate, so the signal is not exposed in cleartext. You SHOULD use AWS Certificate Manager (ACM) to provision and manage the origin's TLS certificate (for example on an Application Load Balancer), so the certificate is validated and automatically renewed.

  • Defense in depth. You SHOULD treat the forwarded signal as one input among several, not a sole gate; over-relying on a single signal without defense in depth leaves the application exposed if the signal is evaded or degraded.

Additional Resources

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/specialized-skills/networking-and-content-delivery-skills/waf · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download waf.zip