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 touching the firewall or running scans. Hardening removes the conditions that make a site easy to target: version fingerprinting, exposed usernames, browseable directories, and PHP files that should not be publicly executable.

Some settings are safe to turn on immediately. Others depend on what your site runs. Use this split as your starting point:

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

Enable one group at a time. Save, verify the site works, then move to the next setting. This keeps rollback simple if something breaks.

WordPress Obscurity

Go to SiteFort → Hardening → WordPress Obscurity.

These settings reduce what automated scanners can learn about the site. Bots collecting version numbers, usernames, and admin paths use that information to run targeted attacks. Removing it does not make the site immune, but it makes mass scanning less productive against you specifically.

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 use feed discovery links. If RSS subscription features break, check this setting.
Prevent Username in Author Slug	On	Author archive URLs change. Check that author pages still work correctly on publisher and blog sites.
Block User Enumeration	On	If a public-facing app reads WordPress user data via REST, confirm it still works after enabling.
Disable Theme & Plugin Editor	On	Nothing to watch. Use SFTP, Git, or a staging environment for code changes instead.
Disable Application Passwords	Test first	Check whether any mobile app, REST client, or publishing tool authenticates using Application Passwords before disabling.
Restrict REST API Access	Test first	Read the section below before enabling this one.

Restrict REST API: check this list first

This setting requires unauthentication for REST requests. It is worth enabling on many sites, but a surprising number of standard WordPress features use the REST API. Before enabling, check whether your site 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 these apply, use Endpoint Status inside the setting to allow only the specific public endpoints your site needs, rather than leaving everything open.

Server Hardening

Go to SiteFort → Hardening → Server Hardening.

These settings block file access and PHP execution paths that attackers commonly abuse. Three of them should be on every production WordPress site without exception.

Setting	Recommended	Watch out for
Disable Directory Listing	On	Nothing to watch. No legitimate user needs to browse your folder structure.
Block PHP Execution in Uploads	On	Media and files still load normally. WordPress does not execute PHP from the uploads folder under any normal circumstance.
Block Sensitive File Access	On	Nothing to watch. Dotfiles, debug logs, and config fragments should never be publicly accessible.
Block Direct PHP in Plugins	On for most sites	A small number of older plugins load files by direct URL. Test key plugin functionality after enabling.
Block Direct PHP in Themes	On for most sites	Check template pages, custom theme pages, and any frontend page using theme functionality after enabling.
XML-RPC	Depends on setup	See table below.

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 manually.

Security Headers

Go to SiteFort → Hardening → Security Headers.

Click Analyze Your Security Headers before making changes. SiteFort shows what is already deployed, what is missing, and what your hosting environment controls independently.

Header	Recommended	Watch out for
X-Content-Type-Options	Enable	Nothing to watch. Safe for all sites.
X-Frame-Options	SAMEORIGIN	If your site legitimately embeds pages in iframes on external domains, check those use cases before enabling DENY.
Referrer-Policy	strict-origin-when-cross-origin	Analytics that depend on full referrer URLs may show reduced data. Most modern analytics tools handle this correctly.
Permissions-Policy	Disable unused features	Check payment, geolocation, camera, and fullscreen before restricting. WooCommerce and video-heavy sites commonly use these.
Strict-Transport-Security	Only after HTTPS verified	Do not enable Include Subdomains or Preload until every subdomain has working SSL. These are hard to reverse.
Content-Security-Policy	Start in Report Only	Can break scripts, checkout flows, analytics, ads, maps, and embeds. Never switch to Enforce without testing.

How to roll out CSP without breaking the site

Start in Report Only mode.
Enable Skip CSP on Admin Pages from the start.
Test your homepage, login page, forms, checkout, account pages, analytics, ads, maps, and any page with third-party embeds.
Add the specific domains your site actually needs. Add them one source type at a time: scripts, styles, images, fonts, connections, frames.
Switch to Enforce only after every tested page passes without 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 the flows most likely to break.

HSTS preload: read before enabling

Once a browser sees the HSTS header, it enforces HTTPS for the max-age duration regardless of changes made in WordPress. Include Subdomains and Preload extend this to every subdomain and to browsers that have never even visited the site. Both are difficult to undo. Enable them only when the entire domain is HTTPS-ready with no exceptions.