SiteFort security guide

Hardening

The right place to start. Before firewall rules or scan schedules, harden WordPress to close the most common attack vectors on every production site.

Security Guide Hardening Docs

Where to start

Open SiteFort → Hardening and work through it before you touch the firewall or schedule a single scan. Firewalls and scanners react to trouble that's already showing up. Hardening is what makes a site boring to attack in the first place, no exposed version number to target, no usernames sitting in plain sight, no browsable folders, no PHP quietly executable somewhere it never should be. Do this part first and a lot of the traffic the firewall would otherwise be fighting off never has a reason to show up.

Not everything here is equally safe to flip on right away. Some settings are fine for every site, no exceptions. Others depend entirely on what your specific site actually runs. Use this split to know which is which before you start:

Enable first

Hide WordPress Version
Prevent Username in Author Slug
Block User Enumeration
Disable Theme & Plugin Editor
Disable Directory Listing
Block PHP Execution in Uploads
Block Sensitive File Access
X-Content-Type-Options
X-Frame-Options (SAMEORIGIN)
Referrer-Policy

Test before enabling

Restrict REST API Access
Disable Application Passwords
Block Direct PHP in Plugins
Block Direct PHP in Themes
XML-RPC: Fully Disabled
Content-Security-Policy
Strict-Transport-Security
Permissions-Policy
Custom Login URL

Work through one group at a time. Save, check that the site still works the way it should, then move to the next setting. If something does break, you'll know exactly which change caused it instead of untangling five at once.

WordPress Obscurity

Go to SiteFort → Hardening → WordPress Obscurity.

None of these settings make your site unhackable, and it's worth being upfront about that. What they do is take away the easy information a scanning bot uses to decide you're worth a closer look: version numbers, usernames, predictable admin paths. A targeted attacker with time on their hands can still find workarounds. The mass-scanning bots that make up the bulk of daily attack traffic mostly can't, and mostly won't bother trying.

Setting	Recommended	Watch out for
Hide WordPress Version	On	Nothing to watch. Safe for every site.
Clean WordPress Head	On for most sites	Some themes rely on feed discovery links. If RSS subscriptions stop working for anyone, this is the first setting to check.
Prevent Username in Author Slug	On	Author archive URLs will change. Worth a quick check that author pages still resolve correctly on publisher and blog sites.
Block User Enumeration	On	If a public-facing app reads WordPress user data through the REST API, confirm it still works after turning this on.
Disable Theme & Plugin Editor	On	Nothing to watch. If you're editing code through the dashboard editor today, that's worth stopping regardless, use SFTP, Git, or staging instead.
Disable Application Passwords	Test first	Check whether any mobile app, REST client, or publishing tool is authenticating through Application Passwords before you turn this off under them.
Restrict REST API Access	Test first	Read the section right below before touching this one. It's the setting most likely to quietly break something you didn't expect.

Restrict REST API: check this list first

This setting requires authentication for REST requests that don't have it already, and it's worth turning on for a lot of sites. The catch is that more standard WordPress functionality depends on the open REST API than most people realize. Before enabling, check whether your site actually uses any of the following:

WooCommerce cart, checkout, account pages, or store API
Contact forms, booking forms, or quote plugins
Page builder block previews or live search
Membership or LMS content delivery
Headless WordPress frontend
Mobile app or external publishing workflow

If any of those apply to your site, use Endpoint Status inside the setting to allow only the specific public endpoints you actually need, rather than leaving the whole API open just to avoid the extra step.

Server Hardening

Go to SiteFort → Hardening → Server Hardening.

These settings shut down file access and PHP execution paths that show up constantly in real attacks, browsable directories, PHP quietly running from inside your uploads folder, config fragments sitting in public reach. Three of these belong on every production WordPress site, no exceptions, no "it depends."

Setting	Recommended	Watch out for
Disable Directory Listing	On	Nothing to watch. No legitimate visitor has ever needed to browse your folder structure.
Block PHP Execution in Uploads	On	Media and file downloads keep working exactly as before. WordPress has no legitimate reason to execute PHP out of the uploads folder, ever.
Block Sensitive File Access	On	Nothing to watch. Dotfiles, debug logs, and config fragments should never be reachable from a browser in the first place.
Block Direct PHP in Plugins	On for most sites	A handful of older plugins still load files by direct URL. Test your key plugin functionality once this is on.
Block Direct PHP in Themes	On for most sites	Check template pages, custom theme pages, and anything on the frontend that leans on theme functionality after enabling this.
XML-RPC	Depends on setup	See the table below, this one genuinely depends on what's connected to your site.

XML-RPC setting

Your setup	Use this setting
No Jetpack, no mobile publishing app, no legacy tool	Fully Disabled
Jetpack connected, or mobile app in use	Disable Pingbacks Only
A legacy XML-RPC tool is required	Fully Enabled, then pair with a firewall IP rule restricting access to known IPs only

Hosted or managed environments: if your server config is managed externally or Write to Files is disabled, go to SiteFort → Tools → Manual Configuration Rules and copy the generated rules into your server config by hand instead.

Security Headers

Go to SiteFort → Hardening → Security Headers.

Click Analyze Your Security Headers before changing anything. SiteFort shows you what's already deployed, what's missing, and what your hosting environment is already controlling on its own, so you're not duplicating something your host already handles or missing something they don't.

Header	Recommended	Watch out for
X-Content-Type-Options	Enable	Nothing to watch. Safe for all sites.
X-Frame-Options	SAMEORIGIN	If your site genuinely needs to be embedded in an iframe on an external domain, check that use case before you consider tightening to DENY.
Referrer-Policy	strict-origin-when-cross-origin	Analytics relying on full referrer URLs may show slightly less detail. Most modern analytics tools already handle this gracefully.
Permissions-Policy	Disable unused features	Check payment, geolocation, camera, and fullscreen before restricting anything. WooCommerce and video-heavy sites lean on these more often than you'd expect.
Strict-Transport-Security	Only after HTTPS verified	Leave Include Subdomains and Preload off until every subdomain has working SSL. These two are genuinely hard to walk back once they're live.
Content-Security-Policy	Start in Report Only	This is the one most likely to quietly break scripts, checkout flows, analytics, ads, maps, or embeds. Never flip straight to Enforce without testing first.

How to roll out CSP without breaking the site

Start in Report Only mode. This logs violations without actually blocking anything, so you see what would break before it does.
Enable Skip CSP on Admin Pages from the start, so you're not troubleshooting your own dashboard while you're trying to test the frontend.
Walk through your homepage, login page, forms, checkout, account pages, analytics, ads, maps, and any page with a third-party embed.
Add the specific domains your site actually needs, one source type at a time: scripts, styles, images, fonts, connections, frames. Adding everything at once makes it much harder to tell what fixed what.
Switch to Enforce only once every page you tested passes clean, with no console errors.

WooCommerce, membership, and LMS sites: test the full checkout flow, payment confirmation, course player, and any email opt-in or affiliate tracking before enforcing CSP. These are consistently the flows that break first, and they're also the ones you'll hear about fastest if they do.

HSTS preload: read before enabling

Once a browser has seen the HSTS header, it enforces HTTPS for the full max-age duration no matter what you later change in WordPress. Include Subdomains and Preload push that enforcement to every subdomain, and to browsers that have never even visited your site before. Both are difficult to reverse once they've taken effect. Only turn them on once the entire domain is HTTPS-ready with zero exceptions left anywhere.