Security Pilot

Security Pilot is a comprehensive WordPress security plugin that hardens your site against common attacks and vulnerabilities. It applies industry-standard HTTP security headers, protects the login page from brute-force attacks, blocks malicious requests with a built-in firewall, restricts sensitive REST API endpoints, and ships a one-click audit that grades the installation from A to F.

Unlike bloated security suites, Security Pilot is lightweight and modular: enable only the protections you need. Every module can be toggled independently, and all settings are managed from the Security Pilot top-level menu in the WordPress admin sidebar.

Security Pilot — Settings page with every module on a single, scrollable form.

Highlights

HTTP security headers — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection and removal of the X-Powered-By header.
Login protection — configurable rate limiting, temporary lockouts and permanent bans for repeat offenders, with optional email alerts.
Request firewall — pattern-based detection of SQL injection, cross-site scripting (XSS), path traversal, remote file inclusion (RFI) and command injection.
REST API protection — block unauthorized access to sensitive endpoint groups such as /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder and Elementor.
WordPress hardening — disable the file editor and XML-RPC, suppress pingbacks and trackbacks, hide the WordPress version, remove the RSD link and the Windows Live Writer manifest.
Rate limiter — per-IP throttling for 404 floods and other high-frequency request patterns, with a configurable max-block count and rolling time window.
Form protection — rate limits front-end submissions, blocks disposable email domains, and traps bots with hidden honeypot fields and a configurable time-to-fill check.
Security Check — one-click audit that grades the installation from A to F and reports per-check status (PASS / WARNING / FAIL) on hardening, REST API exposure, outdated plugins/themes, debug settings, file editor and many more.
Access Rules & attack logging — manage Blocked IPs, Whitelisted IPs and Whitelisted URLs from a three-tab screen, and drill into every blocked request in the Attack Log.

Requirements

Security Pilot is designed for modern, self-hosted WordPress sites.

A working WordPress installation with administrator access.
A PHP version supported by your current WordPress release.
HTTPS is strongly recommended. The HSTS header should only be enabled when your site is reachable over TLS on every URL, including subdomains you want covered.
Sufficient permission to modify HTTP response headers. On most managed hosts this works out of the box; in front of some reverse proxies or CDNs the headers may need to be allowed through at the edge.

There are no external services to configure and no API keys are required. Settings, logs and blocklists are stored in your own WordPress database.

Installation

Download the Security Pilot plugin ZIP.
In WordPress, open Plugins → Add New → Upload Plugin.
Choose the ZIP file and select Install Now.
Click Activate Plugin when the upload completes.
Open Security Pilot → Settings to review the modules. The four submenu items, in the order they appear, are Security Check, Access Rules, Attack Log and Settings.

After activation, no protection is forcibly enabled — every module starts in a known state and can be toggled individually. This makes it safe to install on a production site and to introduce hardening in small, reversible steps.

Configuration

All configuration is performed from Security Pilot → Settings. The page groups settings into modules — each module is a collapsible card with its own enable toggle and a small number of options.

A License card at the top accepts a PILOT-XXXX-XXXX-XXXX-XXXX key (from your order confirmation) and enables automatic plugin updates from the GitHub release feed when verified. The plugin works fully without a key; only the auto-update channel is gated.

HTTP Security Headers

The headers module adds standards-based HTTP response headers to every request served through WordPress. Toggle individual headers on or off according to your site’s needs.

Header	Default value	Purpose
`X-Frame-Options`	`SAMEORIGIN`	Prevents clickjacking by blocking the page from being embedded in third-party frames.
`X-Content-Type-Options`	`nosniff`	Stops browsers from guessing content types, mitigating MIME-confusion attacks.
`X-XSS-Protection`	`1; mode=block`	Legacy XSS filter for older browsers.
`Strict-Transport-Security`	enabled with sensible defaults	Forces browsers to use HTTPS for future visits. Enable only when the site is fully HTTPS.
`Referrer-Policy`	`strict-origin-when-cross-origin`	Limits the referrer information leaked to third parties.
`Permissions-Policy`	restrictive defaults	Disables sensitive browser features (camera, microphone, geolocation, etc.) that the site does not use.
`Content-Security-Policy`	configurable	Restricts the origins from which scripts, styles, images and other resources may load.
`X-Powered-By`	removed	Hides the `X-Powered-By` value generated by PHP or other components that would otherwise advertise your server stack.

A few notes when configuring headers:

