It’s possible to specify certain factors that completely by-pass all Firewall checking. In principle, you should not need to whitelist anything or anyone unless you have discovered a collision with another plugin.

Whitelists Options Explanations

The following options should be used sparingly and with caution since you never want to whitelist anyone, even yourself unless you really must.

Option: Whitelist Parameters

How does the pages/parameters whitelist work?

It is a comma-separated list of pages and parameters. A NEW LINE should be taken for each new page name and its associated parameters.

The first entry on each line (before the first comma) is the page name. The rest of the items on the line are the parameters.

The following are some simple examples to illustrate:

edit.php, featured

On the edit.php page, the parameter with the name ‘featured’ will be ignored.

admin.php, url, param01, password

Any parameters that are passed to the page ending in ‘admin.php’ with the names ‘url’, ‘param01’ and ‘password’ will be excluded from the firewall processing.

*, url, param, password

Putting a star first means that these exclusions apply to all pages. So for every page that is accessed, all the parameters that are url, param and password will be ignored by the firewall.


1 - firewall block    Page parameter failed firewall check. The offending parameter was \"page\" with a value of \"xxxxx\".

Parameter to whitelist is: page

2 - firewall block    Page parameter failed firewall check. The offending parameter was \"test-field-input-url_7\" with a value of \"\".

Parameter to whitelist is: *, test-field-input-url_7 as that's the name of the parameter holding the value that's triggering the block.

Important: This option should be used with caution and you should only provide parameter names that you must have excluded.

How to use * (asterisks)

* (asterisks) refers to all pages and for example, you want to whitelist the parameters for all pages:

  • s
  • post_type
  • shop_view
  • add_to_wishlist

To achieve this, you use the following rule as each page (or asterisk) can only appear once:


*, s, post_type, shop_view, add_to_wishlist


This will whitelist those 4 parameters for all pages.

Another example is if you want to do this for 1 particular page, e.g.:


posts.php, s, post_type, shop_view, add_to_wishlist

Hint: You can also whitelist parameter directly from within your audit trail. Just click "Whitelist Param" link, and it'll be whitelisted for your automatically. For example:Important: This is an advanced setting where you can by-pass the firewall for a given page such as ‘hello.php’, or by-pass the firewall for a given parameter sent to that page. This is useful where certain pages/plugins submit data that you always want to leave untouched by the firewall.

Please note that this is a place for whitelisting page request parameters only, and can't be used for whitelisting IP addresses. If you'd like to whitelist IPs, you can use IP Management tool here.

Option: Ignore Administrators

When this option is enabled, authenticated administrator users will not be processed by the firewall rules. 

Note: This is not a recommended option, but if you want to ensure that administrators are never affected by the firewall, check this box. Otherwise, leave it unchecked.

Option: Ignore Search Engines

If you are tracking statistics on your site, Googlebot, MSNbot, and Yahoo Slurp can be very useful. These search engine bots gather (harvest) information about your page for their respective search engine.

A "spider" is a computer program that follows certain links on the web and gathers information as it goes.

When the "Ignore Search Engines" option is enabled, the firewall will try to recognize search engine spiders/bots and not apply firewall rules to them.

Note: This is not recommended, but if for any reason you think search engines are being blocked from crawling your site based on certain “GET” data on your pages, check this box. Otherwise, leave it unchecked.

In general, there is no need to whitelist anything unless there is a compatibility issue to deal with.

For more information on how the Shield's Firewall works, read the blog article here.

For examples of the Firewall entries in the Audit Trail, how to interpret them and whitelist parameters, read the article here