Service Security
Audit, harden, monitor, respond. Real defense from a team that ships WP Vanguard, a WordPress security scanner in production. We know the attacks because we scan for them every day.
<?php
// wp-config.php hardening (production)
// Disable file editing in admin
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
// Force SSL on admin and login
define( 'FORCE_SSL_ADMIN', true );
// Limit revisions, autosave interval
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );
// Strict cookie security
define( 'COOKIE_DOMAIN', 'example.com' );
define( 'COOKIEHASH', md5( 'example.com' ) );
// Application passwords only for service accounts
add_filter( 'wp_is_application_passwords_available', function ( $available, $user ) {
return user_can( $user, 'manage_options' ) ? $available : false;
}, 10, 2 );
// Disable XML-RPC unless explicitly needed
add_filter( 'xmlrpc_enabled', '__return_false' );
Why security
The difference matters. Unbreached means nobody serious has looked yet. The attack surface is wide open: an outdated plugin nobody noticed, a wp-config.php with file editing enabled, an admin account with a leaked password, a REST endpoint with permission_callback set to __return_true. The site is up, but the lock is unlocked.
We hardened our own infrastructure to ship WP Vanguard. We see the attack patterns daily because our scanner looks for them on real sites. The hardening we ship to clients is the hardening we run on our own production stack.
What we harden
Config layer, plugin layer, user layer, edge layer, monitoring layer. We do not stop at installing a plugin. We close the doors a plugin cannot reach.
01
Full security audit of plugins, themes, file permissions, user accounts, application passwords, cron jobs, database tables, options. Findings classified by severity with concrete remediation steps.
You know your real risk surface before we change anything.
02
File editing disabled, SSL forced, cookies scoped properly, XML-RPC disabled or restricted, application passwords gated to admins only. The basics done right, not skipped.
Common attack vectors closed at the config layer.
03
Every active plugin checked against known vulnerability databases. Abandoned plugins flagged. Premium plugins verified for license activity. Custom code reviewed for SQL injection, XSS, missing nonces, capability bypasses.
Vulnerabilities patched before exploitation.
04
Admin accounts inventoried. Inactive admins removed. Application passwords audited and revoked where unjustified. Two-factor enforced for admin and editor roles. User session policy hardened.
Account-based attack paths closed.
05
Cloudflare or Wordfence Premium WAF with rules tuned for WordPress. Rate limiting on login, REST, XML-RPC. Bot management for the routes that need it. Real attack traffic blocked before it hits PHP.
Brute force and credential stuffing stop at the edge.
06
Off-site backups verified by test restore. File integrity monitoring active. Failed login alerts wired to Slack. Incident response runbook documented. We have actually responded to incidents, this is not theory.
Detection and response time measured in minutes.
Daily
we scan WordPress sites for vulnerabilities through WP Vanguard
Same patterns we scan for, we harden against. Production proof, not theory.
Process
01
One to two weeks. Full security audit covering config, plugins, themes, users, file permissions, REST endpoints, cron jobs. Output is a prioritized findings report with severity ratings.
You know your real risk surface.
02
Two to four weeks. Findings remediated in priority order. Config changes tested on staging first. Plugin updates rolled out staggered. WAF rules deployed and tuned.
Risk surface measurably smaller.
03
File integrity monitoring active. Failed login alerts wired. Backup restore tested. Incident response runbook documented. Optional retainer for ongoing monitoring.
Detection and response time measured in minutes.
Common questions
Plugins are part of the answer, not the whole answer. They cannot fix bad code in your custom plugins, weak file permissions on your host, missing 2FA on admin accounts, or an exposed wp-config.php. We harden the layers a plugin cannot reach. Then we install the right plugin on top.
We have responded to incidents. Process: isolate the site, take a forensic snapshot, identify the entry point, clean malware, restore from a verified clean backup if needed, harden the entry point so it does not happen again, monitor for thirty days. We have a separate incident response service for this scenario.
We do focused security audits and code review. We are not a CREST-accredited pen test firm. For formal penetration testing or compliance audits (SOC 2, ISO 27001), we partner with specialized firms and feed our hardening work into the audit prep.
No. We test every config change on staging first. The hardening we ship is what WordPress core, WordPress.org, and the hosting community recommend. None of it requires plugin behavior changes. If anything does, we document it and you approve it explicitly.
Each has its own attack surface. WooCommerce: payment gateway misconfiguration, exposed customer data via REST. BuddyPress: privacy controls on profiles and activity. LearnDash: course access bypasses. We cover plugin-specific hardening as part of the audit.
A focused security audit (full report, prioritized findings, remediation plan) are scoped per project. Full hardening engagements are sized depending on site complexity. Incident response quoted separately. Discovery call is free.
Ready to harden your WordPress?
Discovery call is free. Fixed-price quote within 48 hours. Audits are scope-dependent.