HSTS is permanent in browsers once received. Verify HTTPS works everywhere — including www and any subdomains you plan to include — before enabling it.
The Content-Security-Policy is the most powerful and the most intrusive header. Start with the report-friendly defaults, then tighten the policy after checking the browser console for blocked resources on your real pages.
If your site sits behind a CDN or reverse proxy that rewrites headers, make sure those edges pass the values added by Security Pilot through unchanged.

Login Protection counts failed authentication attempts per IP address and applies a lockout when a threshold is reached. After a configurable number of lockouts, the IP can be permanently banned.

Available settings:

Max failed attempts — number of failed logins from an IP before a lockout is triggered. Accepts values from 1 to 20. The default of 5 is a sensible starting point.
Attempt window — the rolling time window, in minutes, used to count failures. Accepts values from 1 to 120.
Lockout duration — how long a locked-out IP stays blocked, in minutes. Accepts values from 1 to 1440 (24 hours).
Permanent ban threshold — number of separate lockouts an IP can accumulate before it is banned permanently. Accepts values from 1 to 20.
Email alerts — when enabled, the site administrator receives an email each time an attack is detected and each time an IP is added to the blocklist.
Hide detailed error messages — generic error messages (“invalid credentials”) replace WordPress’s default messages, preventing attackers from learning whether a username exists.

The protection applies to both wp-login.php and the standard XML-RPC authentication endpoint when XML-RPC remains enabled.

Request Firewall

The Request Firewall inspects incoming requests for malicious patterns and returns a 403 Forbidden response when one is found. The detection patterns are built in and cover:

SQL injection — common payloads against query parameters, POST bodies and cookies.
Cross-site scripting (XSS) — reflected and stored attack signatures.
Path traversal — ../ style attempts to escape the document root.
Remote file inclusion (RFI) — references to external URLs in contexts where local paths are expected.
Command injection — shell metacharacters in parameters that are likely to reach system-style functions.

The firewall has no per-rule configuration. It is either enabled or disabled. Blocked requests are recorded in the attack log described below, including the offending parameter and the rule that triggered the block.

Rate Limiter (404 Flood Protection)

Sites under brute-force probing churn through hundreds of 404 responses per IP per minute, looking for hidden plugin assets or wp-config backups. The Rate Limiter caps that traffic per source IP by tracking 404 hits in a rolling window:

Field	Default	Notes
Max 404 responses before block	`25`	Once exceeded, the IP is added to the Blocked IPs list.
Time window (seconds)	`60`	Rolling window over which the counter is evaluated.

The block is enforced by the same mechanism used by Login Protection, so it shows up in the Access Rules → Blocked IPs tab with reason 404_flood.

REST API Protection

WordPress exposes a large REST API by default, including endpoints that are useful for site builders but often unnecessary on a production site. Security Pilot can block unauthenticated access to entire endpoint groups while leaving the rest of the API intact.

Protected groups:

/wp/v2/users — user enumeration via the core users endpoint.
WooCommerce — store, order and customer endpoints exposed by WooCommerce when installed.
Jetpack — Jetpack’s own REST namespace.
wp-site-health — health-check endpoints that may leak information about the environment.
Divi Builder — Divi’s REST endpoints.
Elementor — Elementor’s REST endpoints.

Enable protection only for the groups you do not need. For example, a site that does not run WooCommerce can safely lock down the WooCommerce endpoints. The plugin checks authentication on each request and returns an authorization error for unauthenticated callers attempting to access a protected group.

Form Protection

Protects contact / comment / login forms across the site from spam, disposable email signups and high-velocity bot submissions:

Field	Default	Notes
Max submissions per IP within cooldown	`1`	Hard cap per IP in the cooldown window.
IP cooldown window (minutes)	`30`	How long the per-IP rate gate stays closed after a submission.
Max total form emails per hour (global)	`15`	Site-wide ceiling on emailed form submissions per hour.
Blocked email TLDs	comma-separated	Bounces submissions whose email TLD matches the list (e.g. `mfa, xyz, top, click, link, surf, icu, gq, ml, cf, tk, ga`).
Blocked email domains	comma-separated	Bounces submissions whose full email domain matches the list — useful for disposable-mail providers.

Honeypot traps (hidden fields filled only by bots) and a minimum time-to-fill check run alongside the rate gates. Blocked attempts are logged to the Attack Log.

WordPress Hardening

The hardening module switches off WordPress features that are frequently abused or that disclose information attackers can use to plan an exploit. Each option is independent.

