Stillward Security Wordpress Plugin - Rating, Reviews, Demo & Download
Plugin Description
Stillward Security follows one rule: protect, don’t disturb.
Most security plugins break sites by aggressively filtering requests, stripping
form data, whitelisting file types, or forcing strict policies. Stillward ships
with only non-breaking hardening enabled by default. Anything that can affect
how your site works is turned OFF until you knowingly enable it.
Enabled by default (safe on any site):
- Security headers — X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
- WordPress hardening — hide version, generic login errors, disable the file editor, remove head meta leaks
- Block username enumeration — stops ?author=N probes and the public REST users list
- Brute-force login protection — IP lockout after too many failed logins
- Upload protection — blocks executable uploads (.php, .exe…) and disables PHP execution in /uploads (normal media and documents still upload)
Opt-in (off by default — enable knowingly):
- Disable XML-RPC (leave off if you use Jetpack or the WP mobile app)
- HSTS header (HTTPS-only sites)
- Content-Security-Policy (test carefully)
- Strict MIME whitelist
- Custom (hidden) login URL
- Request firewall — SQLi/XSS/traversal detection. It NEVER edits your submitted
data, runs in log-only mode by default, and only blocks if you switch it to
Block mode. - Auto-clean for the Malware Shield. Scanning is on and reports what it finds;
removing anything automatically is your decision. You can also clean once, on
demand, with the “Scan & clean” button.
Malware Shield — and why it will not eat your files
The Malware Shield hunts one specific, self-healing infection (fake db.php /
advanced-cache.php drop-ins, vapor-* / host-*-bridge mu-plugins, injected
theme functions.php, sc_* options and cron). Deleting a legitimate file is
worse than the malware, so three gates must all pass before anything is removed:
- Confidence — only an exact marker unique to this malware family can lead
to a removal. The generic “obfuscated code” heuristic is report-only, because
licence loaders, packers and minified libraries look exactly like that. - Location — removal is limited to the places this family actually drops
files: the three wp-content drop-ins, mu-plugins, PHP files in/uploads,
thewp-content/cachestaging copy, filenames it is known to plant, and any
file inwp-includes/wp-admin/the web root that the official WordPress
checksum manifest says WordPress does not ship.
A file that IS part of a real plugin, theme or WordPress itself is never
deleted — it is reported instead, because an infected real file needs
reinstalling, not erasing.wp-config.phpis never deleted under any
circumstance. - Protected paths — this plugin’s own folder and other security/backup
plugins (which legitimately ship malware signatures in their source) are
skipped entirely.
Everything that is removed is copied into the plugin’s own database table
first — never into another file on the server, because a copy of malware on
disk is still malware on disk. If a removal turns out to be a mistake, download
the copy from the Malware Shield tab and put it back. Removed options and cron
events are backed up the same way and restore in one click. An infected theme
functions.php is never modified or deleted: it is reported, so you can
reinstall a clean copy of the theme.
Developers can force report-only behaviour for any path with the
wpss_malware_auto_removable and wpss_malware_protected_paths filters.
Database Audit — the things a file scanner cannot see
A file scanner is blind to a compromise that never writes a file, and that is
not a hypothetical: an SEO-cloaking campaign ran for four months across eight
sites on one hosting account while hourly scans reported clean, because its code
lived in a plugin’s database table, its configuration in an option, its spam in
wp_posts, and its administrators were inserted straight into wp_users.
The audit runs alongside the file scan and asks three questions that have exact
answers:
- Is there an option named after this site’s own hostname? The malware names
its configuration rowmd5(sha1($host)), so the name is different on every
site and no blocklist can list it — but the same name can be computed here and
looked up. There is no false-positive surface at all. Autoloaded 32-hex option
names in general are raised as a warning. - Was any administrator created by something other than WordPress?
WP_User::add_role() assigns a boolean, so WordPress only ever writes
s:13:”administrator”;b:1. A row built by hand in SQL writes a string
instead. That single difference found four rogue administrators across those
eight sites and produced no false positives. Duplicateuser_loginvalues are
treated the same way — WordPress will not create one. - Does any content belong to a user that does not exist? And were large
batches of posts written within a single second? A legitimate import looks
identical to an injection here, so both are warnings with a one-click “It was
me” that stops that exact fact being reported again.
Nothing found in the database is ever changed automatically. A confirmed rogue
administrator can be demoted to Subscriber with its sessions ended and password
reset — never deleted — and the previous role, capabilities and password hash go
into quarantine first so Restore puts the account back exactly as it was.
Critical findings are e-mailed the moment they are recorded: once per distinct
finding per day, at most twelve an hour, and only for findings that mean
something got in. Routine lockouts and firewall blocks are logged but never
mailed, because an alert that is always noise teaches people to ignore alerts.
Safety guarantees
- The firewall only reads requests — it never modifies or strips POST data, so
it cannot break form nonces or submissions. - Deactivating the plugin is non-destructive: it does not touch wp-login.php,
.htaccess, your options or logs. - No per-request database writes — only real security events are logged.
Screenshots
No screenshots provided
