Technical summary
How does REST allowlist (route prefix match; bypasses enforcement) work in Aegisify WAF, and what should administrators verify? protects API traffic by inspecting routes, bodies, authentication requirements, identities, schemas, rate behavior, and protocol-specific abuse signals. This article is grounded in the supplied Aegisify WAF 1.20.13 plugin package. It documents current behavior and defaults rather than relying on older FAQ wording.
Where administrators configure or verify it
Primary wp-admin path: wp-admin → Aegisify WAF → API Shield. Exact controls can be distributed across the related tab/page when the feature is composed of multiple engines.
Current 1.20.13 defaults and related controls
The table below lists settings in the supplied current source that are directly related to this topic. The current default/bound/status shown is code-derived. Where the product does not define a named Medium preset, the shipped default is documented as the baseline operating point rather than inventing a value.
| Setting | Current default / bound / status | Why this default | How to tune safely |
|---|---|---|---|
api_security.pii_response_allowlist |
(blank / site-specific) | Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. | Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. |
wp_protect.rest_allowlist |
(blank / site-specific) | Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. | Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. |
wp_protect.rest_cors_allowlist |
(blank / site-specific) | Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. | Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. |
ddos.endpoint_allowlist |
(blank / site-specific) | Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. | Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. |
ai_security.rest_routes |
(blank / site-specific) | Blank or empty by default because this value depends on the site, organization, route, identity source, recipient, API credential, or exception policy. Configure it only with verified site-specific data. | Supply only validated site-specific values. Leaving it blank/empty means no custom value, exception, recipient, credential, route, or policy has been asserted by default. |
api_security.block_deprecated_routes |
OFF / false | Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. | OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. |
api_security.block_undocumented_routes |
OFF / false | Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. | OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. |
api_security.block_unregistered_routes |
OFF / false | Disabled in the shipped baseline because enabling it can change live request handling, indexing behavior, automation, enforcement, or integration traffic and should be reviewed for the specific site first. | OFF leaves the behavior inactive. Turn it ON only after checking prerequisites and expected traffic/content because this setting can introduce enforcement, automation, indexing, outbound integration, or additional processing depending on the feature. |
Adjustment strategy
Change one control at a time, save it through the product UI, reproduce the legitimate and malicious/test flow, and review the product log/status surface. For enforcement controls, use Monitor/Observe first when normal behavior is uncertain; move to Block only after the signal is reliable. For thresholds, do not jump directly from the default to an extreme unless an active incident requires emergency containment and a recovery path exists.
Operational guidance
On a production WordPress site, a sudden block spike after a plugin/API deployment should first be investigated in WAF logs. Narrow the issue to the exact route, rule family, client identity, or payload characteristic. Prefer a precise exclusion/allowlist or threshold adjustment over disabling broad protection.
Technical keywords
Aegisify WAF, 1.20.13, allowlist, api, bypasses, endpoint, enforcement, exclude, exclusion, match, prefix, rest, route, whitelist, api_security, pii_response_allowlist
Source baseline
Verified package: Aegisify WAF 1.20.13. Primary source files: includes/class-aegiswaf-storage.php; includes/class-aegiswaf-ai-security.php; includes/class-aegiswaf-api-security.php; includes/class-aegiswaf-managed-rules.php; includes/ddos/class-aegiswaf-ddos-storage.php; includes/admin/pages/class-aegiswaf-page-waf-rules.php; includes/admin/pages/class-aegiswaf-page-logs.php; includes/admin/pages/class-aegiswaf-page-access.php. If a future plugin version changes these settings, support should re-read the installed version rather than carry these defaults forward automatically.