Do we need to migrate from OWASP 3.2 to DRS 2.x for Azure Application Gateway WAF?

Hi,

Thank you for the detailed explanation. This is very helpful.

I have one follow-up clarification regarding preserving the existing configuration during the migration from OWASP_3.2 to Microsoft_DefaultRuleSet 2.x.

Our current Application Gateway WAF policy has:

OWASP_3.2

Microsoft_BotManagerRuleSet_1.1

Existing exclusions

Potential managed rule overrides / disabled rules

Custom rules

You mentioned that using PowerShell/CLI/ARM/Terraform should preserve rule overrides, exclusions, and custom rules, while using the Azure Portal may reset managed-rule overrides.

Could you please confirm the following:

What is the recommended CLI, PowerShell, or ARM method to update the existing WAF policy from OWASP_3.2 to Microsoft_DefaultRuleSet_2.2 while preserving existing exclusions, custom rules, and managed rule overrides?

Is there an official Microsoft example command or ARM/Bicep snippet for this in-place migration?

If some existing overrides are linked to OWASP-specific rule IDs, will Azure automatically map them to DRS 2.2 rules where possible, or do we need to manually review and recreate those overrides after the migration?

Is there a supported way to export the current WAF policy, update only the managed rule set type/version, and reapply it safely as a rollback-capable process?

For production, would Microsoft recommend switching the policy to Detection mode first, performing the ruleset migration, reviewing logs, and then switching back to Prevention?

We want to avoid using the Azure Portal if it resets managed-rule overrides, so we would like to follow the safest Microsoft-supported scripted approach.

Thanks.

Thanks for the follow-up on scripting the WAF policy migration—I'll keep this practical and focused on preserving your tuned OWASP 3.2 + Bot Manager setup while moving to DRS 2.2.

Export first for safety, then update just the ruleset versions via CLI. This keeps your exclusions, custom rules, and managed rule overrides intact—no portal needed.

Export Current Policy (Rollback Ready):

az network waf policy export --resource-group <rg-name> --name <waf-policy-name> --file backup-policy.json

Update to DRS 2.2 (Preserves Everything):

bash
az network waf policy update \
  --resource-group <rg-name> \
  --name <waf-policy-name> \
  --managed-rules '[
    {
      'ruleSetType': 'Microsoft_DefaultRuleSet',
      'ruleSetVersion': '2.2'
    },
    {
      'ruleSetType': 'Microsoft_BotManagerRuleSet',
      'ruleSetVersion': '1.1'
    }
  ]'

PowerShell alternative:

powershell
$wafPolicy = Get-AzWebApplicationFirewallPolicy -ResourceGroupName <rg-name> -Name <waf-policy-name>
$wafPolicy.ManagedRules.ManagedRuleSets[0].RuleSetType = 'Microsoft_DefaultRuleSet'
$wafPolicy.ManagedRules.ManagedRuleSets[0].RuleSetVersion = '2.2'
Set-AzWebApplicationFirewallPolicy -WebApplicationFirewallPolicy $wafPolicy

ARM/Bicep Snippet

Export to JSON, tweak only managedRuleSets, redeploy:

json
{
  "type": "Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies",
  "properties": {
    "managedRules": {
      "managedRuleSets": [
        { "ruleSetType": "Microsoft_DefaultRuleSet", "ruleSetVersion": "2.2" },
        { "ruleSetType": "Microsoft_BotManagerRuleSet", "ruleSetVersion": "1.1" }
      ]
    }
  }
}

az deployment group create --resource-group <rg> --template-file updated-policy.json

Rule ID Mapping & Overrides

No auto-mapping—OWASP IDs (e.g., 942100) won't match DRS rules, so they'll go inactive post-upgrade. Review your ruleOverrides array, map to DRS equivalents manually (use the rule group docs below), and test.

Rollback & Production Flow

Export/Reapply: az network waf policy create --file backup-policy.json --name rollback-policy.

Safe Prod Path: Detection mode → CLI update → Log Analytics review (AzureDiagnostics | where wafAction_s == "Blocked") → Prevention. Expect minor tuning for new Threat Intel rules.

Clone to staging first. This mirrors Microsoft's scripted guidance exactly.

