Core security settings

Settings → General Settings → Core Security holds the switches that close the doors WordPress leaves open by default. Each is independent. Apply recommended settings turns on the ones marked below together.

Block XML-RPC requests · recommended

XML-RPC lets remote software communicate with WordPress. Check connected publishing and management services before restricting it; their current requirements determine whether it is needed.

In 3.0, the switch:

• Refuses authenticated methods governed by WordPress’s xmlrpc_enabled filter.
• Removes pingback.ping and pingback.extensions.getPingbacks.
• Removes the X-Pingback header.

It does not reject every request to xmlrpc.php. Methods supplied by plugins with their own authentication can remain available. WordPress explains the filter’s scope in its API reference. Test the services you rely on after changing the setting. For an endpoint-wide block, work with your host and check compatibility separately.

Hide usernames from the public · recommended

Out of the box, WordPress hands out every login name to anyone who asks. On, this switch closes all three places it does so:

• The REST endpoint /wp-json/wp/v2/users for visitors who are not signed in with a role that can list users. Signed-in users can still read their own record, so the block editor works.
• The /?author=1 redirect that reveals the username of user 1.
• The users sitemap, wp-sitemap-users-1.xml.

Verify email addresses on signup · recommended

New accounts registered through WordPress or through FluentAuth’s forms must confirm their address by clicking a link before the account is active. It stops bots registering with addresses they do not own.

Keep these roles out of wp-admin · recommended

Hides the admin bar on the front end and redirects the chosen roles away from /wp-admin to the site’s front page (or to their login redirect). Default: Subscriber. Members, customers and students see your site, never the dashboard.

Filter: fluent_auth/low_level_user_roles.

Application passwords

Application passwords let external apps authenticate to the REST API with a per-app secret. They are useful for a headless front end or a mobile app, and a risk otherwise. Block application passwords disables them. It is not part of the recommended set because the plugin cannot know whether you use them. If you are unsure, review connected services and the Application Passwords section on relevant user profiles before blocking them.

Visitor IP and proxies

The attempt limit, the audit log and the IP rules all need the visitor’s real address. Behind Cloudflare or a reverse proxy, PHP sees the proxy’s address instead.

FluentAuth resolves the address in this order:

1. Cloudflare. If the request comes from one of Cloudflare’s published address ranges, the CF-Connecting-IP header is used. Automatic, nothing to configure.
2. A declared trusted proxy. Under Settings → General Settings → Visitor IP, list the proxy’s address or range and the header it sets (default X-Forwarded-For). Only when the request actually comes from a listed proxy is the header trusted, so a visitor cannot forge it.
3. REMOTE_ADDR, the connection’s own address.

The same can be set in wp-config.php, which then locks the settings screen:

define('FLUENT_AUTH_TRUSTED_PROXIES', '10.0.0.0/8, 192.168.1.5');
define('FLUENT_AUTH_PROXY_IP_HEADER', 'HTTP_X_REAL_IP');

The settings screen checks your own request and warns if every visitor appears to share one address, which is the sign of an undeclared proxy.

Other settings on this page