Hardening

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.

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.

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.

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.

Login Security

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.

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

Login Form Protection

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.

For custom frontend login, registration, or checkout forms, see Custom Form CAPTCHA.

Password Policies

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

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.

Two-Factor Authentication

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

Allowed methods are Authenticator App (TOTP) and Email Code. Roles include Administrator, Editor, Author, Contributor, and Subscriber. Remember Device Duration supports 0 to 365 days, and Grace Period supports 0 to 30 days.

WooCommerce and membership account integration

SiteFort can expose 2FA enrollment and management on frontend account pages, allowing customers and members to manage account security without entering the WordPress administration area.

WooCommerce

When SiteFort Two-Factor Authentication is enabled and WooCommerce is active, SiteFort automatically adds My Account → Account security. No shortcode, WooCommerce template override, or theme modification is required.

Customers can use Account security to:

• Enroll in two-factor authentication.
• Change their active 2FA method.
• Generate a new set of recovery codes.
• Disable 2FA when the site's enforcement policy allows it.

The normal WooCommerce login page remains available. When an enrolled user signs in, the password is validated first. SiteFort then requires the second factor before authentication is completed.

Membership and custom account pages

For membership plugins, LMS platforms, customer portals, or custom frontend dashboards, add the following shortcode to the authenticated account page where users should manage their 2FA settings:

[sitefort_2fa_management]

The shortcode displays SiteFort's 2FA management interface for the currently authenticated WordPress user. Depending on the site's policy and current account state, users can enroll, change methods, manage recovery codes, or disable 2FA.

Logged-out visitors receive a generic sign-in message. SiteFort does not expose or generate a login URL from the shortcode.

2FA integration checks

• Test Authenticator App and Email Code enrollment when both methods are allowed.
• Generate recovery codes and test one before enforcing 2FA broadly.
• Confirm WooCommerce customers can open My Account → Account security.
• Confirm custom account pages display the correct 2FA state for the logged-in user.
• Confirm users in enforced roles are required to complete enrollment after the configured grace period.
• Verify transactional email delivery before relying on Email Code.
• Avoid overlapping 2FA enforcement from another security or authentication plugin.

CAPTCHA on Custom Forms

SiteFort can render CAPTCHA inside custom frontend login, registration, and checkout forms. Configure a CAPTCHA provider in SiteFort before adding a CAPTCHA shortcode to a form.

CAPTCHA on custom login forms

Add the following shortcode inside the custom login form:

[sitefort_captcha action="login"]

When the form uses the standard WordPress authentication flow, SiteFort validates the CAPTCHA automatically during login.

CAPTCHA on custom registration forms

Add the following shortcode inside the registration form:

[sitefort_captcha action="register"]

Registration systems that use their own submission process must validate the CAPTCHA before creating the WordPress account. Use the SiteFort developer validation API when the registration plugin or custom form does not pass through a supported WordPress registration flow.

Other custom forms

Available CAPTCHA actions are:

• login
• register
• checkout

Custom form processors can validate CAPTCHA submissions through the SiteFort developer API. This is intended for plugin developers, custom integrations, and forms that manage their own submission lifecycle.

Compatibility notes

• Configure a CAPTCHA provider before adding a SiteFort CAPTCHA shortcode.
• Test each custom form after integration, especially forms created with page builders.
• Forms using AJAX, REST APIs, or proprietary authentication may require additional validation integration.
• CAPTCHA does not replace the form's existing nonce, authorization, input validation, or permission checks.
• Custom login forms must use the WordPress authentication flow for SiteFort's login-time 2FA challenge to run.

Developer reference

Render SiteFort CAPTCHA from PHP using the appropriate action for the form:

echo do_shortcode( '[sitefort_captcha action="register"]' );

For a custom submission handler, validate the CAPTCHA before completing the protected action:

$result = apply_filters(
'sitefort_validate_captcha',
true,
'register',
'custom'
);

if ( is_wp_error( $result ) ) {
// Stop the submission and display the returned error.
}

The second argument after the initial value identifies the CAPTCHA action. Use the action that matches the form being protected, such as login, register, or checkout.

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.

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

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.