WordPress security audit: what I check, point by point
These are the checks the report runs on a WordPress site, from the outside and from the inside with the connector. Every finding comes with its evidence (the path, the file or the version) and a concrete action:
- Core integrity: every file in
wp-admin and wp-includes compared with the original for your version. - Integrity of the plugins from the official directory, file by file.
- Plugins and theme with published vulnerabilities, with the exact version, disabled ones included.
- Outdated or abandoned plugins compared with the WordPress.org directory.
- PHP files where they don't belong: in
wp-content/uploads and other upload or cache folders. mu-plugins and files that load on their own, which don't show up in the normal plugin list.- Obfuscated code and backdoors:
eval, base64_decode, remote loading and known malware patterns. - Administrator accounts, to spot accounts nobody recognizes.
- Database: scripts injected into options, posts and widgets, and the
siteurl and home options. wp-config.php: debugging (WP_DEBUG, WP_DEBUG_DISPLAY), SALT keys, file editor (DISALLOW_FILE_EDIT), FORCE_SSL_ADMIN and table prefix.- Redirects in
.htaccess based on the visitor's browser or where they came from. - PHP configuration:
display_errors, allow_url_include, expose_php and dangerous functions enabled. - Exposed files:
.zip or .sql backups, .git, .env and debug logs that can be downloaded from the internet. - The outside: HTTPS, security headers,
xmlrpc.php, domain email (SPF, DKIM, DMARC) and blacklists.
On WooCommerce, also the scripts that load in the cart and at checkout. Background in WordPress security; if any of this already points to an infection, the next step is hacked WordPress cleanup.
PrestaShop security audit
Version of the core and of every module, enabled or not, against PrestaShop's advisories and the Friends of Presta list of vulnerable modules; overrides and where they come from; integrity of classes/, controllers/ and the checkout; debug mode, the admin folder and employees. The full list of checks is on PrestaShop security.
Joomla, Drupal and Magento audits
They have their own read-only connector too: a plugin for Joomla (3.10 to 6), a module for Drupal (9 to 11) and a module for Magento 2.4. I check core integrity against the originals for your version, installed extensions or modules with published vulnerabilities, PHP hidden in image folders and forgotten backups in the public web root. The report costs the same as for WordPress or PrestaShop. What's specific to each platform, in Joomla security, Drupal security and Magento security.
Shopify and custom-built sites
On Shopify there's no server to check: the store creates a read-only custom app and with it I review the theme, the apps' scripts and the pages; it's quoted by the hour (more in Shopify security). On a custom PHP site I use a temporary agent that is uploaded by FTP, expires after 72 hours and deletes itself. If there's no PHP (Node.js, Next.js, Python, Ruby, .NET, Java, Go…), the external scan is completed with the project's dependency files (package-lock.json, composer.lock, poetry.lock…) to check the libraries against published vulnerabilities and see whether the framework is still supported. That covers a security audit for a custom PHP, Laravel or Node.js site too.