When should administrators use Enable REST API protection layer (REST inspection enforcement) in Aegisify WAF?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary When should administrators use Enable REST API protection layer (REST inspection enforcement) in Aegisify WAF? 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.ajax_enforcement_enabled 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.ajax_monitoring_enabled 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.jwt_validation_enabled 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. wp_protect.rest_api_key_enabled 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.enabled ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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, ajax, api, enable, endpoint, enforcement, graphql, grpc, inspection, jwt, layer, protection, rest, route, api_security 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.

When should administrators use Enable WordPress protection layer (master switch) in Aegisify WAF?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary When should administrators use Enable WordPress protection layer (master switch) in Aegisify WAF? is part of the WAF request-inspection, enforcement, visibility, or exception-management surface. 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 → WAF Rules / Settings. 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 ddos.enable_cache_bypass_detection ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. ddos.enable_search_detection ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. waf.enable_normalization ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. waf.enable_owasp ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. access.enabled 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. ai_security.agency.enabled 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. ai_security.ajax_enabled ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. ai_security.audit.enabled ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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 Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required. Technical keywords Aegisify WAF, 1.20.13, enable, layer, master, protection, switch, wordpress, ddos, enable_cache_bypass_detection, enable_search_detection, waf, enable_normalization, enable_owasp, access, enabled 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.

How does Bot analytics charts (24h trend, 7d trend, radar, UA, etc.) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Bot analytics charts (24h trend, 7d trend, radar, UA, etc.) work in Aegisify WAF, and what should administrators verify? classifies and controls automated clients while preserving configured search-crawler compatibility. 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 → Bot Control. 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 bot.crawler_policies.agent compatible “compatible” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.bad_ua_list curl wget python-requests httpclient “curl wget python-requests httpclient ” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.block_bad_ua ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. bot.crawler_policies.ads standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.other standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.search compatible “compatible” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.training standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.seo_crawler_compatibility ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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, 24h, 7d, agent, analytics, automation, bot, charts, crawler, radar, trend, ua, crawler_policies, bad_ua_list, block_bad_ua 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.

