Security audit

Close the doors you did not know were open.

Most WordPress breaches do not start with a clever attack. They start with an outdated plugin, a forgotten admin account or an endpoint nobody switched off. I find those before someone else does.

When it is time

Sounds familiar?

  • Nobody can say for sure which plugins are still maintained
  • Admin accounts of former staff or agencies still exist
  • The site was hacked once, and nobody is sure it is really over
  • A customer, an insurer or an auditor asks how the site is secured

The audit

What I check.

Remote and read-only. You get a written report with every finding, its risk and the effort to fix it.

  • Core, plugins and themes: versions, known vulnerabilities, abandoned code
  • Users, roles and capabilities, including custom ones
  • Exposed endpoints: XML-RPC, user enumeration over REST, debug output, directory listings
  • Custom code: escaping, sanitizing, nonces and capability checks
  • Secrets: keys and passwords in the repository, the database or wp-config.php
  • HTTP security headers and the TLS setup
  • File permissions, uploads and what the web server may execute
  • Backups, logs and how fast you would notice an incident

Start with the free check: it already tests HTTPS, the security headers and whether your WordPress version is exposed. Seconds, no access needed.

The fix sprint

What a sprint typically closes.

Fixed scope and price, agreed before we start. Every change arrives as a pull request that you review and merge.

  • Remove or replace abandoned plugins
  • Clean up accounts and roles, with two-factor login for administrators
  • Fix escaping and permission checks in custom code, with tests
  • Set security headers at the server or CDN, not by plugin guesswork
  • Move secrets out of the code and rotate them

FAQ

Questions I get asked.

Is this a penetration test?

No. A penetration test attacks the site from the outside. The audit reads code and configuration from the inside, which finds a different and often larger set of problems. If you need a penetration test for compliance, do the audit first, so you do not pay for findings you could have fixed already.

Will you install a security plugin?

Only if it solves a real problem. Most of the work is removing risk, not adding another layer that needs updates too.

What if you find an active compromise?

Then the audit pauses and the incident comes first: contain it, clean up, find the way in and close it. You decide on every step.

Let’s make your WordPress boring. In the best way.

Tell me about your site. You get an honest answer, even if it is “you don’t need me”.