SiteFort documentation

Hardening

Lock down the WordPress attack surface. Covers obscurity settings, server rules, login protection, password policies, two-factor authentication, lockouts, and security headers.

Documentation Home Recommended Settings

Hardening

Hardening reduces the number of ways attackers can fingerprint, access, or abuse WordPress. SiteFort organizes these controls into WordPress Obscurity, Server Hardening, Login Security, Two-Factor Authentication, and Security Headers.

Rollout advice: enable hardening in layers. Start with low-risk information exposure controls, then server rules, then login controls, then strict headers such as CSP or HSTS preload.

WordPress Obscurity

These settings reduce fingerprinting and account discovery. They are usually safe to enable, but REST API restrictions can affect headless frontends, mobile apps, blocks, forms, and integrations.

Setting	What it does	Check before enabling
Hide WordPress Version	Removes version numbers from meta tags, RSS feeds, and script query strings.	Safe for most sites.
Clean WordPress Head	Removes unnecessary meta tags, manifest links, and feed discovery links from the HTML head.	Confirm no theme feature relies on a removed discovery link.
Prevent Username in Author Slug	Prevents author archive slugs from exposing login usernames and repairs existing matching slugs.	Check author archive URLs on publisher sites.
Block User Enumeration	Blocks author scanning, REST API user endpoints, oEmbed data, and user sitemaps.	Safe for most sites. Confirm author data is not required by a public app.
Disable Theme & Plugin Editor	Removes the built-in code editor from Appearance and Plugins menus.	Recommended for production. Use Git, SFTP, or a deployment pipeline for code changes.
Disable Application Passwords	Removes Application Passwords, which bypass two-factor authentication.	Do not enable if mobile apps, external publishing tools, or API clients rely on application passwords.
Restrict REST API Access	Requires authentication for REST endpoints. Core data endpoints require appropriate capabilities and unknown endpoints are blocked for unauthenticated visitors.	Open Endpoint Status and allow public endpoints required by your theme, forms, commerce, headless frontend, or integrations.

Endpoint Status shows Endpoint, Status, and Action columns. Status badges include Core Protected, capability names, Core Permissions, Public Allowed, Login Required, and Unrestricted. Actions include Allow Public and Restrict.

Server Hardening

Server hardening prevents direct access to files and directories that should not be browsed or executed. These rules are strongest when written to the web server configuration, because requests can be blocked before WordPress loads.

Setting	Why it matters	Verification
Disable Directory Listing	Prevents visitors from browsing folder contents when no index file exists.	Open a directory path without an index file and confirm it is not listed publicly.
Block PHP Execution in Uploads	Stops web shells from executing PHP directly inside uploads.	Confirm legitimate media still loads. WordPress should not need to execute PHP from uploads.
Block Direct PHP Access in Plugins	Prevents individual plugin PHP files from being executed directly by URL.	Verify plugin functionality that uses WordPress routing still works.
Block Direct PHP Access in Themes	Prevents theme PHP files from being executed directly by URL.	Check key templates and frontend pages after enabling.
Block Sensitive File Access	Blocks dotfiles, debug files, lock files, version-control metadata, sample config files, and server config fragments.	Test a safe blocked path such as a known readme or sample file if available.
XML-RPC	Choose Fully Enabled, Disable Pingbacks Only, or Fully Disabled.	Disable pingbacks for most sites. Fully disable only if Jetpack, mobile app, or XML-RPC clients are not required.

Manual Configuration Rules provides Server Config Rules and wp-config.php Rules, with actions to show or hide rules, regenerate, copy, verify enforcement, open manual rules, or open advanced settings. Use this when Write to Files is disabled or server configuration is managed outside WordPress.

Custom Login URL

Custom Login URL replaces the default WordPress login URL with a custom path. Standard login endpoints are disabled and return an error or redirect based on your setting.

Choose a login slug that is memorable to administrators but not obvious to bots.
Choose a register slug if public registration is enabled.
Copy and store the new login URL before saving.
Choose the default wp-login.php response: 403, 404, or Redirect.
If using Redirect, confirm the redirect target does not reveal the new login path.

Access warning: Pretty permalinks may be required. Keep hosting or file access available before changing the login URL on a production site.

Login Form Protection

Setting	What it does	Recommended starting point
Limit Login Attempts	Locks out IPs and users after repeated failed login attempts.	Start with moderate thresholds, then tune from Lockouts & Recovery.
Bot Detection (CAPTCHA)	Requires CAPTCHA verification on the login form.	Enable when brute force or bot attempts continue after lockouts, or when compliance policy requires it.
Restrict Login Identifier	Allows email only, username only, or both based on policy.	Email Address Only is recommended when user email addresses are managed and unique.
Block Default Admin Username Logins	Rejects authentication attempts using the default `admin` username.	Enable unless a real account still uses that username; rename that account first.
Obfuscate Login Error Messages	Uses a generic failure response instead of revealing whether username or password was wrong.	Enable on production sites.

