Web Rules Engine

The Web Rules Engine is a User Portal-based service that enables you to self-serve site rules as an alternative to .htaccess rules. The service currently supports management of the following rule types: IP-based Allow/Deny rules, response headers, and rewrite rules.

Overview

The Web Rules Engine (WREn) enables you to self-manage certain site traffic behaviors from the User Portal, such as:

  • Disallowing IP/Range access to protect against malicious attacks and other negative site behavior
  • Allowing IP/Range access for known good actors
    • IPs that have been blocked at a server level cannot be allowed in this way. Allowing an IP only impacts those denied by another access rule.
  • Preventing direct access to private files
  • Restricting traffic from specific countries or regions
  • Modifying cache-control headers and security headers
  • Redirecting a page
  • Rewriting a page URI

For those who previously leveraged .htaccess file rules to self-manage and control these behaviors, the Web Rules service can now be used instead via the User Portal. 


Manage Web Rules

To manage access, header, and rewrite rules for any environment:

  1. Log in to the User Portal
  2. Select the environment name
  3. Click Web Rules in the menu

Additionally, you can choose the Access rules tab, the Header rules tab, or the Rewrite rules tab to manage a specific type of rule.

Web Rules functionality is enabled by default on all environments, but can be disabled by selecting Disable web rules.

NOTE

In some cases, there may be a temporary Global Setting available on the page above that reads “Enable .htaccess support”. This option is only available in specific cases, you can learn more about it here.

Copy Rules to Another Environment

Web rules can be copied from one environment to another environment on the same account. Rules will be copied as-is and will include access, header, and rewrite rules. Duplicate rules on the destination environment will not be copied, so as to not cause any conflicts.

We recommend cleaning up all the rules on both source and destination prior to copying them.

  1. From the Global Settings of the environment rules will be copied from, click Copy rules to another environment.
  1. Select the destination environment(s) to receive the rules
  2. Choose the insert order:
  • Appending the rules will copy the source rules to the bottom of the target rule list.
  • Prepending the rules will copy the source rules to the top of the target rule list.
  1. Click Copy Rules

Copy a Single Rule

To copy a single rule to another environment or multiple environments:

  1. Locate the rule you’d like to copy
  2. Click the 3 dot menu icon to the right
  3. Select Copy to another environment
  1. Select the destination environment(s) to receive the rules
  2. Choose the insert order:
  • Appending the rules will copy the source rules to the bottom of the target rule list.
  • Prepending the rules will copy the source rules to the top of the target rule list.
  1. Click Copy Rule

Allow or Deny XML-RPC

XML-RPC is considered out-dated and is prone to both attack and spam. In most cases the WordPress API can be used instead of XMP-RPC, however you may find some applications still require access to xmlrpc.php.

XML-RPC can be set to allow or deny access via a simple toggle on the Web Rules page for each environment.

  • Select Deny XML-RPC – recommended to block XML-RPC requests.
  • Select Allow XML-RPC to allow XML-RPC requests.

NOTE

XML-RPC is blocked by default on WP Engine environments created after April 2022. We recommend confirming the current setting.

If you choose to allow XML-RPC, we recommend some additional custom access rules to keep it secure. By creating two custom access rules you will first limit the IPs that can access xmlrpc.php, then a second rule (placed directly below the first) will deny all others. For example:

First Rule- Grants limited access to xmlrpc.php:

  • Action: Allow
  • IP: [IP(s) to allow]
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: xmlrpc.php

Second rule- Block all IPs not specified above:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: xmlrpc.php

Access Rules

Access rules can allow you to manage the flow of traffic to a website with certain restrictions. For example, access rules can be used to block an IP range.

Access rules are read in cascading order, can be set for IP or IP ranges, and can have certain conditions applied.

IP and CIDR Standardization

The list of IPs and CIDRs for every access rule are sorted, CIDR blocks are standardized, and duplicates are removed. The standardized list is always equivalent to the original. It will not allow or block anything that wasn’t in the original list.

For example:

177.47.19.194/30,
177.47.19.198/30,
177.47.18.106/29,
200.219.195.250/30


Will be standardized to the equivalent:

177.47.18.104/29,
177.47.19.192/30,
177.47.19.196/30,
200.219.195.248/30

Add Access Rule

To add a new web rule:

  1. Open the Web Rules engine
  2. Select Access Rules
  3. Click Add Rule
  4. Enter the rule
  5. Click Add Rule to validate and save the new rule
  6. Once your web rules have been validated and applied, they will populate in the rule table

Insert Relative Access Rule

