Scope and limits

SafeHouse hardens WordPress, limits login attempts, stops form bots, and tells you about risky changes and known vulnerabilities. It also covers caching and the small jobs sites usually install separate plugins for. It is not a firewall and not a malware scanner. This page lists what SafeHouse protects against, what it leaves to other tools, and what it expects from you and your host.

What SafeHouse protects against

Risk	What SafeHouse does	Module
Password guessing on login forms, XML-RPC and application passwords	Locks out addresses that keep failing, for longer each time, and pauses attacked accounts for unknown devices	Login limits
Spam sign-ups, comment spam, password-reset floods, scripted logins, fake orders	Honeypot fields and Cloudflare Turnstile on the forms bots target	Bot protection
Attackers learning usernames	Blocks ?author= scans, the public users REST endpoint, the users sitemap and author data in oEmbed	Hardening
An attacker setting the default role to administrator and registering an account	Gives new accounts the Subscriber role when the default role is admin-level, and e-mails you when the setting changes	Hardening, Change alerts
A vulnerable plugin used to upload and install a malicious plugin	Blocks every plugin and theme install, even through code that skips permission checks, until you unlock for a while	Install lockdown
Changes nobody noticed: a new administrator, plugin, mu-plugin or drop-in, an edited wp-config.php	E-mails the alert recipients	Change alerts
Known vulnerabilities in installed software	Warns in wp-admin and by e-mail, and names the version that fixes it	Vulnerability alerts
Plugins closed on WordPress.org, abandoned, or left behind	Lists them weekly, also in Site Health	Plugin health
A tampered SafeHouse update	Installs an update only when its Ed25519 signature and its checksum match	Signed updates
Other sites on a shared Redis server planting cached objects	Signs every cached value and checks the signature before using it	Redis object cache

What SafeHouse does not do

Not included	Use instead
Web application firewall (blocking malicious requests to any URL)	Wordfence, Cloudflare WAF, or your host's firewall
Malware scanning and cleanup	Wordfence or your host
Two-factor login	Wordfence Login Security or another two-factor plugin
Backups	Your host or a backup plugin
Checking the contents of plugin and theme files	Wordfence's file scan. Change alerts notices new plugin folders, not changed files.
Limiting general traffic or absorbing floods	Cloudflare or your host
A Content Security Policy header	Your server configuration. SafeHouse leaves it out on purpose, because a generic policy breaks payment forms that load in frames.
Network activation on multisite	Activate SafeHouse on each site separately

Running with Wordfence explains how the two divide the work when both are installed.

How SafeHouse avoids becoming the weak spot

A security plugin runs on every request with administrator-level access to the site, so its own design matters as much as its features.

• Signed updates. WordPress installs a SafeHouse update only when the release manifest's Ed25519 signature and the package's SHA-256 checksum both match. This covers updates from the update host. A ZIP you upload by hand is not checked by SafeHouse; verify it yourself first.
• Administrator-only actions. Every SafeHouse request handler checks the user's capability and a nonce. The settings page needs manage_options.
• Changes are logged. Every settings change goes to the activity log, with the user and the address.
• No files written by web requests. SafeHouse writes no .htaccess rules and never edits wp-config.php. The only files it creates, the Redis object cache drop-in and the safe mode flag, are written by WP-CLI commands.
• No rescue URL. Safe mode is turned on with a file, a constant or WP-CLI, never with a secret URL, because URLs end up in server and CDN logs.
• Visitor addresses cannot be faked with headers. SafeHouse uses the connection's address (REMOTE_ADDR) unless you name a trusted proxy, and it trusts Cloudflare's visitor header only on connections from Cloudflare's own addresses.
• No telemetry. SafeHouse contacts only the services listed on Data and privacy, and only for the modules that need them. The activity log stays in the site's database and keeps entries for 90 days.
• Secrets stay out of the log. Values whose names look like passwords, tokens, keys or cookies are stored as [redacted].

Who is responsible for what

SafeHouse and Design House:

• releases built from the public repository and signed in a protected GitHub Actions environment
• the vulnerability data that Vulnerability alerts downloads, signed with its own key
• fixes for vulnerabilities reported privately through the repository's Security tab

You:

• keep WordPress, plugins, themes and PHP up to date; SafeHouse tells you what is vulnerable but does not update it for you
• read the alert e-mails, and keep Alert recipients pointing at a mailbox someone reads
• keep backups and use strong passwords, ideally with two-factor login
• tell SafeHouse about a proxy in front of the site (Behind Cloudflare or a proxy)
• keep a way back in: file access or WP-CLI (Recover from a lockout)

Your host:

• the server, PHP and database, and their security updates
• a network firewall
• outgoing HTTPS from the server, which updates, vulnerability data and Turnstile need

Assumptions

• SafeHouse trusts administrators. Anyone who can manage options can switch modules off. Pin the important ones in wp-config.php if that matters to you (Configure in wp-config).
• SafeHouse trusts wp-config.php. Constants defined there override the settings page.
• SafeHouse trusts the release signing key and the vulnerability data key built into the plugin. Signed updates explains what a valid signature proves and what it does not.

Related pages

• Running with Wordfence
• Signed updates
• Data and privacy