Disable file editor — turns off the in-dashboard theme and plugin file editor (DISALLOW_FILE_EDIT). An attacker who manages to obtain admin credentials can no longer modify code directly from the WordPress UI.
Disable XML-RPC — blocks the xmlrpc.php endpoint, which is a common target for brute-force and amplification attacks. Only disable XML-RPC if no integration on your site relies on it.
Disable pingbacks and trackbacks — closes a long-standing amplification vector that has been used in DDoS campaigns.
Hide WordPress version — removes the generator meta tag and version query parameters from enqueued assets so the installed WordPress version is not advertised in the page source.
Remove RSD link — drops the Really Simple Discovery link used by external publishing clients.
Remove WLW manifest — removes the Windows Live Writer manifest link that is rarely useful today.

For most production sites it is safe to enable all hardening options. Disabling the file editor and XML-RPC, in particular, is considered a baseline recommendation by the WordPress security community.

Security Check

The Security Check page — Security Pilot → Security Check — runs a one-click audit and produces a letter grade from A (“excellent, your security is strong”) down to F, alongside KPI counters for total passed, failed, warning and total checks.

The Check covers every category the plugin can verify from inside WordPress, including (but not limited to):

HTTPS configured for the site URL.
File editor disabled (DISALLOW_FILE_EDIT).
XML-RPC disabled.
Debug logging and debug display off in production.
wp-config.php access blocked at the web-server level.
WordPress core, plugins and themes up to date.
Inactive plugins still installed (attack surface).
Default admin username absent.
REST API protection enabled.
HTTP security headers, login protection and request firewall active.
Strong DB prefix, PHP exposure, server signature.

Each row prints a short title, a one-line description and a status badge (PASS, WARNING, FAIL, INFO). The Settings → Security Check module exposes three opt-in toggles that add deeper checks (outdated plugins, outdated themes, plugin vulnerability lookup against a public feed) — these run when the report is requested and slow it down by a few seconds, so they are disabled by default. From the report itself, fixes are typically one-clicks away in the WordPress admin (update plugin, delete inactive plugin, edit a hardening toggle).

Usage

A practical first pass through the plugin looks like this.

Install and activate Security Pilot.
Open Security Pilot → Settings.
Enable HTTP Security Headers with the recommended defaults. Visit a few pages of your site and check the browser console for unexpected Content-Security-Policy violations.
Enable Login Protection. Leave Max failed attempts at 5, choose a 15-minute attempt window and a 60-minute lockout for a typical site. Turn on email alerts so you find out when the site is attacked.
Enable the Request Firewall. No further configuration is required.
Enable the Rate Limiter to catch 404 floods (default 25 hits in 60 seconds → IP added to the blocklist).
Toggle REST API Protection for the endpoint groups your site does not use publicly. The /wp/v2/users group is almost always safe to lock down.
Enable Form Protection on sites with contact / comment forms — pick a sensible per-IP cooldown and a TLD blocklist.
Enable WordPress Hardening options. At a minimum, disable the file editor and XML-RPC on production sites.
Run a Security Check and act on every WARNING and FAIL row (update or delete the listed plugins and themes, flip the flagged hardening toggles).

After this initial pass, return to Security Pilot → Security Check periodically to keep the grade above C, and to Attack Log + Access Rules to review what was caught.

Reviewing access rules

The Access Rules screen (Security Pilot → Access Rules) is a three-tab centralised control panel for IP- and URL-based blocklists and whitelists:

Blocked IPs — every address currently blocked by Login Protection, the Rate Limiter or the firewall. Each row prints the IP, the block reason (e.g. firewall:path_traversal, 404_flood, firewall:sqli), the time it was added and an Unblock button. A simple form on top lets you manually block an arbitrary IP with an optional reason, and a search field filters by IP or reason.
Whitelisted IPs — addresses exempted from every check (office, monitoring service, staging server, your own home IP).
Whitelisted URLs — paths exempted from the 404 Rate Limiter (useful when a legitimate endpoint legitimately returns 404 in bursts).

Access Rules — Blocked IPs tab with manual block form, search and per-row Unblock action; sibling tabs cover Whitelisted IPs and Whitelisted URLs.

Use this screen to:

Unblock an address that was caught by a legitimate user fat-fingering their password.
Whitelist a known-good IP (your office, monitoring service, staging server) so it cannot be locked out by accident.
Whitelist a URL that hits the 404 rate limit by design (e.g. a probe path consumed by external monitoring).

Reviewing the attack log

The Attack Log (Security Pilot → Attack Log) records every blocked request, including brute-force lockouts, firewall hits, rate-limiter trips, form-spam bounces and REST API denials. Each row carries the timestamp, source IP, Attack type (e.g. RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), the Rule listener that issued the block, and the Request URI that triggered it. A bulk Clear Log action wipes the page and the toolbar exposes a free-text search plus per-IP and per-listener filters.