Users with existing web rules have additional options for adding new rules in relation to existing rules. This can be useful when creating rules whose order is significant.

  1. Open the Web Rules page
  2. Locate an existing rule
  3. Click the 3 dot menu icon to the right
  4. Select an insert option:
    • Insert rule above – Creates a rule above the current rule. The new rule will be read first.
    • Insert rule below – Creates a rule below the current rule. The new rule will be read second.
    • Learn more about web rule order here.

Edit Access Rule

To edit an existing access rule, for example manually changing the order or IP:

  1. Open the Web Rules page
  2. Locate the rule you wish to edit
  3. Click the 3 dot menu icon to the right
  4. Select Edit Rule
  5. Make the necessary changes, then click Save and apply to revalidate and apply the update

Delete Access Rule

To delete an existing web rule:

  1. Open the Web Rules page
  2. Locate the rule you wish to edit
  3. Click the 3 dot menu icon to the right
  4. Select Delete Rule

Access Rule Conditions

All conditions for the rule must evaluate to true, otherwise the rule will have no effect.

Conditions can be one of the following types:

  • URI
  • QUERY_ARG
  • REQUEST_METHOD
  • HEADER
  • GEOIP COUNTRY CODE

Conditions can use the following operators:

  • Equal to ( = )
  • Not equal to ( != )
  • Regex match ( ~ )
  • Negative regex match ( !~ )

Access Rule Examples

Below are some examples of common rules you may use. Rules can be modified as necessary, for example switching deny and allow, or using an IP range versus a single IP.

Deny an IP address:

  • Action: Deny
  • IP: [IP address to deny]
  • Conditions: None are needed

Deny a bot by way of its user agent:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: Header
    • Name: User-Agent
    • Operator: Regex matches (~)
    • Value: [Enter the actual user agent name in this field] EX: badbot

Allow a single IP address access to wp-admin and deny all other IPs access:

First rule (should be placed above the second rule):

  • Order: 1
  • Action: Allow
  • IP: [IP address to allow]
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: wp-login

Second rule (should be placed below the first rule):

  • Order: 2
  • Action: Deny
  • IP: All
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: wp-login

Deny traffic from non-US GeoIPs:

  • Action: Deny
  • IP: All
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Not equal to (!=)
    • Country Codes: [‘US – United States’]

Block multiple countries from accessing a website:

In this example, block China, India, and South Africa.

  • Action: Deny
  • Comment: Block China, India, and South Africa
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Equals (=)
    • Value: CN, IN, ZA

Only allow traffic from specific countries, block all other countries:

In this example, allow traffic from the United States (US), and Canada (CA) and block everyone else.

  • Action: Deny
  • Comment: Only allow US and Canada
  • Conditions:
    • Type: GeoIP Country Code
    • Operator: Does Not Equal (!=)
    • Value: US, CA

If you want to block an entire country/region but allow a specific IP in one of those countries to access the site, you would just create an Allow rule for the specific IP and place it before the country block. Be sure to name the rule with an identifiable phrase, as the order here is important.


Header Rules

Using the Web Rules Engine, response headers can be set. This section can be used to add security headers or to modify cache behavior via cache control headers.

Header rules function the same as access rules; they are read in cascading order and can be set/unset by header name.

Add Header Rule

To add a header rule to Nginx:

  1. Log in to the User Portal
  2. Select the environment name
  3. Click Web Rules
  4. Select Header Rules
  5. Click Add header rule
  6. Enter the rule, then click Save

For header rule conditions, see Access Rule Conditions above.

Header Rule Examples

Set a header to allow all access control for 2xx status responses:

  • Action: Set
  • Name: Access-Control-Allow-Origin
  • Value: *
  • When: Only on successes
  • Conditions: None are needed

Unset Set-Cookie header for all responses:

  • Action: Unset
  • Name: Set-Cookie
  • When: All responses
  • Conditions: None are needed

Set Cache Control for URIs in /resources:

  • Action: Set
  • Name: Cache-Control
  • Value: max-age=604800, public
  • When: Only on successes
  • Conditions:
    • Type: URI
    • Operator: Regex matches (~)
    • Value: /resources/

Set HSTS header for 2 years, include subdomains, and preload:

  • Action: Set
  • Name: Strict-Transport-Security
  • Value: max-age=63072000; includeSubDomains; preload
  • When: Only on successes
  • Conditions: None are needed

Restricted Headers

  • x-powered-by
  • server
  • date
  • x-orig-cache-control
  • nr-enabled
  • x-cache
  • x-cache-group
  • x-cacheable
  • X-pass-why
  • Any header that includes WPE

Rewrite Rules

Using the Web Rules Engine, rewrite rules can be added. A rewrite can be used to change the URL requested by a client and route the client to a new location.

