Security with Site Defaults: deciding what your site exposes in public

The Site Defaults spotlight covered how presets get applied and how drift is caught. This post is about the security-relevant controls themselves, and how to choose a posture for a real site without breaking an integration you forgot was there.

None of these controls is a firewall or a login hardening plugin. What they do is shrink the public surface WordPress exposes by default: old remote-publishing endpoints, user listings, and version-revealing metadata. That is a modest goal, but it is the part a fresh install gets wrong out of the box.

What each preset does, at a glance

Blog is the one that differs on purpose: a publication usually wants author pages, so it protects the REST user listing but leaves author archives alone. Development changes nothing here, which is the point of a development preset.

XML-RPC: check for old integrations first

XML-RPC is WordPress’s older remote-publishing interface. Agency, Business, and Blog disable it and remove its pingback response header, because on most modern sites nothing legitimate uses it and it remains a common target for automated login attempts.

Before applying one of those presets, ask whether anything still talks to xmlrpc.php: Jetpack, a legacy desktop publishing tool, or an older integration a client set up years ago. If so, use Customize this preset, make XML-RPC available, and apply the result as Custom. You keep the rest of the preset’s hardening and only carve out the piece you actually need.

Application Passwords: why the presets keep them

It is tempting to turn off everything remote. The presets deliberately don’t do that for Application Passwords, because they are how modern REST API integrations and automation authenticate: deployment scripts, headless front ends, and many current publishing tools.

Disabling them is available as a cleanup policy, but only do it once you know nothing depends on them. A quick check is to look at the Application Passwords section on each administrator’s profile in Users. If the lists are empty and you don’t expect to add any, turning them off is reasonable. If anything is listed, find out what it is before you switch it off.

User enumeration: what’s reduced, and what isn’t

Agency and Business close two common public ways to list usernames: the anonymous REST API user listing, and author archives (including the users sitemap). Blog closes only the REST listing. Signed-in users and normal editor features keep working.

Be honest with yourself about the limit. These controls reduce common enumeration paths; they don’t make usernames secret. Author names can still show up in posts, themes, feeds, caches, and other plugins. Treat this as removing the easy, automated paths, and still rely on strong passwords and whatever login protection you already use.

Metadata cleanup: low risk, worth doing

The generator, shortlink, RSD, and WLW tags are small, but the generator tag advertises your WordPress version and RSD exists to help clients discover XML-RPC. Removing them rarely breaks anything on a modern site, which makes them an easy default on any site that isn’t a development box.

Check it from outside, signed out

After applying a preset, confirm the result the way an outsider would see it: from a signed-out browser or with curl, replacing example.com with your site.

1. curl -s https://example.com/wp-json/wp/v2/users should no longer return a list of users.
2. On Agency or Business, curl -sI "https://example.com/?author=1" should come back not found, and https://example.com/wp-sitemap-users-1.xml should be gone.
3. curl -sI https://example.com/ should no longer include an X-Pingback header.
4. View the page source of your home page and confirm the generator tag is gone.

If a check still shows the old behavior, suspect a page cache or CDN first. Purge it and check again before assuming the setting didn’t take.

Keep the posture once you’ve set it

Drift monitoring watches the WordPress options a preset applied and flags changes on the settings page, in an admin notice, and in Site Health, without reverting anything on its own. For the public-surface checks above, a good habit is to rerun them after installing a new plugin or theme, since new code can add its own endpoints that expose the same information.

A practical order of operations

1. List the integrations the site actually has, especially anything older than a few years.
2. Pick the preset that matches the site: Agency or Business for client and company sites, Blog for publications with author pages.
3. Customize only what an integration needs, such as XML-RPC for Jetpack, and apply the result as Custom.
4. Run the signed-out checks, purging caches if needed.
5. Revisit the checks after major plugin or theme changes, and resolve any drift Site Defaults reports.

The goal isn’t a locked-down site that nothing can talk to. It’s a site where every public door that stays open is one you chose to leave open.