Your Web Developer Isn’t Telling You This

The security flaws, GDPR violations, and missing protections your developer probably didn’t mention. Not because they’re dishonest — because nobody asked.

You paid someone to build your website. Maybe a freelancer, maybe an agency, maybe your mate’s kid who’s good with computers. It looks nice. It works. You’re happy.

But there’s a list of things they probably didn’t do and definitely didn’t mention. Not because they’re trying to rip you off — most of the time they just don’t think about it. They’re designers, not security people. They build things that look good and function. The boring stuff underneath gets skipped.

Here’s what I keep finding when I audit small business websites.

Your email can be spoofed

When I check a business domain, the first thing I look at is email authentication. Specifically three things: SPF, DKIM, and DMARC.

These are DNS records that tell email providers “these are the only servers allowed to send email from our domain.” Without them, anyone can send an email that looks like it comes from you@yourbusiness.co.uk and most email systems won’t flag it.

I recently audited a local organisation and they had no DMARC record at all. Someone could send an email to their customers saying “your invoice is attached, please pay immediately” and it would look completely legitimate.

Your web developer didn’t set this up because it’s not part of building a website. But it’s part of owning a domain. And if you’re sending invoices, quotes, or order confirmations from that domain, it matters.

Takes about 15 minutes to fix. It’s a DNS record. Your domain registrar will have a guide.

Your admin panel is open to the world

If your site runs on WordPress, go to yourdomain.com/wp-login.php right now. Can you see the login page? So can everyone else.

Every website I audit has the admin login sitting on the public internet. No IP restriction. No two-factor authentication. No rate limiting. Just a username and password between an attacker and full control of your website.

I found one site where the WordPress REST API was also exposing every user account. You could visit a specific URL and get a list of usernames. Combined with the open login page, that’s half the work done for an attacker.

Your tracking is illegal

I don’t mean this dramatically. I mean it literally. Under UK law (PECR), you need explicit consent before setting non-essential cookies. On every site I’ve audited so far, Google Analytics and/or Facebook Pixel fire before the cookie consent banner appears.

Your developer probably pasted the tracking code into the header because that’s what the Google or Facebook instructions say to do. They didn’t think about the consent flow because, honestly, most developers don’t.

But here’s the thing — if your analytics are firing before consent, your data is also wrong. You’re counting visitors who never agreed to be counted. Your conversion rates, your traffic numbers, your ad targeting — all based on polluted data.

Your security headers are probably missing

There’s a website called securityheaders.com. Go there, type in your domain. If you get anything less than a B, your developer left out security headers.

These are invisible settings that tell browsers how to behave when loading your site. Things like:

• Don’t let other sites embed my site in a frame (prevents clickjacking)
• Only load scripts from trusted sources (prevents injection attacks)
• Always use HTTPS (prevents downgrade attacks)
• Don’t send referrer data to third parties (prevents data leakage)

Most small business websites score an F. Not because they’ve been configured badly, but because they haven’t been configured at all. Nobody thought to add them.

I audited a school website recently. Their site had zero security headers. The portals they linked to for student records had all of them. The school’s own website was the weakest link in its own security chain.

Your PHP or WordPress version might be ancient

One site I audited was running PHP 7.0.33. That version hasn’t had a security patch since December 2018. The server was broadcasting the version number in its headers, telling attackers exactly what to target.

Another was running a WordPress version from 2021 with known vulnerabilities.

Your developer built the site and moved on. Unless you’re paying for maintenance, nobody is updating the software underneath. It just sits there, getting older and more vulnerable every month.

What this means

I’m not saying your web developer is bad at their job. Building a good-looking, functional website is a skill. But security, compliance, and email authentication are different skills, and they’re rarely included in a website build unless you specifically ask for them.

The problem is that nobody tells you to ask.

So here’s the shortlist. Ask whoever built your site:

1. Is our admin login restricted or protected with two-factor authentication?
2. Do we have SPF, DKIM, and DMARC records set up?
3. Do our analytics scripts wait for cookie consent before firing?
4. What score do we get on securityheaders.com?
5. What version of PHP or WordPress are we running, and is it still supported?