Limit Login Attempts supports failed attempts per IP from 1 to 20, failed attempts per user from 1 to 20, detection windows of 5 min, 15 min, 30 min, 1 hour, and 24 hours, and lockout durations of 5 min, 15 min, 30 min, 1 hour, and 24 hours.

Password Policies

Password policies decide what happens when a user reaches the login flow or changes credentials. Apply stronger policy to privileged roles first.

Policy	What it does	Recommended use
Breached Password Detection	Blocks known breached passwords and triggers mandatory reset when existing credentials appear in global leaks.	Enable for all users when possible.
Enforce Strong Passwords	Rejects weak passwords and requires reset when existing password no longer meets policy.	Enable for privileged users at minimum.
Prevent Password Reuse	Blocks users from reusing their current password after a reset or voluntary change.	Useful for regulated sites and administrator accounts.
Require Password Change on Role Promotion	Requires a new password when a user is promoted to Administrator or Editor.	Recommended for all production sites.
Password Expiration Policy	Requires rotation after 1 to 365 days.	Use only where policy requires periodic rotation; avoid unnecessary rotation for normal users.

Lockouts & Recovery

Lockouts & Recovery shows active lockouts from failed login attempts and recent authentication activity. It is the recovery panel when a legitimate user is blocked by login protection.

Control or state	What it means	How to use it
Active Lockouts / No Active Lockouts	Whether an IP or user is currently locked out.	Use Unlock for a specific false positive or Unlock All during a broad misconfiguration.
Protection Active / Disabled	Whether login attempt limiting is enforcing lockouts.	If disabled, historical activity can still appear but new lockouts are not enforced.
Block in Firewall	Converts abusive login activity into a firewall block.	Use for clearly malicious IPs that keep returning.
Trust (Allowlist)	Adds a source to allowlist or trusted handling.	Use only for stable office, VPN, or monitoring IPs that you control.
Recent Authentication Activity	Shows event, IP, and time.	Use to confirm whether a complaint is a real lockout, a wrong password, or another login control.

Two-Factor Authentication

Two-Factor Authentication protects WordPress accounts with a second verification step. SiteFort includes 2FA Enforcement for policy and My 2FA for the current user's setup.

Area	What users do	Operational guidance
Your 2FA Status	Review current method, recovery code count, setup action, regeneration, or disable action.	Administrators should keep recovery codes offline before enforcement begins.
Authenticator App	Scan QR code or use manual secret in Google Authenticator, Authy, 1Password, or compatible app.	Best default for administrators and editors.
Email Code	Receive a one-time code by email during login.	Useful fallback when app rollout is not practical, but depends on email delivery.
Recovery Codes	Save generated codes. Regeneration replaces previous codes.	Store securely. Each code can be used once.
2FA Policy Settings	Enable 2FA, choose allowed methods, enforce by role, set remember-device duration, and set grace period.	Start with Administrator and Editor roles, then expand if needed.

Allowed methods are Authenticator App (TOTP) and Email Code. The UI prevents removing the last allowed method. Roles include Administrator, Editor, Author, Contributor, and Subscriber. Remember Device Duration supports 0 to 365 days, and Grace Period supports 0 to 30 days.

Security Headers

Security Headers configures browser-level protections. Start with analysis, review recommendations, deploy low-risk headers, then carefully test Content-Security-Policy and HSTS.

Click Analyze Your Security Headers.
Review Deployment recommendation, Recommendations, Read-Only Warnings, and Deployed Headers.
Use Enable / Fix, Configure, or Edit for each header.
Click Refresh Preview or Re-scan after changes.

Header	Purpose	Deployment guidance
Content-Security-Policy	Restricts external resources the browser may load, mitigating XSS and data injection.	Start in Report Only. Move to Enforce after scripts, styles, images, fonts, connections, frames, forms, and embedded content are validated.
Strict-Transport-Security	Enforces HTTPS-only connections.	Enable only after HTTPS works reliably. Include subdomains and preload only when every subdomain is HTTPS-ready.
X-Content-Type-Options	Prevents MIME sniffing and content-type confusion.	Usually safe to enable.
X-Frame-Options	Prevents clickjacking by controlling iframe embedding.	Use SAMEORIGIN unless the site should never be framed; use DENY carefully.
Referrer-Policy	Controls how much URL information is shared when users navigate away.	`strict-origin-when-cross-origin` is the recommended balance.
Permissions-Policy	Restricts browser APIs such as camera, microphone, geolocation, payment, USB, fullscreen, and autoplay.	Disable features the site does not use. Use Self Only for features needed by your domain.

Disclosure header warnings include X-Powered-By, Server, and X-Generator. CSP source tokens include Self, Inline, Eval, HTTPS, Data, Blob, and None where applicable. CSP also supports custom domains and Skip CSP on Admin Pages, which is recommended because WordPress admin relies heavily on inline scripts.

Referrer-Policy Options

Available policies include strict-origin-when-cross-origin, no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, and unsafe-url. Avoid unsafe-url on production sites because it sends full paths and query strings.