I Audited 5 Local Business Websites. Here’s What I Found.

Real findings from real audits. Broken Facebook Pixels, exposed admin panels, tracking children without consent, and fingerprinting scripts. No names, just patterns.

I run a small software company in Suffolk. To build my reputation, I’ve been offering free website security and GDPR audits to local organisations. Schools, charities, small businesses, anyone who wants one.

I’ve done enough now to see patterns. The same problems come up over and over again. None of the businesses below are named, but every finding is real.

The sweet shop

A small ecommerce business on Shopify. Nice products, decent website, clearly run by people who care about what they do.

Their Facebook Pixel was broken. It was firing a Purchase event on every page load, telling Facebook that every visitor was a buyer. Purchase value: £0.00. Every time. They were running Facebook Ads with this data, which means Facebook had no idea who their real customers were. Their ad spend was being wasted and they had no way of knowing.

They also had five cookies being set before any consent was given, including a year-long analytics tracker.

The fix took about ten minutes in Shopify settings. They were probably wasting hundreds of pounds a month on broken ad targeting.

The business membership organisation

A well-known local organisation. Professional-looking website. The kind of place you’d expect to have their digital house in order.

Their WordPress installation was exposing user accounts through the REST API. Anyone could visit a specific URL and get a list of every user account on the site, including usernames. Their XML-RPC endpoint was wide open, which is a known brute-force attack vector. No rate limiting, no protection.

Their email security was missing DMARC entirely. Anyone could send an email pretending to be from their domain and most email providers wouldn’t flag it.

They had a login page sitting on the public internet with no protection beyond a username and password. No two-factor authentication, no CAPTCHA, nothing.

They responded within 48 hours and were genuinely grateful.

The school

This one kept me up at night.

Their web server was running PHP 7.0.33. That version reached its end of life in December 2018. Over seven years without a security patch. The server was broadcasting the version number in its HTTP headers, telling anyone who asked exactly which vulnerabilities to target.

The admin login for their content management system was publicly accessible. No IP restriction, no CAPTCHA, no two-factor authentication. Anyone in the world could sit on that page and guess passwords all day.

They had no privacy policy page — it returned a 404 error. No security headers whatsoever. Google Analytics tracking children before consent.

The portals they used for student records — Arbor, Go4Schools — were properly secured by their vendors. Full security headers, firewalls, the works. But the school’s own website, the front door that links to all of those portals, had none of those protections.

The news website

I checked a regional news website as part of a wider look at a media group. What I found was a fingerprinting script that loaded before the cookie consent manager on every single one of their sites.

The script assigned a persistent unique ID to each visitor’s device, tracked every article they read, and sent it all to a third-party server. It ran before the consent banner appeared. Rejecting cookies had no effect because the tracking had already started.

The technology was from a company with 5 employees and accumulated losses of over £2 million. No other major UK news publisher uses it. Just this one media group, across all their sites.

Their own code contained a variable called isTagPreloadedBeforeConsent. They knew.

The charity

A charity website running on an older platform with no SSL certificate on several subpages. Contact forms submitting data over unencrypted HTTP. No DMARC, no DKIM, no SPF record at all — meaning anyone could send emails as their domain with zero checks.

Their donation page was on a third-party platform that was properly secured, but the main website linking to it had none of the basics. A user clicking “Donate” was going from an insecure site to a secure one, which should be the other way around — the whole journey should be secure.

The patterns

After doing enough of these, the same things keep coming up:

Almost nobody has DMARC set up properly. This means anyone can send emails pretending to be from their domain. For organisations that send invoices, order confirmations, or donation receipts, this is a real risk.

Tracking before consent is universal. I have not yet audited a single website where Google Analytics or Facebook Pixel waited for consent before firing. Not one.

Admin panels are left open. Whether it’s WordPress, Bolt, or something else, the login page is sitting on the public internet with nothing but a password between an attacker and full control of the website.

Nobody checks their security headers. It takes 10 seconds to scan a site on securityheaders.com. Most small business websites score an F.

The third-party services are usually fine. Shopify, Arbor, Go4Schools, Stripe — these platforms have proper security teams. The weak point is always the website itself, the bit the business actually controls.

What to do

If you recognise any of this, don’t panic. Most of it is fixable. Some of it is fixable for free. The first step is knowing there’s a problem.