Official Docs:

• Upgrade WAF Ruleset Version
• DRS 2.x Rule Groups
• WAF Policy CLI Reference

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Hi,

Thank you, this is very helpful.

One final clarification please.

In the example provided, the CLI command uses:

az network waf policy update

However, for our Application Gateway WAF Policy, the Azure CLI command group available in our environment appears to be:

az network application-gateway waf-policy

For example, we can run:

az network application-gateway waf-policy show az network application-gateway waf-policy managed-rule rule-set list

Could you please confirm the exact supported Azure CLI command for Application Gateway WAF Policy to migrate from OWASP_3.2 to Microsoft_DefaultRuleSet_2.2?

Specifically, should we use:

az network application-gateway waf-policy managed-rule rule-set update --policy-name --resource-group --type Microsoft_DefaultRuleSet --version 2.2

Also, could you confirm whether this command preserves existing exclusions, custom rules, and managed rule overrides, or whether we should instead export the full policy JSON, modify only properties.managedRules.managedRuleSets, and redeploy it using ARM/Bicep?

We want to avoid accidentally clearing existing managed rule overrides during the migration.

Thanks.

Hi **
**I am still waiting for your reply on above comment please.

Thanks****

Regarding your questions:

Is OWASP_3.2 still supported and recommended for Application Gateway WAF?

Supported: Yes. Recommended latest: No. Microsoft’s support policy lists CRS 3.2 as supported, but Microsoft recommends using the latest rule set where possible; for Application Gateway WAF, the latest recommended managed rule set is DRS 2.2. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ruleset-support-policy, https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules

Is migration to DRS 2.1 / 2.2 mandatory or only recommended?

Recommended now, not immediately mandatory while CRS 3.2 remains within the supported window. However, it becomes operationally necessary before CRS 3.2 reaches end of support under Microsoft’s rolling support policy. CRS 3.2 support ends one year after the first DRS version newer than DRS 2.2 is released. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ruleset-support-policy

Can the existing WAF policy be updated in-place, or is a new WAF policy recommended?

Technically, the existing policy can be updated in-place. For production, the safer path is to clone/export and test a separate WAF policy first, then associate it after validation. Microsoft’s upgrade guidance supports changing the managed rule set on an existing policy, but warns to preserve exclusions/overrides and validate new rules safely. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/upgrade-ruleset-version, https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules

Will existing exclusions, disabled rules, and custom rules continue to work after upgrading?

Custom rules and global policy settings remain separate from the managed rule set and generally continue. Managed rule overrides, disabled rules, and rule-level exclusions do not automatically remain valid when the rule set changes unless they are carried forward/remapped. If changed through Azure portal, previous managed-rule customizations such as rule state, rule actions, and rule-level exclusions are reset to the new managed rule set defaults; custom rules, policy settings, and global exclusions remain unaffected. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules, https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/upgrade-ruleset-version

Are there known breaking changes or compatibility concerns?

Yes. DRS introduces different rule groups, new rule IDs, removed CRS rules, Microsoft Threat Intelligence rule groups, newer engine behavior, and additional detections. Microsoft provides mapping guidance for legacy CRS rule groups to DRS groups and warns not to copy overrides/exclusions for removed rules. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/upgrade-ruleset-version, https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules

Is Microsoft planning a deprecation timeline for OWASP_3.2 on Application Gateway WAF?

Microsoft’s current support policy does **not give a fixed calendar end date for CRS 3.2 yet. It states CRS 3.2 is supported, and its support ends one year after the release of the first DRS version newer than DRS 2.2. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ruleset-support-policy

How to avoid production impact?

Use a controlled migration: inventory current customizations, clone policy, upgrade the clone to DRS 2.2, preserve/remap exclusions and overrides, set new/unknown rules to Log where needed, run Detection/Log validation, inspect WAF logs, tune false positives, then switch production association. Microsoft recommends testing in a non-production environment and using logs/exclusions to tune legitimate traffic. - https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/upgrade-ruleset-version, https://learn.microsoft.com/en-us/troubleshoot/azure/web-application-firewall/web-application-firewall-troubleshoot

Cheers