How should MaxMind MMDB path setting (framework for provider usage) be configured in Aegisify WAF, and what is the current default?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How should MaxMind MMDB path setting (framework for provider usage) be configured in Aegisify WAF, and what is the current default? is part of the WAF request-inspection, enforcement, visibility, or exception-management surface. 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 → WAF Rules / Settings. 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 intel.maxmind_mmdb_path (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. bot.per_path_limits [] 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. managed_rules.categories.path_traversal ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. managed_rules.thresholds.path_traversal 1 Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. ai_security.excluded_paths (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.front_paths (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. common_attacks.block_known_sensitive_paths ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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 Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required. Technical keywords Aegisify WAF, 1.20.13, framework, maxmind, mmdb, path, provider, usage, intel, maxmind_mmdb_path, bot, per_path_limits, managed_rules, categories, path_traversal, thresholds 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.

How does Geo/ASN provider framework (hook/provider selection support) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Geo/ASN provider framework (hook/provider selection support) work in Aegisify WAF, and what should administrators verify? is part of the WAF request-inspection, enforcement, visibility, or exception-management surface. 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 → WAF Rules / Settings. 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 intel.geo_provider none “none” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. ai_security.audit.include_provider_model ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. ai_security.providers.action monitor “monitor” is the shipped baseline so administrators can collect evidence and verify normal traffic or behavior before moving to stronger enforcement where applicable. Where this control exposes Off / Monitor / Block: Off disables its decision path; Monitor records/evaluates without blocking; Block enforces the decision. Start with Monitor for uncertain traffic, then move to Block after reviewing false positives and exceptions. ai_security.providers.allowed_hosts api.openai.com api.anthropic.com generativelanguage.googleapis.com *.aiplatform.googleapis.com api.cohere.com api.mistral.ai api.groq.com api.perplexity.ai api.x.ai api.deepseek.com api.together.xyz api.fireworks.ai openrouter.ai *.openai.azure.com bedrock-runtime.*.amazonaws.com “api.openai.com api.anthropic.com generativelanguage.googleapis.com *.aiplatform.googleapis.com api.cohere.com api.mistral.ai api.groq.com api.perplexity.ai api.x.ai api.deepseek.com api.together.xyz api.fireworks.ai openrouter.ai *.openai.azure.com bedrock-runtime.*.amazonaws.com” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. ai_security.providers.allowed_models (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.providers.denied_hosts (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.providers.denied_models (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.providers.enabled 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 Use the feature’s logs and current request evidence as the tuning source. Compare normal traffic with the event that triggered the control, then change only the smallest setting required. Technical keywords Aegisify WAF, 1.20.13, asn, country, framework, geo, geolocation, hook, intel, provider, selection, support, geo_provider, ai_security, audit, include_provider_model 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.

How does ASN blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does ASN blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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 → WAF Rules / Settings. 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.ajax_enforcement_enabled 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.enforcement_enabled 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.monitor_enforcement_policy.allow_critical_single_signal 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.monitor_enforcement_policy.allow_direct_policy_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.allow_explicit_custom_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.block_score_threshold 10 The shipped value of 10 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. api_security.monitor_enforcement_policy.minimum_independent_signals 2 The shipped value of 2 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. app_monitoring.enforcement_policy.allow_critical_single_signal 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, asn, blocking, enforcement, only, provider, requires, api_security, ajax_enforcement_enabled, enforcement_enabled, monitor_enforcement_policy, allow_critical_single_signal, allow_direct_policy_block, allow_explicit_custom_block, block_score_threshold 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.

How does Country blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Country blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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 → WAF Rules / Settings. 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.ajax_enforcement_enabled 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.enforcement_enabled 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.monitor_enforcement_policy.allow_critical_single_signal 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.monitor_enforcement_policy.allow_direct_policy_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.allow_explicit_custom_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.block_score_threshold 10 The shipped value of 10 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. api_security.monitor_enforcement_policy.minimum_independent_signals 2 The shipped value of 2 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. app_monitoring.enforcement_policy.allow_critical_single_signal 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, blocking, country, enforcement, only, provider, requires, api_security, ajax_enforcement_enabled, enforcement_enabled, monitor_enforcement_policy, allow_critical_single_signal, allow_direct_policy_block, allow_explicit_custom_block, block_score_threshold 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.

How does IP / CIDR blocklist enforcement (PRO-only) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does IP / CIDR blocklist enforcement (PRO-only) work in Aegisify WAF, and what should administrators verify? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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 → WAF Rules / Settings. 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.ajax_enforcement_enabled 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.enforcement_enabled 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.monitor_enforcement_policy.allow_critical_single_signal 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.monitor_enforcement_policy.allow_direct_policy_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.allow_explicit_custom_block ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. api_security.monitor_enforcement_policy.block_score_threshold 10 The shipped value of 10 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. api_security.monitor_enforcement_policy.minimum_independent_signals 2 The shipped value of 2 is the exact current default encoded by the plugin and should be treated as the baseline unless site evidence supports a change. Treat this numeric value as the shipped baseline. Adjust one step at a time, document the reason, and verify the operational effect before making the setting more extreme. app_monitoring.enforcement_policy.allow_critical_single_signal 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, blocklist, cidr, enforcement, ip, only, api_security, ajax_enforcement_enabled, enforcement_enabled, monitor_enforcement_policy, allow_critical_single_signal, allow_direct_policy_block, allow_explicit_custom_block, block_score_threshold 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.

How should Behavioral scoring (PRO-only scoring + threshold enforcement) be configured in Aegisify WAF, and what is the current default?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How should Behavioral scoring (PRO-only scoring + threshold enforcement) be configured in Aegisify WAF, and what is the current default? controls deterministic request inspection and matching for common web-attack techniques, custom rules, managed signatures, and heuristics. 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 → WAF Rules / Settings. 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 intel.behavioral_threshold 80 The shipped value of 80 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. managed_rules.anomaly_scoring.enabled 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. managed_rules.anomaly_scoring.score_per_rule 5 The shipped value of 5 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For a positive-risk score threshold, lowering the threshold is generally more sensitive/aggressive; raising it requires stronger evidence. Tune from the shipped value using observed true positives and false positives. managed_rules.anomaly_scoring.threshold 10 The shipped value of 10 is the current baseline threshold or capacity. It is intentionally finite so the control can provide useful protection or bounded resource use without starting at an extreme. For abuse/rate thresholds, a lower number is generally more aggressive and can stop attacks sooner but may affect legitimate bursts; a higher number is more tolerant but allows more activity before intervention. Change incrementally and validate against logs. 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, behavioral, enforcement, only, scoring, threshold, intel, behavioral_threshold, managed_rules, anomaly_scoring, enabled, score_per_rule 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.

How does Bot Control logging (allow + rate_limit events with matched pattern and scope) work in Aegisify WAF, and what should administrators verify?

body.single-avada_faq h1.entry-title, body.single-avada_faq .entry-title, .fusion-faq-shortcode .fusion-toggle-heading, .fusion-faq-shortcode .panel-title a, .fusion-accordian .panel-title, .fusion-accordian .panel-title a {font-size:14px!important;color:#2d2e3d!important;} .aegisify-faq-tech,.aegisify-faq-tech p,.aegisify-faq-tech li,.aegisify-faq-tech td,.aegisify-faq-tech th,.aegisify-faq-tech code {font-size:11.5px!important;color:#2d2e3d!important;line-height:1.65;} .aegisify-faq-tech h2 {font-size:14px!important;color:#2d2e3d!important;line-height:1.4;margin:20px 0 8px;} .aegisify-faq-tech h3 {font-size:12.5px!important;color:#2d2e3d!important;line-height:1.45;margin:16px 0 6px;} .aegisify-faq-tech table {width:100%;border-collapse:collapse;margin:10px 0 14px;} .aegisify-faq-tech th,.aegisify-faq-tech td {vertical-align:top;text-align:left;border:1px solid #dedfe3;padding:7px 8px;} .aegisify-faq-tech code {overflow-wrap:anywhere;word-break:break-word;} Technical summary How does Bot Control logging (allow + rate_limit events with matched pattern and scope) work in Aegisify WAF, and what should administrators verify? provides security telemetry and forensic context for inspected, logged, challenged, rate-limited, blocked, and operational events across WAF subsystems. 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 → Logs. 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 bot.crawler_policies.agent compatible “compatible” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.bad_ua_list curl wget python-requests httpclient “curl wget python-requests httpclient ” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.block_bad_ua ON / true Enabled in the shipped baseline as the product’s current safe operating choice for this control. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. bot.crawler_policies.ads standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.other standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.search compatible “compatible” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.crawler_policies.training standard “standard” is the exact shipped value in the current version. It is preserved as the baseline because the plugin code defines it as the default rather than deriving it from the old FAQ text. Keep the shipped value unless a documented site requirement calls for a different mode or identifier. Validate the change in the feature’s logs/status view and roll back if behavior becomes less reliable. bot.seo_crawler_compatibility ON / true Enabled in the shipped baseline because the control provides broadly useful visibility, validation, compatibility, or protection without requiring a site-specific value. ON activates the behavior; OFF removes that specific behavior. Use OFF only when the control is intentionally unnecessary, another trusted layer owns the function, or a compatibility investigation proves the control is involved. Re-enable after testing when protection is still required. 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, abuse, agent, allow, automation, bot, control, crawler, ddos, events, limit, logging, matched, max, maximum 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.

Archives: FAQs | Aegisify - WordPress Tools, Security…

Categories: AegisWAF
When should administrators use Enable REST API protection layer (REST inspection enforcement) in Aegisify WAF?
read more
Categories: AegisWAF
When should administrators use Enable WordPress protection layer (master switch) in Aegisify WAF?
read more
Categories: AegisWAF
How does Bot analytics charts (24h trend, 7d trend, radar, UA, etc.) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How should MaxMind MMDB path setting (framework for provider usage) be configured in Aegisify WAF, and what is the current default?
read more
Categories: AegisWAF
How does Geo/ASN provider framework (hook/provider selection support) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does ASN blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does Country blocking enforcement (PRO-only; requires provider) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How does IP / CIDR blocklist enforcement (PRO-only) work in Aegisify WAF, and what should administrators verify?
read more
Categories: AegisWAF
How should Behavioral scoring (PRO-only scoring + threshold enforcement) be configured in Aegisify WAF, and what is the current default?
read more
Categories: AegisWAF
How does Bot Control logging (allow + rate_limit events with matched pattern and scope) work in Aegisify WAF, and what should administrators verify?
read more

What’s New At Aegisify