We Checked 250 Law Firm Websites. 6 in 10 Leak the Usernames Attackers Need First

Law firms hold some of the most sensitive information a small business can hold. Client files, case details, financial records, privileged conversation. So we wanted to answer a simple question: from the outside, with nothing but a browser, how exposed are the websites sitting in front of all of that?

We checked 250 live law firm WordPress sites. We did not log into anything, we did not run an exploit, and we did not touch a single file. Every check was passive, the kind of thing any visitor’s browser can see. This is the same quick vetting we run before taking over a site we did not build, so we pointed it at a whole vertical to see how common the gaps actually are.

The short version: 184 of the 250 sites (73%) had at least one real, fixable security exposure. 146 (58%) had two or more. And the most common problem is the one a law firm should worry about most.

Six in ten were handing out their usernames

150 of the 250 sites (60%) were publicly exposing their WordPress login names.

WordPress, left at its defaults, can be asked “who writes here?” in a couple of ways, and many sites answer with the exact usernames people log in with. Breaking into a login takes two things: a username and a password. Leak the username and you have given away half the job for free. A brute force attempt stops being guesswork and becomes a targeted one.

For a firm holding privileged client files, that is the front door left on the latch. The fix is small, a config change or a single security plugin setting. The point is that six in ten had not made it.

The rest, with the real numbers

Here is every check we ran, with honest denominators. A few checks could not return a clear answer on every site, so the rates below are out of the sites that actually gave one, not blindly out of 250.

A few of these are worth a sentence each:

• XML-RPC left on, 33% of the 214 that gave a clear answer. An older WordPress feature most sites no longer need, and a long time favorite for brute force and denial of service amplification.
• HTTPS not forced, 4%. Small, but it means a visitor can land on an unencrypted version of the site.
• Open directory listing, 4%. Nine sites left their upload folders browsable, so anyone can walk the files.
• WordPress core was clean. Not one site ran a clearly end of life version, and none leaked its version through the old readme file. On 84 sites we could not read the version at all, which is good hygiene, not a gap. Credit where it is due.
• Missing HSTS header, 75%. We are listing this last on purpose. It is a hardening best practice, not an active exposure, so we did not count it in the 73%. Plenty of “X% of sites are insecure” headlines quietly lean on soft findings like this one. We did not want to.

How we ran this check

The method was deliberately simple, so the numbers are easy to reproduce and hard to argue with.

We started with 250 live law firm websites running WordPress. Every check was made from the outside, as an ordinary visitor, with no login, no exploitation, and nothing a normal browser would not already request. Here is exactly what each of the six checks looked for:

• HTTPS enforced. We requested the site over plain http and checked whether it redirected to https with a valid certificate. A site failed if it served content without forcing a secure connection.
• WordPress core current. We read the version where the site disclosed it, through the generator tag, the /readme.html file, or the feed. A site failed if it ran a clearly end of life version or published its version through the old readme file. Where the version could not be read at all, we marked it not checked rather than guess.
• Username exposure. We requested the public users endpoint at /wp-json/wp/v2/users and tried the author archive at /?author=1. A site failed if either one returned a real login username.
• Open directory listing. We requested /wp-content/uploads/ and checked whether the folder returned a browsable file index instead of blocking it.
• XML-RPC enabled. We requested /xmlrpc.php and checked whether it responded as active.
• HSTS header. We checked whether the secure response included a Strict-Transport-Security header.

Each check ran on every site, so the per check rates use honest denominators: the number of sites where that check returned a clear answer, never rounded up to the full 250. No site is named anywhere, and the published dataset carries no identifying detail.

Why this matters even if you do not run a law firm

These are ordinary small business WordPress sites. They are exactly what lands on your desk when a client switches agencies, when a freelancer goes quiet, or when you inherit a build nobody documented. You take the site over, and you quietly take over whatever was left exposed on it too.

Most of this is invisible from the front end. The site loads, the forms work, the client is happy. The exposure is sitting in places nobody looks until something goes wrong, and by then it is your name on the support ticket.

So before you agree to take a site on, vet it from the outside the way we did. A few of these you can check in your own browser in under ten minutes:

• Visit /wp-json/wp/v2/users and see whether it returns usernames.
• Try /?author=1 and watch whether it redirects to a real login name.
• Open /wp-content/uploads/ and see whether the folder is browsable.
• Check that http redirects to https.
• Load /xmlrpc.php and see whether it answers.

Ten minutes tells you what you are about to be responsible for.

If you would rather not run it yourself

That is part of what we do as a white-label WordPress team. We will run a deeper version of this check on a site you are about to inherit or already manage, and John reviews every report personally before it reaches you. No charge, and no pitch stapled to it. If a site you have already taken on is in trouble, our WordPress project rescue service is built for exactly that.

A few honest notes

A security report is only as good as its caveats, so:

• This was 250 law firm sites we selected, not a random sample of every firm online. Read it as “across the 250 sites we looked at,” not “of all law firms.”
• Every check ran from the outside and passive only. No logins, no exploitation, no plugin or theme vulnerability scanning, no malware checks, no email or DNS checks. Only what a visitor can see.
• The per check numbers use honest denominators. XML-RPC, for instance, ran cleanly on 214 of the 250, so its 33% is out of 214, not 250.
• Everything is anonymized. No site is named, and no finding carries an identifying detail.

If you run an agency and you are taking on sites you did not build, this is the kind of thing worth checking on day one. It is almost always quick to fix once you know it is there.