NinjaFirewall (WP/WP+ Edition)



The Overview page shows information about the firewall status. We recommend you keep an eye on it, because in case of problems, all possible errors and warnings will be displayed here.


Monthly stats:

Statistics are taken from the current log. It is rotated on the first day of each month. You can view the log by clicking on the Firewall Log menu.


Benchmarks show the time NinjaFirewall took, in seconds, to proceed each request it has blocked.

Firewall Options

Firewall protection:

This option allows you to disable NinjaFirewall. It has basically the same effect as deactivating it from the Plugins menu page. Your site will remain unprotected until you enable it again.

Use shared memory (!! WP+ edition only !!):

This feature allows NinjaFirewall to use Unix shared memory segments in order to speed up all operations. The firewall will no longer need to connect to the database and, instead, will retrieve its options and configuration directly from memory (RAM). On a very busy server (e.g., multisite network etc), this feature can dramatically increase the processing speed from 25% to 30%, prevent blocking I/O and slow queries.

This option requires that your PHP version was compiled with the --enable-shmop parameter, otherwise, if it is not compatible with your server/hosting environment, it will be disabled.
If you are using GB2312 character set (A.K.A GBK - simplified Chinese characters) for your database, we recommend to disable that option otherwise NinjaFirewall will not have access to the database and it may not be able to properly sanitise multi-byte characters used by that charset.

Debugging mode:

In Debugging mode, NinjaFirewall will not block or sanitise suspicious requests but will only log them (the firewall log will display DEBUG_ON in the LEVEL column).

We recommend to run it in Debugging Mode for at least 24 hours after installing it on a new site and then to keep an eye on the firewall log during that time. If you notice a false positive in the log, you can simply use NinjaFirewall's Rules Editor to disable the security rule that was wrongly triggered.

Error code and message to return:

Lets you customize the HTTP error code returned by NinjaFirewall when blocking a dangerous request and the message to display to the user. You can use any HTML tags and 3 built-in variables:

    %%REM_ADDRESS%% : the blocked user IP.

    %%NUM_INCIDENT%% : the unique incident number as it will appear in the firewall log "INCIDENT" column.

    %%NINJA_LOGO%% : NinjaFirewall logo.

Export/import configuration:

This options lets you export you current configuration or import it from another NinjaFirewall (WP edition) installation. The imported file must match your current version otherwise it will be rejected.
Note that importing will override all firewall rules, options and configuration, except your WP+ edition license.

Firewall Policies

Policies overview:

Because NinjaFirewall sits in front of WordPress, it can hook, scan and sanitise all PHP requests, HTTP variables, headers and IPs before they reach your blog: $_GET, $_POST, $_COOKIES, $_REQUEST, $_FILES, $_SERVER in either or both HTTP & HTTPS mode.
Use the options below to enable, disable or to tweak these rules according to your needs.
Keep in mind, however, that the Firewall Policies apply to any PHP scripts located inside your WordPress directory and its sub-directories, and not only to your index page.

Scan & Sanitise:

