The Publish Button That Never Stores Your Password
What actually happens to your WordPress credentials when you publish from the content app — and the SSRF guard protecting the endpoint you point it at.
Handing a third-party tool your WordPress password, even an application-specific one, is the kind of thing worth being suspicious about by default. It's a fair question: where does that credential go after you paste it in?
For CMS publishing in the content app, the honest answer is: nowhere but the request itself. Your WordPress username and application password — or your generic endpoint's API key — are sent through in the body of the publish request, every single time you publish, and they are not written to storage. There's no database row holding your credential waiting to be exposed later. The design note on the route is explicit about this, matching what the product already tells you: nothing is stored.
That matters for a specific, practical reason beyond general good hygiene: a credential that's never persisted can't leak from a database breach, can't be pulled by an internal tool with too much access, and can't quietly outlive the person who set it up. Every publish is its own, self-contained authenticated request.
The other half of trusting an outbound request
Credentials aren't the only risk when a tool makes a server-side request to a URL you supplied. The URL itself could point somewhere it shouldn't — an internal service, a cloud metadata endpoint, a loopback address — and get treated as if it were your public WordPress site. The publish route runs every target URL through a dedicated safety check before it will fetch it at all: HTTPS only, no localhost, no .internal or .local hostnames, and no private IP ranges, including the specific address cloud providers use for instance metadata. If a URL doesn't clear that check, the request never goes out.
It's described honestly as a best-effort guard, not a complete fix — it can't catch a hostname that resolves to something different at the moment of the actual fetch than it did at check time. But it closes off the obvious, common ways a user-supplied URL gets misused, before a single byte goes out the door.
Between the credential handling and the URL check, the design goal is the same: the thing you paste in should do exactly what you asked, and nothing else.