Skip to content

How WP Safer reaches your site: the site key, signed requests and what that access can do

Traffic only goes one way, from the panel to your site. What every request has to pass before the plugin runs it, why the site key is worth as much as an administrator password, and the two ways to take the access away.

Last updated

Every backup, update and uptime check WP Safer runs starts the same way: the panel sends a signed command to the WP Safer plugin on your site. This article explains how that connection is protected, what the access is worth in practice, and how to take it away.

Traffic only goes one way

The plugin never calls wpsafer.com. All traffic is panel → site: a signed POST from our server to the /wpsafer-api endpoint the plugin registers. There is no outbound connection from your site to us, nothing to allow in an outbound firewall, and no queue on your side waiting for instructions.

One practical consequence: “is this site connected?” can only be answered from the last time we reached it. That is exactly what the WP Safer card in your WordPress admin shows — the result of the last request that arrived, not a live handshake.

What protects a request

Before the plugin runs anything, the request has to pass every one of these checks:

  • Rate limit. At most 60 requests per minute per calling IP address. Anything above that is rejected before it is even looked at.
  • IP allowlist. The plugin ships with the list of WP Safer server addresses and refuses requests from anywhere else. The single exception is the one-click admin login, which is opened in your own browser.
  • A site key must be configured on the site, and the request must carry a signature.
  • A timestamp inside a five-minute window. A request that is more than five minutes old — or five minutes in the future — is rejected, so an intercepted request cannot be replayed later.
  • A valid signature. The signature is computed over the timestamp, the list of requested actions and the site key. The key itself never travels over the network: only the resulting hash does, and it is compared in constant time.

If any check fails, the plugin answers with a short reason (rate-limited, ip-not-allowed, bad-site-key, bad-timestamp) and does nothing else. Those reasons are what the panel shows on the site row when a site will not connect.

The site key is an administrator credential

The key is created when you add a site and is stored in two places: in our database, and in the plugin’s settings on your site. You can see and copy it in the panel on the site page, under Details, and on the site itself on the WP Safer settings screen in wp-admin.

Treat it the way you would treat an administrator password, because that is what it is worth. A correctly signed request can install, update, activate and delete plugins and themes, update WordPress core, take and restore a backup, read the plugin and user inventory — and open wp-admin as the administrator user you nominated, which is what the one-click login button in the panel does.

What we do not store is your WordPress administrator password. We store the administrator username you enter, and the key that signs the login. FTP/SFTP details are optional, only needed when WordPress cannot write files on its own; if you enter them, the username is stored as you typed it and the password with reversible encryption, and you can clear them at any time.

Taking the access away

Access ends the moment the key stops matching. From the site side, either of these is enough:

  1. Change the key. In wp-admin, open the WP Safer settings screen and save a different 32-character value. Every command from the panel is rejected from that second on.
  2. Deactivate or delete the plugin. Without the plugin there is no endpoint to call at all.

The panel has no “rotate key” button, so after doing either of those you reconnect by removing the site in the panel and adding it again, which issues a fresh key.

Removing a site in the panel is the other half: it stops all scheduled work and takes the site out of your list. Because a deleted site can be restored from the trash, its record is kept after deletion — so if your reason for deleting is that the key may have leaked, change the key on the site as well. That is the step that actually invalidates it.