You can choose to scan and reject dangerous content but also to sanitise requests and variables. Those 2 actions are different and can be combined together for better security.

    Scan: if anything suspicious is detected, NinjaFirewall will block the request and return an HTTP error code and message. The user request will fail and the connection will be closed immediately.

    Sanitise: this option will not block but sanitise the user request by escaping characters that can be used to exploit vulnerabilities (', ", \, \n, \r, `, \x1a, \x00) and replacing < and > with their corresponding HTML entities (&lt;, &gt;). If it is a variable, i.e. ?name=value, both its name and value will be sanitised.
    This action will be performed when the filtering process is over, right before NinjaFirewall forwards the request to your PHP script.

    If you enabled POST requests sanitising, articles and messages posted by your visitors could be corrupted with excessive backslashes or substitute characters.


Whether to filter HTTP and/or HTTPS traffic.


    File Uploads: you can allow/disallow uploads or allow uploads but block scripts* (PHP, CGI, Ruby, Python, bash/shell, C/C++ source code), ELF* (Unix/Linux binary files) and system files* (.htaccess, .htpasswd and PHP INI).

    Sanitise filenames: any character that is not a letter a-zA-Z, a digit 0-9, a dot ., a hyphen - or an underscore _ will be removed from the filename and replaced with the X character.

    Maximum allowed file size:* if you allow uploads, you can select the maximum size of an uploaded file. Any file bigger than this value will be rejected. Note that if your PHP configuration uses the upload_max_filesize directive, it will be used before NinjaFirewall.

* !! WP+ edition only !!

HTTP GET variable:

Whether to scan and/or sanitise the GET variable.

HTTP POST variable:

    Whether to scan and/or sanitise the POST variable.

    Decode base64-encoded POST variable: NinjaFirewall will decode and scan base64 encoded values in order to detect obfuscated malicious code. This option is only available for the POST variable.

HTTP REQUEST variable:

Whether to sanitise the REQUEST variable.


Whether to scan and/or sanitise cookies.

HTTP_USER_AGENT server variable:

Whether to scan and/or sanitise HTTP_USER_AGENT requests.

HTTP_REFERER server variable:

    Whether to scan and/or sanitise HTTP_REFERER requests.

    Block POST requests that do not have an HTTP_REFERER header: this option will block any POST request that does not have a Referrer header (HTTP_REFERER variable). If you need external applications to post to your scripts (e.g. Paypal IPN, WordPress WP-Cron etc), you are advised to keep this option disabled otherwise they will likely be blocked. Note that POST requests are not required to have a Referrer header and, for that reason, this option is disabled by default.

HTTP response headers:

In addition to filtering incoming requests, NinjaFirewall can also hook the HTTP response in order to alter its headers. Those modifications can help to mitigate threats such as XSS, phishing and clickjacking attacks.

    Set X-Content-Type-Options to protect against MIME type confusion attacks: sending this response header with the nosniff value will prevent compatible browsers from MIME-sniffing a response away from the declared content-type.

    Set X-Frame-Options to protect against clickjacking attempts: this header indicates a policy whether a browser must not allow to render a page in a <frame> or <iframe>. Hosts can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, by ensuring that their content is not embedded into other pages or frames. NinjaFirewall accepts two different values:

    • SAMEORIGIN: a browser receiving content with this header must not display this content in any frame from a page of different origin than the content itself.
    • DENY: a browser receiving content with this header must not display this content in any frame.

    Enfore X-XSS-Protection (IE, Chrome and Safari browsers): this header allows compatible browsers to identify and block XSS attack by preventing the malicious script from executing. NinjaFirewall will set its value to 1; mode=block.

    Force HttpOnly flag on all cookies to mitigate XSS attacks: adding this flag to cookies helps to mitigate the risk of cross-site scripting by preventing them from being accessed through client-side script. NinjaFirewall can hook all cookies sent by your blog, its plugins or any other PHP script, add the HttpOnly flag if it is missing, and re-inject those cookies back into your server HTTP response headers right before they are sent to your visitors. Note that WordPress sets that flag on the logged in user cookies only.

    Set Strict-Transport-Security (HSTS) to enforce secure connections to the server: this policy enforces secure HTTPS connections to the server. Web browsers will not allow the user to access the web application over insecure HTTP protocol. It helps to defend against cookie hijacking and Man-in-the-middle attacks. Most recent browsers support HSTS headers.

    Set Content-Security-Policy: this policy helps to mitigate threats such as XSS, phishing and clickjacking attacks. It covers JavaScript, CSS, HTML frames, web workers, fonts, images, objects (Java, ActiveX, audio and video files), and other HTML5 features. NinjaFirewall lets you configure the CSP policy separately for the frontend (blog, website) and the backend (WordPress admin dashboard).

IP (WP edition only):

    Block localhost IP in GET/POST requests: this option will block any GET or POST request containing the localhost IP ( It can be useful to block SQL dumpers and various hacker's shell scripts.

    Block HTTP requests with an IP in the HTTP_HOST header: this option will reject any request using an IP instead of a domain name in the Host header of the HTTP request. Unless you need to connect to your site using its IP address, (e.g., enabling this option will block a lot of hackers scanners because such applications scan IPs rather than domain names.

    Scan traffic coming from localhost and private IP address spaces: this option will allow the firewall to scan traffic from all non-routable private IPs (IPv4 and IPv6) as well as the localhost IP. We recommend to keep it enabled if you have a private network (2 or more servers interconnected).


    Block PHP built-in wrappers: PHP has several wrappers for use with the filesystem functions. It is possible for an attacker to use them to bypass firewalls and various IDS to exploit remote and local file inclusions. This option lets you block wrappers found inside a GET or POST request, cookies, user agent and referrer variables.

    Block serialized PHP objects: Object Serialization is a PHP feature used by many applications to generate a storable representation of a value. However, some insecure PHP applications and plugins can turn that feature into a critical vulnerability called PHP Object Injection. When this option is enabled, NinjaFirewall will block serialized PHP objects found in GET, POST, COOKIE, HTTP_USER_AGENT and HTTP_REFERER. By default, it is disabled.

    Hide PHP notice & error messages: this option lets you hide errors returned by your scripts. Such errors can leak sensitive informations which can be exploited by hackers.

    Sanitise PHP_SELF, PATH_TRANSLATED, PATH_INFO: this option can sanitise any dangerous characters found in those 3 server variables to prevent various XSS and database injection attempts.


    Block the DOCUMENT_ROOT server variable in HTTP requests: this option will block scripts attempting to pass the DOCUMENT_ROOT server variable in a GET or POST request. Hackers use shell scripts that often need to pass this value, but most legitimate programs do not.

    Block ASCII character 0x00 (NULL byte): this option will reject any GET or POST request, COOKIE, HTTP_USER_AGENT, REQUEST_URI, PHP_SELF, PATH_INFO variables containing the ASCII character 0x00 (NULL byte). Such a character is dangerous and should always be rejected.

    Block ASCII control characters 1 to 8 and 14 to 31: in most cases, those control characters are not needed.

    Block localhost IP in GET/POST requests : this option will block any GET or POST request containing the localhost IP ( It can be useful to block SQL dumpers and various hacker's shell scripts.

    Block HTTP requests with an IP in the HTTP_HOST header: this option will reject any request using an IP instead of a domain name in the Host header of the HTTP request. Unless you need to connect to your site using its IP address, (e.g., enabling this option will block a lot of hackers scanners because such applications scan IPs rather than domain names.


    Whether to block direct access to PHP files located in specific WordPress directories.

    Protect against username enumeration: it is possible to enumerate usernames either through the WordPress author archives, the REST API or the login page. Although this is not a vulnerability but a WordPress feature, some hackers use it to retrieve usernames in order to launch more accurate brute-force attacks. If it is a failed login attempt, NinjaFirewall will sanitise the error message returned by WordPress. If it is an author archives scan, it will invalidate it and redirect the user to the blog index page. Regarding the WP REST API, it will block the request immediately.

    WordPress REST API: it allows you to access your WordPress site's data through an easy-to-use HTTP REST API. Since WordPress 4.7, it is enabled by default. NinjaFirewall allows you to block any access to that API if you do not intend to use it.

    WordPress XML-RPC API: XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. WordPress has an XMLRPC API that can be accessed through the xmlrpc.php file. Since WordPress version 3.5, it is always activated and cannot be turned off. NinjaFirewall allows you to immediately block any access to that file, or only to block an access using the system.multicall method (often used in brute-force amplification attacks). If you are using applications that need to access that API such as the JetPack plugin or the WordPress Androis/iOS app, enable only the system.multicall protection otherwise your application will be blocked.

    Block POST requests in the themes folder /wp-content/themes: this option can be useful to block hackers from installing backdoor in the PHP theme files. However, because some custom themes may include an HTML form (contact or search form etc), this option is not enabled by default.

    Force SSL for admin and logins FORCE_SSL_ADMIN: enable this option when you want to secure logins and the admin area so that both passwords and cookies are never sent in the clear. Warning: ensure that you can access your admin console from HTTPS before enabling this option, otherwise you will lock yourself out of your site !

    Disable the plugin and theme editor DISALLOW_FILE_EDIT: disabling the plugin and theme editor provides an additional layer of security if a hacker gains access to a well-privileged user account.

    Disable plugin and theme update/installation DISALLOW_FILE_MODS: this option will block users being able to use the plugin and theme installation/update functionality from the WordPress admin area. Setting this constant also disables the Plugin and Theme editor.

Access Control (!! WP+ edition only !!)

Access Control is a powerful set of directives that can be used to allow or restrict access to your website based on many criteria.
To make better use of them, it is important to understand NinjaFirewall's directives processing order:

    Incoming HTTP request:

    1. .htninja file.
    2. Login Protection.
    3. Access Control :
      1. Role-based Access Control.
      2. Allowed IPs.
      3. Allowed URLs.
      4. Blocked IPs.
      5. Blocked URLs.
      6. Bot Access Control.
      7. Geolocation.
      8. Rate Limiting.
    4. File Guard.
    5. NinjaFirewall built-in rules & policies.

    Response body:

    1. HTTP response headers.
    2. Web Filter.

Role-based Access Control:

By default, any logged in Administrator will not be blocked by NinjaFirewall. This applies to all Access Control directives listed below, as well as the Antispam, the Web Filter and the Firewall Policies, except FORCE_SSL_ADMIN, DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS and the Login Protection options which, if enabled, will always be enforced.
You can also add other users to the whitelist, depending on their role.

Source IP:

    IP-based access control directives should use: this option should be used if you are behind a reverse proxy, a load balancer or using a CDN, in order to tell NinjaFirewall which IP it should use. By default, it will rely on REMOTE_ADDR. If you want it to use HTTP_X_FORWARDED_FOR or any other similar variable, it is absolutely necessary to ensure that it is reliable (i.e., setup by your own load balancer/reverse proxy) because it can be easily spoofed. If that variable includes more than one IP, only the left-most (the original client) will be checked. If it does not include any IP, NinjaFirewall will fall back to REMOTE_ADDR.

    Scan traffic coming from localhost and private IP address spaces: this option will allow the firewall to scan traffic from all non-routable private IPs (IPv4 and IPv6) as well as the localhost IP. We recommend to keep it enabled if you have a private network (2 or more servers interconnected).

HTTP Methods:

This option lets you select the HTTP method(s). All Access Control directives (Geolocation, IPs, bots and URLs) will only apply to the selected methods.
It does not apply to the Firewall Policies options, which use their own ones.

Geolocation Access Control:

You can filter and block traffic coming from specific countries.

     Retrieve ISO 3166 country code from: this is the two-letter country code that is used to define a country (e.g., US, UK, FR, DE etc), based on the visitors IP. NinjaFirewall can either retrieve it from its database, or from a predefined PHP variable added by your HTTP server (e.g., GEOIP_COUNTRY_CODE).

     Block visitors from the following countries: you can add/remove any country from the two listboxes. For more information about some specific ISO 3166 codes (A1, A2, AP, EU etc), you may want to consult the MaxMind GeoIP online help. By default, no country is blocked.

     Geolocation should apply to the whole site or specific URLs only: whether geolocation should apply to the whole site or to specific URLs only (e.g., /wp-login.php, /xmlrpc.php etc). Leave all fields empty if you want it to apply to the whole site.

     Append NINJA_COUNTRY_CODE to PHP headers: after retrieving the two-letter country code, NinjaFirewall can add it to the PHP headers in the $_SERVER["NINJA_COUNTRY_CODE"] variable. If you have a theme or a plugin that needs to know your visitors location, simply use that variable.

    If NinjaFirewall cannot find the two-letter country code, it will replace it with 2 hyphens (--).

    PHP code example to use in your theme or plugin to geolocate your visitors :

    NinjaFirewall includes GeoLite data created by MaxMind

IP / URL / Bot Access Control:

     IP Access Control: you can permanently allow/block an IP or a part of it. IPv4 and IPv6 are fully supported by NinjaFirewall.
    You must at least enter the first 3 characters of an IP:

    • Full IPv4 : will only match IP

    • Partial IPv4:
      • 1.2.3. will match any IP address starting with 1.2.3. (from to, but will not match

      • 1.2.3 will match any IP address starting with 1.2.3 (from to, and also etc), but will not match

    The same rules apply to IPv6 addresses. Subnets notation (e.g, are not supported.

     Rate Limiting : this option allows you to slow down aggressive bots, crawlers, web scrapers or even small HTTP attacks. Any IP reaching the defined threshold will be banned from 1 to 999 seconds. Note that the purpose of this feature is not to permanently block an IP but rather to temporarily prevent it from accessing the site and abusing your system resources. If you want to permanently block an IP, use the blacklist instead. Also, do not rely on this option to block brute force attacks on the login page, use the more suitable Login Protection for that purpose. By default, Rate Limiting is turned off.

    IPs temporarily banned by the Rate Limiting option can be unblocked immediately by clicking either the "Save Access Control Directives" or "Restore Default Values" buttons.
    Because NinjaFirewall can handle thousands of HTTP requests per second and block IPs even before your blog is loaded, we strongly recommend that you disable the rate limiting/throttling option of any other WordPress plugin that you may have installed and only use NinjaFirewall's one instead. It will drastically speed up your site and reduce the server load on a busy site or during an attack.

     URL Access Control: you can block any access to one or more PHP scripts based on their path, relative to the web root (SCRIPT_NAME). You can enter either a full or partial path (case-sensitive).

    • /foo/bar.php will block any access to the bar.php script located inside a /foo/ directory or sub-directory.

    • /foo/ will block access to all PHP scripts located inside a /foo/ directory.

    Note that the Firewall Policies page already includes restrictions to some WordPress directories.

     Bot Access Control: you can block bots, scanners and various crawlers based on the HTTP_USER_AGENT variable. You can enter either a full or partial name (case-insensitive).

Log Event:

You can enable/disable firewall logging for each access control directive separately. All but the "Allow the following IPs" directive have this option enabled by default.

File Guard

File Guard can detect, in real-time, any access to a PHP file that was recently modified or created, and alert you about this.
If a hacker uploaded a shell script to your site (or injected a backdoor into an already existing file) and tried to directly access that file using his browser or a script, NinjaFirewall would hook the HTTP request and immediately detect that the file was recently modified/created. It would send you a detailed alert (script name, IP, request, date and time). Alerts will be sent to the contact email address defined in the Event Notifications menu.

Modifications detected by NinjaFirewall include mtime (saved or updated content of a file) and ctime (inode change, e.g., permissions, ownership etc).

If you do not want to monitor a folder, you can exclude its full path or a part of it (e.g., /var/www/public_html/cache/ or /cache/ etc). NinjaFirewall will compare this value to the $_SERVER["SCRIPT_FILENAME"] server variable and, if it matches, will ignore it.

File Guard real-time detection is a totally unique feature, because NinjaFirewall is the only plugin for WordPress that can hook HTTP requests sent to any PHP script, even if that script is not part of the WordPress package (third-party software, shell script, backdoor etc).

File Check

File Check lets you perform file integrity monitoring upon request or on a specific interval (hourly, twicedaily, daily).
You need to create a snapshot of all your files and then, at a later time, you can scan your system to compare it with the previous snapshot. Any modification will be immediately detected: file content, file permissions, file ownership, timestamp (ctime and mtime) as well as file creation and deletion.

Create a snapshot of all files stored in that directory:

By default, the directory is set to WordPress ABSPATH.

Exclude the following files/folders:

You can enter a directory or a file name (e.g., /foo/bar/), or a part of it (e.g., foo). Or you can use an extension (e.g., .css).
Multiple value must be comma-separated (e.g., /foo/bar/,.css,.png).

Do not follow symbolic links:

By default, NinjaFirewall will not follow symbolic links.


The NinjaFirewall Anti-Malware feature lets you scan your website for malware. It is important to note that its main goal is not to detect a hidden iframe redirecting to a porn site, but applications that could harm the site or even the server such as backdoors or shell scripts. It can also scan and detect dangerous Linux binary files (trojan, IRC bot etc).

The scanning engine is compatible with the popular Linux Malware Detect (LMD), whose anti-malware signatures are included with this release. Linux Malware Detect is a malware scanner for Linux released under the GNU GPLv2 license, that is "designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources."

The Anti-Malware engine is also compatible with some ClamAV signatures and it is possible to create and include your own ones. See our blog for more info about this.

Web Filter (!! WP+ edition only !!)

If NinjaFirewall can hook and scan incoming requests, it can also hook the response body (i.e., the output of the HTML page right before it is sent to your visitors browser) and search it for some specific keywords. Such a filter can be useful to detect hacking or malware patterns injected into your HTML code (text strings, spam links, malicious JavaScript code), hackers shell script, redirections and even errors (PHP/MySQL errors). Some suggested keywords as well as a default list are included.
In the case of a positive detection, NinjaFirewall will not block the response body but will send you an alert by email.

Search HTML page for keywords:

You can enter any keyword from 4 to 150 characters and select whether the search will be case sensitive or not.

Email Alerts:

You can use the notification throttling option to limit the frequency of alerts sent to you (and written to the firewall log) and select whether you want NinjaFirewall to send you the whole HTML source of the page where the keyword was found. Alerts will be sent to the contact email address defined in the Event Notifications menu.

Response body filtering can be resource-intensive. Try to limit the number of keywords to what you really need (<10) and/or, if possible, prefer case sensitive to case insensitive filtering.

Network (multi-site only)

Even if NinjaFirewall administration menu is only available to the Super Admin (from the main site), you can still display its status to all sites in the network by adding a small NinjaFirewall icon to their admin bar. It will be visible only to the administrators of those sites.
It is recommended to enable this feature as it is the only way to know whether the sites in your network are protected and if NinjaFirewall installation was successful.
Note that when it is disabled, the icon still remains visible to the Super Admin.

Event Notifications

NinjaFirewall can alert you by email on specific events triggered within your blog. They include installations, updates, activations etc, as well as users login and modification of any administrator account in the database. Some of those alerts are enabled by default and it is highly recommended to keep them enabled. It is not unusual for a hacker, after breaking into your WordPress admin console, to install or just to upload a backdoored plugin or theme in order to take full control of your website.

Login Protection

By processing incoming HTTP requests before your blog and any of its plugins, NinjaFirewall is the only plugin for WordPress able to protect it against very large brute-force attacks, including distributed attacks coming from several thousands of different IPs.
The protection applies to the wp-login.php script and can also include the xmlrpc.php one.

You can select to enable the protection only if an attack is detected or to keep it always activated.

Yes, if under attack:

When too many login attempts are detected, it password-protects the login page immediately, regardless of the offending IP. It blocks the attack instantly and prevents it from reaching WordPress, but still allows you to access your administration console using a predefined username/password combination. NinjaFirewall uses its own very fast authentication scheme and it is compatible with any HTTP server (Apache, Nginx, Lighttpd etc).

     Protect the login page against: select the type of requests (GET and/or POST) to monitor.

     Password-protect the login page: enter the suitable threshold that will trigger the protection.

     HTTP authentication: enter the user name and password that you want to use to bypass the protection during an attack.

     Message: enter the message to display during the authentication process.

Always ON:

NinjaFirewall will always enforce HTTP authentication implementation and you will be prompted to enter your choosen username/password each time you will access the login page.

     HTTP authentication: enter the user name and password that you want to use to access the login page.

     Message: enter the message to display during the authentication process.

AUTH log:

NinjaFirewall can write to the server AUTH log when the brute-force protection is triggered. This can be useful to the system administrator for monitoring purposes or banning IPs at the server level.
If you have a shared hosting account, keep this option disabled as you do not have any access to the server's logs.
On Debian-based systems, the log is located in /var/log/auth.log, and on Red Hat-based systems in /var/log/secure. The logline uses the following format:

ninjafirewall[AA]: Possible brute-force attack from BB on CC (DD). Blocking access for EEmn.

    AA: the process ID (PID).

    BB: the offending IPv4 or IPv6 IP address.

    CC: the blog (sub-)domain name.

    DD: the target: it can be either wp-login.php or XML-RPC API.

    EE: the time, in minutes, the protection will remain active.

Sample loglines:
Be careful if you are behind a load balancer, reverse-proxy or CDN because NinjaFirewall will always record the REMOTE_ADDR IP. If you have an application parsing the AUTH log in order to ban IPs (e.g. Fail2ban), you must setup your HTTP server to forward the correct IP (or use the .htninja file), otherwise you will likely block legitimate users.

Antispam (!! WP+ edition only !!)

NinjaFirewall can protect your blog against spam without user interaction (e.g., CAPTCHA, math puzzles etc). The protection is totally transparent to your visitors.

Protection level:

Select the level of protection. In most cases, Low should be enough for most site.

Apply protection to:

Whether to protect comment and/or registration forms.

NinjaFirewall antispam feature works only with WordPress built-in comment and registration forms. If you are using third-party plugins to generate your forms, they will not be protected against spam.

Firewall Log

Firewall Log:

The firewall log displays blocked and sanitised requests as well as some useful information. It has 6 columns:

    DATE : date and time of the incident.

    INCIDENT : unique incident number/ID as it was displayed to the blocked user.

    LEVEL : level of severity (critical, high or medium), information (info, upload) and debugging mode (DEBUG_ON).

    RULE : reference of the NinjaFirewall built-in security rule that triggered the action. A hyphen (-) instead of a number means it was a rule from your own Firewall Policies or Access Control page.

    IP : the blocked user remote address.

    REQUEST : the HTTP request including offending variables & values as well as the reason the action was logged.


Allows you to export the log as a TSV (tab-separated values) text file.


Allows you to delete the currently viewed log.

Enable firewall log:*

You can disable/enable the firewall log from this menu.

Brute-force attacks will still be written to the firewall log, even if you disable it.

Auto-rotate log:*

NinjaFirewall will rotate its log automatically on the very first day of each month. If your site is very busy, you may want to allow it to rotate the log when it reaches a certain size (MB) as well.
By default, if will rotate the log each month or earlier, if it reaches 2 megabytes.
Rotated logs, if any, can be selected and viewed from the dropdown menu.

* !! WP+ edition only !!

Centralized Logging (!! WP+ edition only !!)

Centralized Logging lets you remotely access the firewall log of all your NinjaFirewall protected websites from one single installation. You do not need any longer to log in to individual servers to analyse your log data. There is no limit to the number of websites you can connect to, and they can be running any edition of NinjaFirewall: WP, WP+, Pro or Pro+.

Secret key:

The secret key will be used to generate your public key. Enter at least 30 ASCII characters, or use the one randomly created by NinjaFirewall.

This server's IP address:

As an additional protection layer, you can restrict access to the remote website(s) to the main server's IP only. You can use IPv4 or IPv6. If you do not want any IP restriction, enter the * character instead.

Public key:

This is the public key that you will need to upload to each remote website (consult our blog for more info about it).

Remote websites URL:

Enter the full URL of your NinjaFirewall protected website(s) that you want to remotely access from the main server.

Centralized Logging will keep working even if NinjaFirewall is disabled. Use the "Centralized Logging" menu if you want to disable it.

Live Log

Live Log:

Live Log lets you watch your website traffic in real time. It displays connections in a format similar to the one used by most HTTP server logs. Note that requests sent to static elements like JS/CSS files and images are not managed by NinjaFirewall.

You can enable/disable the monitoring process, change the refresh rate, clear the screen, enable automatic vertical scrolling and change the log format.

Live Log does not make use of any WordPress core file (e.g., admin-ajax.php). It communicates directly with the firewall without loading WordPress bootstrap. Consequently, it is fast, light and it should not affect your server load, even if you set its refresh rate to the lowest value (5 seconds).

If you are using the optional .htninja configuration file to whitelist your IP, the Live Log feature will not work.

Rules Editor

Besides the Firewall Policies, NinjaFirewall includes also a large set of built-in rules used to protect your blog against the most common vulnerabilities and hacking attempts. They are always enabled and you cannot edit them, but if you notice that your visitors are wrongly blocked by some of those rules, you can use the Rules Editor below to disable them individually.

    Check your firewall log and find the rule ID you want to disable (it is displayed in the RULE column).

    Select its ID from the enabled rules list below and click the "Disable it" button.

Note: if the RULE column from your log shows a hyphen - instead of a number, that means that the rule can be changed in your Firewall Policies page.


To get the most efficient protection, you can ask NinjaFirewall to automatically update its security rules. It can check for updates hourly, twice daily or daily.
Each time a new vulnerability is found in WordPress or one of its plugins/themes, a new set of security rules will be made immediately available to protect against such vulnerability.
Only security rules will be downloaded. If a new version of NinjaFirewall (including new files, options and features) was available, it would have to be updated from the dashboard plugins menu as usual.

We recommend to enable this feature, as it is the only way to keep your WordPress secure against new vulnerabilities.