REST Rules

Last updated: 10th July 2026 for CC Security Essentials Pro version 1.0

Introduction

The WordPress REST API provides a standard way for WordPress, plugins and external applications to communicate with your website.

Many websites can safely restrict public access to the REST API using the protection provided by CC Security Essentials.

Some websites, however, legitimately require selected REST API endpoints to remain publicly accessible, while others may need to block particular routes even for authenticated users.

CC Security Essentials Pro adds REST Rules, allowing you to create precise allow and block rules for individual REST API routes.

For most websites, the core REST API Protection provided by CC Security Essentials is sufficient. REST Rules are intended for websites that require more detailed control.

Before You Create Rules

Before creating REST Rules, we recommend:

  • enabling REST API Protection in the core plugin;
  • testing your website normally;
  • confirming that any required integrations continue to operate correctly.

Only create custom rules when there is a genuine need to change the default behaviour.

Keeping your configuration as simple as possible generally results in a more secure and maintainable website.

How REST Rules Work

Each incoming REST API request is compared against the configured rules.

Depending on the matching rule, the request may be:

  • allowed;
  • blocked;
  • or handled by the standard REST API Protection provided by the core plugin.

Rules are evaluated in order.

The first matching rule determines how the request is handled.

For this reason, more specific rules should normally appear before broader rules.

Allow Rules

An Allow Rule permits requests that would otherwise be restricted.

Typical examples include:

  • a public integration that requires a specific endpoint;
  • a trusted application communicating with WordPress;
  • a plugin that legitimately exposes selected REST API routes.

Allow Rules should be as specific as possible.

Avoid allowing broader route patterns than necessary.

Block Rules

A Block Rule explicitly prevents access to matching REST API routes.

This can be useful when:

  • a plugin exposes functionality that should not be accessible;
  • an endpoint is no longer required;
  • access should be restricted regardless of normal visitor rules.

Blocking unnecessary endpoints can help reduce the attack surface of your website.

Route Patterns

Rules match REST API routes.

A route typically looks something like:

/wp/v2/posts

or

/my-plugin/v1/orders

The Route Tester can help identify the exact route used by a request.

Wildcards

REST Rules support wildcard matching where appropriate.

Wildcards allow a single rule to match several related routes.

For example, a rule may match every endpoint beneath a particular plugin namespace.

Use wildcards carefully.

A broad wildcard may unintentionally affect additional endpoints introduced by future plugin updates.

Where possible, create the narrowest rule that satisfies your requirements.

Rule Order

Rules are processed from top to bottom.

Once a matching rule has been found, no further rules are evaluated.

For example:

Allow:
/my-plugin/v1/public

Block:
/my-plugin/*

In this case, requests to /my-plugin/v1/public are allowed because the first rule matches before the broader block rule.

If the order were reversed, the broader block rule would prevent access before the allow rule was reached.

Review rule order whenever unexpected behaviour occurs.

The Route Tester

The Route Tester helps you understand how REST Rules affect a particular request.

Enter the route you wish to test.

The Route Tester then reports:

  • whether the route matches a rule;
  • which rule was matched;
  • whether the request would be allowed or blocked.

This makes it much easier to verify your configuration before making changes to a live website.

Security Events

When Security Events are enabled, blocked REST API requests can be recorded for later review.

Reviewing these events can help identify:

  • repeated attempts to access restricted endpoints;
  • incorrectly configured integrations;
  • routes that may require additional rules.

Use this information to improve your configuration over time.

Best Practice

When creating REST Rules we recommend:

  • creating the fewest rules necessary;
  • using specific route patterns;
  • placing specific rules before broader rules;
  • testing each rule after creating it;
  • reviewing Security Events periodically;
  • removing rules that are no longer required.

Complex rule sets are often harder to understand and maintain.

Common Questions

Do I need REST Rules?

Probably not.

Many websites work perfectly using the standard REST API Protection provided by the core plugin.

REST Rules are intended for websites that require more detailed control.

Should I allow every REST API route used by a plugin?

No.

Only allow the routes that genuinely need to remain publicly accessible.

Leaving unnecessary endpoints available may reduce the effectiveness of REST API Protection.

Can I accidentally block part of my website?

Potentially, yes.

If an essential REST API route is blocked, some functionality provided by WordPress or another plugin may stop working.

For this reason we recommend creating rules gradually and testing the affected functionality after each change.

What if I make a mistake?

If a rule prevents expected behaviour:

  1. review the rule order;
  2. use the Route Tester;
  3. temporarily disable the rule;
  4. test the affected functionality again.

Working methodically usually makes problems easy to identify.

Troubleshooting

A plugin has stopped working

The plugin may depend upon a REST API route that is now being blocked.

Use the Route Tester to identify the affected route and review your configured rules.

My Allow Rule doesn’t seem to work

Check:

  • the exact route;
  • wildcard placement;
  • rule order;
  • whether an earlier rule matches first.

The first matching rule always takes precedence.

Too many rules are becoming difficult to manage

Review whether several rules can be replaced by a more specific pattern.

Removing obsolete rules also helps keep the configuration easy to understand.

I don’t know which route to allow

Use the Route Tester together with Security Events to identify the route being requested before creating a rule.

Avoid creating broad Allow Rules simply to “make something work.”

Security Considerations

REST Rules are intended to provide precise control over REST API access.

Every additional Allow Rule should have a clear purpose.

When reviewing your configuration, ask:

  • Is this route still required?
  • Who needs access?
  • Could the rule be made more specific?
  • Has the associated plugin changed since the rule was created?

Reviewing your rules periodically helps ensure that they continue to reflect your website’s current requirements.

Related Articles

Continue with: