Aegisify WAF — Web Application Firewall

WordPress Web Application Firewall: Inspect, Tune, and Enforce Before Normal Application Handling

Aegisify WAF 1.20.13 operates early inside the WordPress/PHP request lifecycle. It combines request-integrity checks, normalization, managed attack signatures, heuristics, custom rules, endpoint policies, abuse correlation, and controlled enforcement so suspicious traffic can be reviewed before stronger blocking is enabled.

A firewall should not turn every suspicious string into a block.
Good application-layer defense separates high-confidence violations from context that still needs tuning, then gives administrators a controlled path from observation to enforcement.

1InspectNormalize + classify

2DecideRules + evidence

3EnforceLog, challenge, limit, block

Request Decision Flow

How Aegisify WAF Turns a WordPress Request Into a Security Decision

The current engine uses separate protection layers rather than one giant regular-expression gate. Open each stage to see where evidence is created and where administrator policy controls the outcome.

Click a stage to expand

01IntegrityMalformed request checks

The request-integrity layer can detect malformed percent encoding, null bytes, dangerous HTTP methods, invalid or folded headers, conflicting message framing, excessive header counts, oversized request targets, and executable upload names.

02NormalizeBounded request zones

Where enabled, Aegisify normalizes bounded request data before managed signatures and heuristics run. Path, query, headers, cookies, body, and upload names remain distinct inspection zones so unrelated fields are not accidentally combined into one match.

03MatchManaged + custom rules

Managed protection evaluates categories such as SQL injection, NoSQL injection, XSS, traversal, LFI/RFI, RCE, command injection, SSRF, and executable-upload patterns. Administrator custom rules and narrow endpoint policies add site-specific controls.

04ScoreHeuristics + evidence

Optional cumulative scoring and heuristic analysis can add context around suspicious encoding, metacharacters, traversal indicators, dangerous schemes, tautologies, and unusually long tokens. Heuristics default to logging because broad anomaly signals require tuning.

05ResolveAuthoritative WAF mode

The global Core WAF mode determines whether configured findings remain observational or can terminate a request. Observe and Learn are non-blocking; Challenge-first verifies browser-capable traffic where supported; Enforce applies the configured action.

06RecordLogs + recovery

Decisions are written into Aegisify WAF evidence so administrators can review affected routes, actions, sources, categories, and decision context. Protected policy changes can create rollback snapshots for recovery.

Authoritative WAF Policy

Four Modes Let Teams Separate Detection From Enforcement

Aegisify does not require administrators to jump directly from disabled protection to hard blocking.

01 — Observe

Inspect Without Terminating Requests

Core WAF findings are recorded while terminating actions are forced to log-only. This is useful when first establishing application behavior or reviewing a new rule set.

02 — Learn

Tune Before Enforcement

Learn mode also records findings without terminating the request, but frames the evidence as tuning candidates before stronger enforcement is enabled.

03 — Challenge-First

Verify Browser-Capable Traffic

Configured block or challenge findings can become browser verification where supported. REST, XML-RPC, and AJAX clients that cannot present a verified browser token receive a denial instead of a browser challenge.

04 — Enforce

Apply the Configured Action

Enforce mode permits the Core WAF to apply configured actions after inspection. This mode should follow log review, narrow exclusions, and validation of business-critical application paths.

Managed Protection

Inspect the Request Where the Attack Signal Actually Appears

Aegisify 1.20.13 separates managed inspection by request zone and gives administrators bounded tuning controls.

Signature Coverage

Common Web Attack Families

Managed rules cover SQLi, NoSQL injection, XSS, RCE, path traversal, LFI, RFI, command injection, SSRF, and executable-upload patterns. Balanced sensitivity is the recommended default; Strict adds broader signatures that should be tested before enforcement.

Inspection Zones

Headers, Cookies, Body, and Request Context

Administrators can control whether bounded headers, cookies, and request bodies enter managed inspection. The default managed body sample is 65,536 bytes. Larger limits increase PHP work and should be used only when the application requires them.

