What the plugin stores and trusts
What the worker keeps on the site, what it trusts, and what it refuses.
What the site trusts
Exactly one thing on its own side: a caller presenting the workspace token. For the calls it makes itself, since 2.3.0, it presents a credential of its own, issued by the platform and replaced on request, and the instructions it accepts in the answer are signed by the platform and valid once. Everything the platform may do to the site — read its inventory, run an update, take and restore a backup, replace the worker, log an administrator in — is behind that one check. There is no second credential, no list of allowed addresses on the site's side, and nothing that answers an anonymous caller with anything but a refusal.
The login the dashboard offers is the one place a platform call becomes a WordPress session: the site issues a ticket that the browser then redeems, valid once and for one minute.
What the site stores
- The workspace token, and since 2.3.0 the site's own credential beside it. Since 2.3.0 neither is written into a backup.
- The platform's address, for the calls the site makes.
- Backups, under
wp-content/backups/in a directory whose name carries a secret of the site's own, so that nobody can guess the path; released when the storage policy says so. - Logs — activity and email as daily files, errors and analytics in tables of the plugin's own, login attempts. Analytics stores no cookie; visitors are hashed with a per-site salt.
The site never holds an object-storage credential. When a backup is uploaded, or downloaded again for a restore, the platform hands the site links that read or write one file for a limited time. The site never sees a key.
What the site refuses
- Anonymous callers, and callers with a wrong token.
- Being cached. Every answer to the platform is marked not cacheable, and LiteSpeed Cache is told directly.
- A release it was not given. The worker installs only what the platform released to this site, checksum verified, and refuses when it cannot ask.
- A restore it cannot do. A restore from a copy on the site that is not wholly there is refused with a cause, rather than restoring what happens to be in the directory.
What the platform refuses on the site's behalf
- A site that redirects is not accepted, because a redirect would strip the credential from the platform's calls.
- Following a redirect on an authenticated call, ever.
- A firewall's page in place of the site's answer, and a report of success the site itself contradicts.
- Trusting a site with a credential before the site has refused a wrong one.
Reporting a problem
If you find something in the worker that this page says should not be possible, report it privately as described under Reporting a vulnerability.