Rewrite rules are read in cascading order. Conditions can be applied to a rule to limit when that rule is triggered. The first rewrite rule whose conditions are met is triggered. Note that the source of a rewrite rule acts as an implicit URI condition.

Rewrite Rule Fields

Action

The rewrite action defines what type of rewrite to perform. The supported actions are:

  • Permanent redirect (301 status code)
  • Temporary redirect (302 status code)
  • Internal rewrite

Permanent and temporary redirect responds to the client with the appropriate status code and directs the client to request the location defined in the rule destination.

The internal rewrite action responds with content from the rule destination without redirecting the client to another URI. For example, a request for /page-1 may be rewritten internally to /page-2, such that the contents of /page-2 are returned to the client without the client being aware the content is from /page-2.

Source

The rule source is a regular expression (RegEx) that must match the original request URI, including the query string, for the rewrite to happen. The rule source regex may contain named and numbered capture groups to be referenced in the rule destination.

Destination

The rule destination defines the target URI for the rule. It may be a static URI, or it may include references to capture groups from the rule source. New query string arguments can be added in the rule destination. Additionally, original query string arguments may be preserved via the “Keep or Discard Original Query String” option.

Keep or Discard Original Query String

For each rewrite rule, you may declare whether to keep or discard the original query string of the request. Keeping the query string is the default behavior. If the rule destination has a query string and the rule preserves the original query string, original query string arguments will be appended to the rule destination.

Add Rewrite Rule

To add a rewrite rule to Nginx:

  1. Log in to the User Portal
  2. Select the environment name
  3. Click Web Rules
  4. Select Rewrite Rules
  5. Click Add rewrite rule
  6. Enter the rule, then click Save

For rewrite rule conditions, see Access Rule Conditions above.

Rewrite Rule Examples

Simple 301 redirect

  • Action: permanent
  • Source: /oldpage/
  • Destination: /newpage/
  • Conditions: None are needed

Rewrite with condition

  • Action: internal
  • Source: ^/index.html
  • Destination: bot.html
  • Conditions:
    • Type: Header
    • Name: User-Agent
    • Operator: Equals (=)
    • Value: ROBOT-UA

Redirect with a capture group

  • Action: permanent
  • Source: (.*)
  • Destination: https://www.example.com/$1
  • Conditions: None are needed

Capture Group Examples

Rewrite rules’ source and destination parameters support named and numbered regular expression capture groups. Named capture groups can help with readability and document the intention of the pattern.

Named capture group

  • Source: /page-(?P<number>\d+)/
  • Destination: /pages/$number/

Numbered capture groups

  • Source: /page-(\d+)/(.*)
  • Destination: /pages/$1/$2

Concatenating characters to capture groups

If static characters should be concatenated with contents of a capture group, wrap the capture group reference in curly braces “{}”.

  • Source: /page-(\d+)v1
  • Destination: /page-${1}v2

Web Rule Order

The order Web Rules are placed in the list can be critical to how they function because many rules can have an impact each other. Web Rules are read from top to bottom, and rules that are read first take priority.

Another way to visualize this is that exceptions to the rule are listed first. For example, if you want to block an IP range but allow a single IP within that range, you will need two rules. The rule listed first will allow the IP address, and the rule listed second will block the IP range.

If a specific exception is allowed higher on the list, the priority will apply for all subsequent rules. In the following example, the bottom two rules deny several countries and a user agent. The rule at the top, allowing a specific IP, is read first and has the highest priority over any rules below it. Therefore, the topmost rule will allow this IP even if it is located in one of the blocked countries OR utilizing the blocked user agent.

With regard to rewrite rules, the first rule whose conditions are met for the request will take effect. If a URL is impacted by multiple rewrite rules, the topmost rule will trump the other rules that may apply to that specific URL. If a more general rewrite is placed first, this could impact lower rules down the road. Being specific with your RegEx and rule order can prevent unintended rewrites from occurring.

Rules can be rearranged, if needed, using the drag-and-drop functionality on the left. Adding a rule relative to another rule can make implementing new rules easier. It’s recommended to use the relative adding method when possible, rather than manually rearranging each rule later, to ensure the order is applied as intended.

Rules can have comments added to help prevent confusion and subsequent damage to the rule order over time. For example, the rule to allow a single IP must be above the rule blocking the country this IP is located in, as an exception. Adding notes can help keep this order clear as the rules list changes or grows:


NEXT STEP: Learn how to enable WebP for image optimization

Still need help? Contact support!

We offer support 24 hours a day, 7 days a week, 365 days a year. Log in to your account to get expert one-on-one help.

The best in WordPress hosting.

See why more customers prefer WP Engine over the competition.