The log is useful both for post-incident review and for tuning the firewall: if a legitimate request to your site appears in the log, you can identify which rule was responsible and decide whether to whitelist the request, the IP, or refine the rule.

Security Pilot adds a widget to the standard Dashboard screen (the page WordPress opens at sign-in) so the headline numbers are visible from the moment you log in.

Security Pilot — WordPress dashboard widget — The Security Pilot widget on the WordPress Dashboard — current letter grade, blocked-IP and attack counters, and the five most recent attacks with deep links to Attack Log and Security Check.

The widget prints:

The latest Security Check grade (A–F) and numeric score (e.g. A 95/100), rendered as a coloured ring.
A live Blocked IPs counter sourced from the Access Rules table.
A running Attacks counter sourced from the Attack Log.
The Recent Attacks list — last five rows of the Attack Log with type badge, source IP and timestamp.
Footer shortcuts to Attack Log and Full Security Report.

FAQ

Does Security Pilot replace other security plugins?

For most sites, yes. Security Pilot covers HTTP headers, login protection, request filtering, REST API restrictions, hardening and auditing. It is intentionally lightweight rather than a “swiss-army” suite. Running it alongside another firewall or login-protection plugin is technically possible but rarely useful and can cause overlapping rules to fire twice.

Will the headers break my site?

The default values are conservative. The two headers that most often need attention are HSTS and Content-Security-Policy.

Enable HSTS only after your site is fully reachable over HTTPS, including any subdomains you want covered. The header is cached by browsers and cannot be easily revoked.
Tune the Content-Security-Policy after watching the browser console for blocked resources on real pages. Custom scripts, fonts and analytics often need to be added to the policy.

Will the request firewall block legitimate traffic?

The detection patterns target known attack signatures and tend to be specific. If a legitimate request is blocked, it will appear in the attack log with the rule that triggered the block. You can then unblock the IP and, if the pattern is genuinely unavoidable, document the exception for your team.

Does the plugin work behind a CDN or reverse proxy?

Yes. The plugin reads the originating IP address from the standard request headers and can correctly identify visitors behind a CDN, provided your hosting environment forwards the correct X-Forwarded-For or equivalent header. Make sure any edge layer in front of WordPress does not strip the response headers added by Security Pilot.

Can I export attack logs or blocked IP lists?

The attack log and blocked IP table are stored in your WordPress database and can be reviewed directly from the admin interface. For long-term archival or off-site analysis, take a database backup as you would for any other WordPress data.

Does disabling XML-RPC break anything?

XML-RPC is used by the legacy Windows Live Writer client, the WordPress mobile apps in certain configurations and a small number of third-party integrations. If you are not using any of these, disabling XML-RPC is one of the most effective single-click hardening steps you can take.

Are settings preserved when the plugin is deactivated?

Yes. Deactivating Security Pilot keeps your configuration, attack log and blocklist in the database so that re-activating the plugin restores the previous state.

Troubleshooting

A legitimate user is locked out

Open Blocked IPs, locate the entry for the affected address and remove the block. If the same user is repeatedly locked out, consider:

Increasing Max failed attempts for forgetful users.
Adding the user’s IP (or the office NAT IP) to the allowlist.
Asking the user to reset their password instead of guessing.

Browser blocks resources after enabling CSP

The Content-Security-Policy is intentionally strict by default. Open the browser developer tools and look at the Console tab — the browser will report each blocked resource along with the directive that rejected it. Adjust the CSP to include the trusted origins (CDN, analytics provider, font host) that your site relies on.

Pages keep loading over HTTP after enabling HSTS

HSTS is honoured only after the browser has seen the header at least once over HTTPS. Visit the site directly over https:// to prime the cache. If the site is not yet reachable over HTTPS for every URL you advertise, disable HSTS until the migration is complete.

REST API integrations stop working

If an integration that relies on a protected endpoint group stops working, temporarily disable protection for that group under REST API Protection and confirm the integration authenticates correctly. Many integrations expect to be called as an authenticated WordPress user; authenticated requests are not blocked by this module.

Headers are not present in the response

Some hosts or reverse proxies strip or override response headers added by PHP. Verify the headers with a tool such as curl -I https://example.com/ or your browser’s network inspector. If a header is missing, check the host’s documentation for how to allow custom headers to pass through, or add the header at the edge if the host requires it.

Email alerts are not arriving

Email alerts use WordPress’s wp_mail() function. If no email arrives, the issue is almost always with the site’s mail configuration rather than with Security Pilot. Install a transactional mail plugin (for example, a plugin that routes WordPress mail through SMTP) and re-test by triggering a lockout from a test browser.