Decision Quality

Thresholds, Scoring, and Heuristics

Category thresholds can be tuned. Optional cumulative scoring can require multiple independent managed matches before its configured action. Heuristics are enabled with a log-first default so broad anomaly evidence does not automatically become a block.

Beyond Single Requests

Credential Abuse and Reconnaissance Need Correlation

Some attacks are obvious only after multiple requests are connected by time, account, source, or repeated missing-path behavior.

Credential-stuffing correlation tracks authentication failures inside a bounded window and can identify source-specific abuse patterns involving repeated failures, multiple usernames, or distributed sources. The default profile uses a 600-second observation window and can create a temporary source block when configured limits are exceeded.

Forced-browsing protection monitors repeated unique 404 probes and known sensitive paths. The default reconnaissance window is 300 seconds with a 12-unique-path threshold, while known sensitive probes can be treated more aggressively when that control is enabled.

Why this matters: a single 404 or failed login may be harmless. Repeated account failures or a sequence of sensitive-path probes can be materially different. Correlation helps reduce the need to overreact to one isolated request.

Site-Specific Control

Endpoint Policies, Custom Rules, Presets, and Non-Enforcing Tests

WordPress sites differ. Aegisify provides scoped controls so tuning can stay narrow.

Use Narrow Endpoint Policies

Per-path policies can override categories, thresholds, and configured actions for a specific WordPress path. Explicit priority determines which overlapping policy takes precedence, and inherited thresholds reduce duplicate configuration.

Create Ordered Custom Rules

Custom rules support explicit ordering and site-specific Log or Block outcomes. The implementation rejects unsafe root-wide Core WAF exclusions and highlights overlap or shadowing so one broad rule does not silently hide another.

Preview, Test, and Recover

The Policy Test runs a synthetic path, method, and payload without enforcing the proposed result. Presets can capture a pre-preset rule snapshot, JSON rule transfer is normalized and verified, and verified configuration changes can expose a rollback path under Test & Recovery.

Deployment Boundary

Use Application-Layer WAF Protection With Edge and Hosting Controls

Aegisify WAF runs inside WordPress/PHP. That is valuable for application context, but it is not the same control point as a reverse proxy, CDN, hosting firewall, or raw network filter.

1Application ContextUse Aegisify for WordPress-aware rules, endpoint behavior, authentication abuse, and request evidence.

2Edge CapacityKeep hosting or edge controls for volumetric attacks and conditions normalized before PHP receives the request.

3Observe FirstStart new or stricter controls in Observe/Learn where practical, then review logs before enforcement.

4RecoveryMaintain backups, emergency access, and tested rollback before changing security policy on revenue-critical sites.

Start With Controlled Visibility

Build a WordPress Firewall Policy You Can Review Before You Enforce

Start with the site, verify the protection layers that apply, review evidence, and tighten policy deliberately.

Get Started

Web Application Firewall FAQ

Common Questions About Aegisify WAF

Does Aegisify WAF run at the network edge?

No. It runs inside WordPress/PHP early in the application request lifecycle. A reverse proxy, CDN, hosting firewall, or network-level mitigation remains useful for raw traffic and volumetric conditions that should be stopped before PHP.

Does one managed-rule match always block?

No. The global WAF mode governs whether a configured Core WAF action may terminate the request. Observe and Learn stay log-only. Heuristic findings are designed to be tuned, and optional cumulative scoring can require broader evidence.

Can I exclude a path from inspection?

Scoped exclusions and endpoint policies are supported, but the implementation rejects unsafe global or root-wide Core WAF exclusions. Narrow exceptions are safer because they reduce the chance of creating an unprotected application area.

How should I deploy stricter rules?

Review application behavior first, test the proposed policy, use narrow path controls where needed, verify critical forms and APIs, then enable stronger enforcement with a recovery path available.

Premium WordPress Plugins