Papy3D WAF is a local application firewall that inspects PHP requests before WordPress loads. It uses auto_prepend_file, a standalone bounded runtime, declarative rules, signed A/B publication and deferred import of authenticated security events.
The plugin provides Observation, Balanced and Hardened modes. Its protections cover common web attacks and WordPress-specific probes, including SQL injection, XSS, command injection, traversal, file inclusion, sensitive-file access, malicious uploads, webshell patterns, SSRF, XXE and repeated login abuse. Administrators can review detections, create narrow exceptions, apply temporary source blocks and monitor runtime performance.
Installation of the early loader is never automatic. An administrator must review the diagnostics and explicitly start installation. The installer does not replace an unknown auto_prepend_file, validates the published runtime before activation and restores the previous compatible Papy3D loader if validation fails. Multisite runtime installation is intentionally unavailable. Mutable runtime data created by WordPress is confined to the dedicated directory below the base returned by wp_upload_dir(), under papy3d-waf/, with direct HTTP access protection; these files are non-executable JSON, DAT, LOG or text data. Because auto_prepend_file must keep working while WordPress replaces the plugin directory during an automatic update, the installer also maintains one dedicated papy3d-waf-runtime/ directory directly below the dynamically resolved WordPress content directory. That exceptional directory contains only byte-for-byte copies of the PHP runtime files shipped with this plugin, plus non-executable bootstrap metadata; it contains no remotely supplied code, generated rules, logs or visitor data. Direct HTTP access to both directories is denied and verified before activation. On supported PHP-FPM/CGI/LiteSpeed or Apache setups, the explicit installation also writes only the marked Papy3D WAF auto_prepend_file block to the site-level .user.ini or .htaccess; it never edits WordPress core files, theme files or plugin source files, and removal targets only its own files and marker.
Request values are inspected only in memory. WordPress authentication and password cookies are excluded, authorization headers are not collected, and the journal stores payload-free detection markers instead of URI queries, cookie values, request bodies, header values or uploaded-file content. IP storage can use complete addresses or irreversible IPv4 /24 and IPv6 /64 network obfuscation.
Papy3D WAF can integrate with Papy3D Security Guard through signed capability delegation. Trusted-proxy remote updates are disabled by default, require explicitly selected providers and a separate administrator opt-in for scheduled refresh; manual refresh remains an explicit administrator action. The optional Cloudflare list integration runs only when enabled or explicitly requested by an administrator. Automatic Cloudflare append is disabled by default and requires exact-IP storage, an active blocking mode, a configured account and an existing selected IP list. No telemetry, remote code or remotely executable rule is used.
See the FAQ, Privacy, External services and Changelog sections for detailed behavior, data handling and release history.
Events are stored locally. WordPress authentication and password cookies are excluded from inspection, and authorization headers are not collected. Request values are inspected only in memory: the queue and database journal store payload-free detection markers rather than URI queries, cookie values, request bodies, header values, or uploaded-file content. The queue has bounded files and the WordPress event retention period is configurable.
Administrators can retain complete IP addresses or store IPv4 as /24 networks and IPv6 as /64 networks. Switching to obfuscated logging irreversibly transforms imported historical IPs; pending authenticated events are masked in the interface and exports and are stored obfuscated at import. A local HMAC remains available for grouping and temporary blocking. JSON export can include the whole retained journal, or one exact IP only while complete-IP storage is enabled. Exports contain sensitive security data and must be protected and deleted after use.
Papy3D WAF also stores the administrator-configured “always allowed” IPv4, IPv6 or CIDR ranges locally as mandatory security configuration. This allowlist is independent of the journal IP-storage mode and is not obfuscated, because changing the configured range would make the access-control rule ineffective. The detected current source is only saved after an authorized administrator explicitly submits the first-run form.
Automatic trusted-proxy updates are disabled by default. When an administrator selects providers and separately enables automatic refresh, the server contacts only those selected providers’ published IP-list endpoints over HTTPS. The providers necessarily receive the server source IP and standard HTTPS metadata. The request user agent identifies Papy3D WAF and its version but does not include the site URL, users, content, settings, or visitor addresses. Retrieved data is validated locally and cached as last-known-good network ranges.
When an administrator configures the optional Cloudflare API integration, the account ID, selected list ID, and API token are sent only to Cloudflare over HTTPS. Manual actions remain explicit. When automatic append is separately enabled, one exact public IP and a bounded WAF comment can also be sent after the configured cumulative or burst threshold. Cumulative counters use local HMAC identities. A local synchronization registry links retained WAF identities to pending or confirmed membership of the selected Cloudflare list so the Log can display AUTO, MANUAL, EXTERNAL or pending state without querying Cloudflare for each row. Exact registry addresses are erased when obfuscated-IP mode is enabled and are not repopulated by later reconciliation. The token is stored locally with authenticated encryption, is never displayed again, and is removed with the connection data on request. Automatic submission and real reports are suspended when IP obfuscation is active.
The optional direct Cloudflare API integration uses https://api.cloudflare.com/client/v4/ and sends the account ID, selected list ID, Bearer API token and standard HTTPS metadata. Credential management, list selection, refresh, download, manual append and clearing remain administrator-triggered. If the administrator separately enables automatic append, WordPress can send one exact public IP and a bounded WAF comment after a cumulative or burst threshold; the pre-WordPress runtime never contacts Cloudflare directly. An optional daily report sends exact blocked IPs, trigger counts, reasons and outcomes through the site’s configured wp_mail() transport to administrator-selected recipients. Cloudflare privacy and terms: https://www.cloudflare.com/privacypolicy/ and https://www.cloudflare.com/policies/terms/.
Trusted-proxy remote updates are optional. The explicit refresh button contacts only providers selected by an administrator. Scheduled WP-Cron refresh is disabled by default and runs only after the administrator separately enables automatic refresh while at least one provider remains selected. The request sends no site URL, user, visitor IP, content, or plugin configuration. The selected provider receives only the server source IP, standard HTTPS metadata, and a generic plugin/version user agent. Retrieved values are locally validated as public IP addresses or CIDR ranges, bounded, cached as last-known-good data, and merged with manual entries that are never overwritten.
The following public sources can be contacted:
Sucuri ranges are bundled from its published firewall documentation, so selecting Sucuri does not contact GoDaddy or Sucuri. Documentation source: https://docs.sucuri.net/website-firewall/troubleshooting/same-ip-for-all-users/