Stillward Security

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:

1. 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.
2. Location — removal is limited to the places this family actually drops files: the three wp-content drop-ins, mu-plugins, PHP files in /uploads, the wp-content/cache staging copy, filenames it is known to plant, and any file in wp-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.php is never deleted under any circumstance.
3. 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 row md5(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. Duplicate user_login values 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.