WordPress security audit
Map access and reduce the attack surface (check first)
WordPress security audit — When a WordPress site gets compromised, the entry point is very often… an access. Even before inspecting the code or plugins, an effective audit starts with mapping accounts, roles, and authentication points. The goal is simple: drastically reduce the number of exploitable paths and make every intrusion attempt costly.
Start by inventorying all WordPress users (including those who no longer log in). Identify generic admin accounts, outdated emails, accounts shared between multiple people, and especially accounts whose role is higher than necessary. The principle of least privilege applies: an editor doesn’t need to be an administrator, a one-off contractor shouldn’t keep elevated rights once their assignment is completed.
Then check the security of the login page: password policy (length, complexity, uniqueness), enabling two-factor authentication (2FA), attempt limits (anti-brute force), and the presence of an anti-user-enumeration mechanism. Enumeration makes it possible to discover valid logins, then launch targeted brute-force attacks.
Finally, review access outside WordPress that sometimes bypasses protections: FTP/SFTP, SSH, hosting panel, phpMyAdmin, webmail. A compromised hosting account often amounts to a total compromise of the site. In your audit, require individual access (no shared account), unique passwords, and ideally strong authentication on the host side.
Updates, dependencies and components: the heart of prevention
A relevant audit checks not only whether everything is up to date, but also what needs to be updated, what should no longer be present and what is maintained. In WordPress, the majority of compromises exploit known vulnerabilities in plugins and themes, sometimes patched for months.
Check the version of WordPress (core), the active theme, and all plugins. Also note disabled items: a plugin that’s disabled but still installed may remain exploitable depending on the vulnerability, or be reactivated by an attacker who has already gained admin access. The safest rule: delete what you don’t use.
The trickiest part is removal without breaking functionality. Before removing a component, identify its exact role (shortcodes, widgets, blocks, scripts, integrations). Prepare a rollback plan. For a clean, progressive method, you can rely on this internal guide: How to Safely Remove Outdated Plugins.
In the audit, add an often-forgotten criterion: the health of the plugin/theme. Date of last update, stated compatibility, frequency of fixes, reputation, existence of active support. An abandoned plugin is a security debt.
Check file integrity and detect suspicious modifications
A site can be up to date and still infected. The audit must therefore include an integrity check: presence of unknown files, modifications in sensitive files, backdoors, webshells, injections in the theme or in mu-plugins.
Discover our offers for WordPress website maintenance
Points to absolutely check:
– The folder wp-content/uploads : it should not contain executable PHP files. The presence of scripts in there is a strong signal (often linked to a backdoor).
– Files wp-config.php and .htaccess : look for unknown redirects, abnormal execution rules, or additions of obscure code.
– Directories wp-includes and wp-admin : they must not contain unexpected files. Any anomaly deserves investigation.
– Theme files: injections into functions.php, header.php, footer.php, or files with a legitimate-sounding name but obfuscated content.
Also check scheduled tasks (WP-Cron): malware latches onto them to reinstall itself or relaunch actions. A serious audit examines cron events, unknown recurring actions, and suspicious external calls.
Server hardening: permissions, PHP, headers, and isolation
WordPress security is not limited to the dashboard. An audit must assess the hosting environment, because an overly permissive configuration can turn a small flaw into a full compromise.
File and write permissions
Check permissions: no directories in 777, no critical files writable by everyone. The exact permissions vary depending on the configuration, but the idea remains the same: limit write access to the necessary directories (uploads, cache, possibly logs) and lock down the rest.
PHP version and modules
Check the PHP version, loaded modules, and configuration. An outdated version increases risk, as do dangerous functions enabled without necessity. Also check error handling (display_errors): showing errors in production can reveal paths, SQL queries, or even secrets.
Security headers and HTTPS
Make sure the site enforces HTTPS, that cookies are secure, and that headers like HSTS, X-Content-Type-Options, X-Frame-Options (or CSP), Referrer-Policy are correctly configured for the context. The goal: reduce XSS vectors, clickjacking, and information leaks. A pragmatic audit doesn’t apply everything at full strength without checking the impact (CSP can break integrations if it’s misconfigured).
Isolation and segmentation
If several sites share the same hosting, an audit must verify isolation (separate accounts, permissions, separation of PHP pools, no shared writeable folders). Otherwise, the compromise of one site can contaminate the others.
Database security: accounts, privileges, and signs of injection
The database is a critical asset: it contains users, password hashes, sessions, content, options, API keys sometimes stored in plain text. A WordPress security audit must therefore verify:
– The MySQL account used by WordPress: it must not have more privileges than necessary. In many cases, it has overly broad rights across the entire server.
– The database credentials: unique, strong, not reused. Also check whether SQL backups are circulating in publicly accessible folders.
– The table wp_options (or its equivalent if a custom prefix): this is often where persistent injections hide (autoload options, encoded code, abnormally long values).
– WordPress users: spot unknown accounts, privilege escalations, or unexplained changes of email and password.
Add a consistency check: a spike in autoload options can indicate abnormal additions. This point also has a performance impact, and performance and security often intersect (a slow site sometimes masks malicious activities in the background).
Security plugins, WAF, logging: verify real effectiveness
Installing a security plugin is not enough: the audit must verify that it is configured, up to date, and above all that it produces actionable signals. Silent security is rarely effective security.
Check:
– Existence of a WAF (at server, CDN, or plugin level) and its mode (detection vs blocking).
– Anti-brute-force settings (lockout, CAPTCHA, allowlists if needed).
– Logging of logins (successful/failed), file changes, modifications to sensitive settings.
– Alerting: who receives the alerts, and are they actually reviewed? An audit must verify the operational chain (otherwise, alerts end up being ignored).
– Log retention and compliance: keep long enough to investigate, without unnecessarily exposing sensitive data.
Backups and restore: the test that reveals hidden flaws
Backup isn’t a nice-to-have. It’s the final safety net. In an audit, we don’t just check that a backup plugin is enabled: we verify that we know how to restore, quickly, cleanly, and without depending on a single person.
Minimum checklist:
– Appropriate frequency (showcase site vs e-commerce vs media).
– Offsite backups (not only on the same server).
– Sufficient history (retention) and multiple versions.
– Backup files + database + possibly server configuration.
– Restoration procedure documented and tested.
The key test: simulate a restore on a staging environment. If you’re looking for a simple, operational procedure, see: Restore a Site in Under 10 Minutes.
Discover our offers for WordPress website maintenance
Scan for vulnerabilities… and interpret the results without false positives
A serious audit combines manual checks and automated tools. Scanners (vulnerabilities, malware, configuration) save time, but they can produce false positives or miss stealthy attacks.
In your approach, favor a layered approach:
– Scan versions (plugins/themes) against known vulnerability databases.
– File analysis (signatures + heuristics) to spot obfuscation, suspicious calls, dangerous functions.
– Configuration audit (HTTPS, headers, directory indexing, exposed endpoints).
– Log review (server and application) to look for attack patterns.
To complete your checklist with actionable items, you can cross-reference external resources such as WordPress security audit: 7 checks to perform, then adapt according to your context (traffic, data, business constraints).
Check forms, uploads, and business entry points
Contact forms, registrations, quote requests, comments, and upload areas are major attack surfaces. The audit must validate:
– Anti-spam and anti-bot protection (without unduly degrading the user experience).
– Server-side validation (not only browser-side): allowed file types, size, extension, MIME checking, renaming, storage outside the executable path if possible.
– Protection against XSS and injections: text fields, HTML fields, WYSIWYG editors, shortcodes.
– Notifications: avoid exposing sensitive information (e.g., emails containing too many technical details).
If your site handles payments, customer accounts, or personal data, the audit must include a review of critical pages (checkout, customer area, AJAX endpoints) and the associated permissions.
Endpoints, REST API, XML-RPC, and unintentional exposure
WordPress exposes useful endpoints, but they can be misused depending on the configuration. The audit must check:
– REST API: what content is accessible without authentication? Are private content types properly protected?
– XML-RPC: is it necessary? If not, disabling it can reduce certain risks (distributed brute force, pingbacks). If yes, limit it and monitor its usage.
– Debug pages and plugin endpoints: some plugins leave routes or admin pages accessible unexpectedly.
– Exposed files: readme, changelog, directory listings, backup endpoints.
A good audit doesn’t automatically shut everything off: it documents usefulness and impact, then applies a gradual reduction of exposure.
Performance and security: weak signals not to ignore
A sudden performance degradation can be a symptom: cryptomining, spam, malicious requests, bots, or overload due to a brute-force attack. Conversely, poor performance can lead to risky choices (disabling protections, leaving caches misconfigured, exposing directories). The audit should therefore include a security-oriented performance component.
Check CPU/memory spikes, the origin of requests, the pages being hit, bursts of 404 errors, and the volume of POST requests. To structure this diagnosis, you can consult: How to Analyze Your Site Speed Tools Method.
And to avoid the classic pitfalls (stacked cache plugins, unoptimized images, uncontrolled third-party scripts) that harm stability as much as security, this internal resource complements the audit well: The Most Frequent Performance Errors.
Special cases: multilingual, staging, and multiple environments
Multilingual sites often add major plugins (translations, SEO, URL management, content synchronization) and multiply the attack surfaces: more routes, more content, more editors, sometimes more integrations. An audit must verify that additional languages do not create unexpected paths (e.g., unprotected pages, redirects, duplicate content exploitable for phishing, etc.).
If your site is affected, also anticipate the technical risks specific to these configurations via: Multilingual Technical Issues to Anticipate.
Another point: staging and pre-production environments. They are often less protected (weak passwords, active indexing, debug plugins, verbose logs). Yet they sometimes contain a copy of the production database. An audit must verify access (auth), indexing (noindex), and separation of secrets (different API keys between staging and production).
Discover our offers for WordPress website maintenance
Action plan: prioritize fixes and prove risk reduction
A useful audit doesn’t stop at a list of issues. It produces a remediation plan prioritized according to: exploitability, impact, exposure, and effort. A critical vulnerability in a publicly exposed plugin takes priority over a low-risk hygiene improvement. Categorize actions into three levels:
– Urgent (24–72h): suspicious accounts, malware, exploited vulnerable plugin, unmanaged hosting access, no backups.
– Important (1–2 weeks): server hardening, privilege reduction, removal of unnecessary components, 2FA, WAF, logs.
– Continuous improvement (monthly/quarterly): dependency review, restore tests, integration checks, monitoring.
To enrich your checklist and avoid blind spots, you can compare your method against structured approaches such as The 7 Critical Points Nobody Checks – AlmaWeb or even a more operational format geared toward quick checks: Express WordPress Audit: 13 Checkpoints + Real Case.
Finally, if you’re looking for a complementary overview (with a step-by-step approach) to compare your results, this external resource can help validate your coverage: How to check the security of your WordPress site.
Make auditing routine: maintenance, monitoring, and accountability
WordPress security is not a one-time event: it’s a routine. The best audit in the world loses its value if the site isn’t maintained, if alerts aren’t read, or if updates are postponed without a process.
Establish a cadence: weekly review of updates, monthly check of accounts and plugins, quarterly restore test, and a more comprehensive audit at regular intervals (or after every major change: new theme, redesign, migration, addition of a critical plugin).
If you want to outsource all or part of this routine with a clear framework (updates, monitoring, backups, interventions), you can consult: Discover our site maintenance offers.
A well-conducted audit does not aim for theoretical perfection. It aims for a site that is sustainably maintainable, a reduced attack surface, faster detection, and a proven restoration capability. It is this trio (prevent, detect, recover) that really makes the difference.
