Securing AEM as a Cloud Service with Traffic Filter and WAF Rules

In recent times, threats to web applications have become increasingly common, including Denial of Service (DoS), Distributed Denial of Service (DDoS), malicious traffic, such as bots, injection attacks, and the misuse of system resources. These threats, if successful, can lead to downtime, data breaches, and degraded user experience. And this is where AEM as a Cloud Service steps in, with built-in traffic filtering and WAF rules, to secure applications while ensuring optimal performance.

In this blog, we will cover traffic filter rules and a subcategory of those rules known as WAF (Web Application Firewall) traffic filter rules, or simply WAF rules. We will also discuss the syntax for writing these rules and share a few examples.

Before diving into the syntax and examples, let’s first explore where we write these rules and how and where we deploy them.

Rule Configuration and Deployment

So, using Cloud Manager’s config pipelines, these traffic rules are deployed to the Adobe managed CDN. They can be deployed on dev, stage and production environments. We need to create a Config pipeline that will deploy the traffic rules.

1. In the Cloud Manager, go to the Pipelines section.
   

   Piplines Menu

2. On the right corner, you’ll see Add Pipeline.
   

   Add Pipeline

3. Select Add Non-Production Pipeline.
   

   Non-production Pipeline

4. Now, configure the details as mentioned in the screenshot
   

   Pipeline Config Section 1

   Pipeline Config Section 2

Syntax

The syntax for traffic rules goes like this,

  kind: "CDN"
  version: "1"
  metadata:
  envTypes: ["dev"]
  Data: <traffic-filter-rules>

These Traffic Rules are usually written cdn.yaml file in the config folder in the codebase, this is at the root level. If the configuration for all environments is same, then only one file should be enough. Else, environment-specific folder or environment-specific cdn.yaml(for eg. cdn-stg.yaml) files can be created.

Common cdn.yaml for all environments

Environment-specific Folders

A traffic rules YAML file is made up of four main fields,

• kind: identifies the type of configuration; for traffic rules, this is always set to CDN.
• version: specifies the configuration format version; AEM currently supports only 1.
• metadata: provides additional context, such as the environment the rules are written for, helping keep configurations organized.
• data: the main section where the traffic filter rules are defined, covering both standard and WAF rules.

Defining Rules in the data Section

As mentioned above, the data field maintains all the traffic filter rules, which can be based on the URL, hostname, geolocation, IPs, request headers, etc. Following is an example of blocking a particular path in the author or publish environment. In the example below, the user tried to access faqs.html, but it returned Error 406 Not Acceptable, which is expected after writing the traffic rule.
Example for Standard Traffic Filter Rules,

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "block-path"
          when:
            allOf:
  - reqProperty: tier 
    equals: “author|publish” 
              - reqProperty: path
    equals: “/content/wknd/us/en/faqs.html”
          action:
            type: block

Error Message

(Note: We will look at each field in the later section of this blog.)

If you have licensed the Enhanced Security or WAF-DDoS Protection Security, you can configure a sub category of traffic filter rules named as WAF rules, which consumes one or more WAF flags.
Example for WAF Rules,

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "WAF-rule-for-XSS-and-SQL-Injection"
          when: 
  - reqProperty: path 
    like: "*"
          action:
            type: block
            wafFlags: [ XSS, SQLI]

Breaking Down the data Section

Inside the data field of the cdn.yaml, you’ll find trafficFilters, which contains the rules section. This is where all traffic filter rules are written. Each rule is made up of a few key fields:

1. name – A unique identifier for the rule. It must be alphanumeric, can include hyphens, and should not exceed 64 characters.
2. when – Defines the condition(s) under which the rule is applied.
   • Use allOf if all conditions must be true.
   • Use anyOf if only one condition needs to be true.
   • For a single condition, you can skip both.

Writing Conditions with when

A condition has two parts: a getter (what to check) and a predicate (how to evaluate it).
Syntax for single condition:

  when:
    - <getter>: <value>
      <predicate>: <value>

Multiple conditions:

  when:
    allOf:
      - <getter>: <value>
        <predicate>: <value>
      - <getter>: <value>
        <predicate>: <value>

Getters and Predicates

• Getters tell the rule what part of the request to inspect, such as:
  • reqProperty => path, URL, query string, method, client IP, region, country
  • reqHeader, queryParam, reqCookie, postParam => request headers, query parameters, cookies, or POST data
• Predicates define how the value should be checked:
  • equals, doesNotEqual => direct comparison
  • like, matches => pattern or regex matching
  • in, notIn => list membership
  • exists =>  property presence

The action Field

The action field defines what happens when a condition is met. Options include:

• Allow – Lets the request pass through if it matches the rule.
• Block – Denies the request completely. This is commonly used when dealing with malicious traffic, suspicious patterns, or specific wafFlags.
• Log – It records the request details for monitoring without blocking or allowing.
• Or a combination of these with wafFlags for advanced filtering.

Using wafFlags

If you have Enhanced Security or WAF-DDoS Protection enabled, you can use wafFlags to block specific threats, such as:

• XSS (Cross-Site Scripting)
• SQLI (SQL Injection)
• BAD-IP, BACKDOOR, CVE exploits
• MALFORMED-DATA, JSON-ERROR, XML-ERROR

These are just a few examples; there are more in the list.

Example: WAF Rule

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "WAF-rule-for-XSS-and-SQL-Injection"
          when: 
            - reqProperty: path 
              like: "*"
          action:
            type: block
            wafFlags: [XSS, SQLI]

With traffic filter rules and WAF rules, AEM as a Cloud Service empowers you to stop harmful requests before they reach your application. A well-structured cdn.yaml not only strengthens security but also ensures a smooth, uninterrupted experience for your users. Start applying these rules today to strengthen your AEM Cloud security.