State of cyber hygiene · Cambridge · October 2026
State of cyber hygiene in Cambridge
89 small businesses in Cambridge publish a website on a domain they own. Over the last week of October 2026 I checked every one of those domains the way a stranger on the internet could: public DNS records, one visit to the home page over HTTP and one over HTTPS, the response headers, and the certificate. No logins, no scanning. Nothing past the home page was touched, and this is what the public footprint of Cambridge's small-business economy looks like.
The headline findings
Every number here comes from the public-facing side, public DNS records and a single visit to each home page, collected October 27, 2026. No business is named. This is not name and shame. It is meant to draw attention to things we do not normally pay attention to. The sections that follow break each figure down by sector, town, and platform, and the method note at the end explains exactly what was checked, and what was not.
- A critical flaw in PHP, the software that runs most of the web, was disclosed on October 21, 2026 and is already being exploited. It hands an attacker control of the server with no password needed, and the US cyber agency ordered federal systems to patch it by October 29. At least 5 small-business sites in Cambridge are advertising a PHP version that is either unpatched against this bug or on a release line that will never get a fix. That is a floor, not a ceiling: most sites hide their version, so the real number is higher.
- 89 small businesses in Cambridge with a website of their own were checked from the outside for this report, the way any visitor could. Local firms, shops, trades, clinics, and contractors, not chains or government.
- 65 of them (90%) can be impersonated in email. Without an enforced DMARC record, a scammer can send an invoice or a quote that looks like it came from the business, and the customer's mail provider has nothing to stop it. Only 7 (10%) have that protection turned on.
- 37 of these sites run WordPress. Of the 20 that publish their version number, 7 are behind on security updates, and 5 sites across the sample still load a code library that stopped getting fixes in 2016. 9 of them take card payments through WooCommerce on that same software.
- 73 sites (86%) have HTTPS set up properly. The other 12 reachable sites do not fully, and 1 serve a broken, expired, or missing certificate, so a customer typing in a card number or a password cannot be sure who is receiving it.
- 8 business domains have no SPF record at all, the most basic of the email checks. Anyone, anywhere, can send mail as those businesses with nothing to flag it as fake.
- 4 domains these businesses are still listed under no longer work, and 2 more show a parking or placeholder page. An abandoned domain can be re-registered by anyone, who then receives the email meant for that business.
- Scored across every outside check, the typical business in Cambridge lands at 66 out of 100. 10 earned an A. 0 failed outright.
Most domains can be impersonated by email
72 of the 89 domains accept email (they publish an MX record). Of those, 64 (89%) publish an SPF record. 8 don't. Without SPF, any mail server on earth can send as that business and the receiving side has nothing to check it against. DMARC, the record that tells receivers what to do with mail that fails the checks, exists on 30 domains (42%), but only 7 (10%) set a policy of quarantine or reject. The other 23 sit at p=none, which is monitoring mode... the record is there, it just doesn't do anything to a forged message.
6 have neither SPF nor DMARC. 3 (4%) have the full set that mail providers now expect from senders: SPF, a DKIM signature at a standard selector, and an enforcing DMARC policy. Those are the domains whose invoices land in the inbox when Gmail and Microsoft tighten their rules again.
The most common mail platform here is Google Workspace (23 domains). Platform matters less than configuration. Tenants on Microsoft 365 in this sample enforce DMARC 19% of the time and Google Workspace tenants 9%; the defaults on both are p=none or nothing at all, so the numbers reflect whoever set the tenant up, not the vendor.
Invoice fraud against small businesses almost always starts with a message that appears to come from the business or from one of its suppliers. SPF, DKIM, and an enforcing DMARC policy are the 3 DNS records that let the big mail providers drop those messages before a customer sees them. They cost nothing but time.
Of 72 domains that receive mail
DMARC policy
Google Workspace against Microsoft 365
| Of mail domains on each | Microsoft 365 | Google Workspace | Filtered (Proofpoint, Mimecast, etc.) | Host-bundled |
|---|---|---|---|---|
| Domains | 16 | 23 | 10 | 5 |
| SPF present | 100% | 91% | 100% | 80% |
| SPF ends in -all | 88% | 9% | 20% | 0% |
| DMARC present | 50% | 39% | 30% | 40% |
| DMARC enforced | 19% | 9% | 0% | 0% |
| DMARC p=none | 31% | 30% | 30% | 40% |
| DKIM found | 19% | 30% | 40% | 0% |
| SPF + DKIM + enforced DMARC | 6% | 0% | 0% | 0% |
| Mean score | 67 | 61 | 63 | 57 |
All mail platforms
| Platform | Domains | Enforce | p=none | No DMARC |
|---|---|---|---|---|
| Google Workspace | 23 | 9% | 30% | 61% |
| Microsoft 365 | 16 | 19% | 31% | 50% |
| Other (small host or self-run) | 13 | 15% | 23% | 62% |
| Mail filtering or relay service | 10 | 0% | 30% | 70% |
| Hosting-bundled email | 5 | 0% | 40% | 60% |
| Rackspace | 4 | 0% | 75% | 25% |
| GoDaddy email | 1 | 0% | 0% | 100% |
Nearly every site has HTTPS. Fewer than half use it fully
85 sites answer over HTTPS. 84 of those presented a certificate that validates cleanly; 1 did not (expired, issued for a different hostname, self-signed, or an incomplete chain), and 0 sites answer on plain HTTP only. 74 (87%) redirect a plain-HTTP visitor to the encrypted site. HSTS, the header that keeps browsers on HTTPS after the first visit, is set on 35 (41%).
Most negotiated TLS 1.3 (81) or 1.2 (4) with a modern client, which is the default on current hosting. 0 servers (0% of the 85 that completed the test) still accept a TLS 1.1 handshake. Browsers dropped it in 2020. 42 sites (49%) send none of the 4 basic browser security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy). 12 (14%) announce their web server or PHP version in the response headers; 3 of the 8 that name a PHP version are on a release that no longer gets security fixes (anything before PHP 8.2 as of October 2026).
Of 85 sites answering on HTTPS
On October 21, 2026 the PHP project shipped emergency releases for 2 unauthenticated remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, rated 9.2 and reachable before any application code runs on Apache mod_php. CISA added both to its Known Exploited Vulnerabilities list on October 26; Amazon saw attempts against its honeypots 4 days before the disclosure. Fixed releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 8.1 and older got no release. In Cambridge, 8 sites announce their PHP version in a response header: 3 already show a fixed build, 2 show a supported branch below the fix, and 3 run a branch with no release at all, mostly 7.4.33 and 8.1.34. A version string can lag a distribution backport, so "below fix" means "cannot be ruled out from the outside", and the far larger group of sites that hide the version are unknown either way.
Certificate problems
Certificate issuers
PHP versions announced
Web server as announced
WordPress carries the region, and tells you its version
37 of the 85 reachable sites run WordPress. That's 44%. 20 of them print the exact WordPress version in the page source. 13 are on a supported branch (7.1.3 or 7.0.7 at the time of the check) and 7 are behind it. On its own, a version string is a shopping list for anyone matching known exploits to targets, and hiding it is a one-line change. Loading every site in a real browser cut the unidentified group to 16 by resolving the JavaScript-rendered builders the plain fetch could not read.
11 WordPress sites load Elementor and 9 run WooCommerce, so card data and customer accounts sit on the same install as the brochure pages. 5 sites still ship jQuery 1.x. That library line went end-of-life in 2016. The second-largest group after WordPress is hosted builders (Wix, Squarespace, Shopify, GoDaddy, Duda, Webflow), where the vendor patches the platform; those sites score better on headers and TLS for no effort on the owner's part, and worse on the things the owner still controls, like DMARC.
Plugin names below come from asset paths on the home page, so they undercount anything that doesn't load on the front page. Counts are how many sites load each plugin, not how many are out of date; that can't be read from the outside without probing, which this survey doesn't do.
Platform split, 85 sites
WordPress versions seen
Most-loaded WordPress plugins
Front-end markers
Where the sites live, and what stands in front of them
27 of the 85 reachable sites (32%) answer through Cloudflare, which means the origin server is hidden and the free tier of a web application firewall is at least available to them. Counting Cloudflare, Sucuri, Imperva, Akamai, AWS CloudFront and WAF, Azure Front Door, and Fastly together, 28 sites (33%) have some edge service in front of them. The rest answer straight from the host. For 30 WordPress sites that means the login page, the XML-RPC endpoint, and the REST API are a direct hop from the internet with nothing rate-limiting them.
58 sites show their serving network. 26% of those are served from Canada and 71% from the United States, mostly Amazon and Google plus the big American shared hosts. 11 sites share one of 1 addresses that each carry 10 or more businesses from this sample, which is normal for shared hosting and worth knowing when one of them is compromised. 38 sites negotiate HTTP/3, 78 HTTP/2, and 7 are still on HTTP/1.1 only; 20 domains (22%) have an IPv6 address.
Hosting is identified from the network that announces the serving IP address (Team Cymru's ASN data) and reverse DNS, nothing else. A site behind Cloudflare is listed as Cloudflare because its origin is not visible. Wix, Squarespace, Shopify, and Webflow sit partly on Amazon and Google networks and partly on their own, so the platform counts in section 03 and the network counts here differ.
Serving network
Edge, CDN, and WAF signatures
Country of the serving network
Protocol and transport
What the page loads from other people
Tracker types seen
DNS is where most of the easy wins sit
2 domains (2%) are DNSSEC-signed, and 2 publish a CAA record limiting which authorities can issue their certificates. 4 domains in the directories no longer resolve or don't answer at all, and 2 show a parking or placeholder page; those are mostly businesses that let a domain lapse while directories still list it, which is its own risk when someone else registers it and starts receiving their mail.
DNS hosting
Domain state
Who is doing well, and who isn't
Mean score among scored domains, DMARC enforcement among mail-receiving domains, and clean HTTPS among reachable sites. Groups under 10 domains are left out so a single business can't be picked out of a row.
By sector
| Sector | n | Score | DMARC enforced | HTTPS ok |
|---|---|---|---|---|
| Healthcare/Dental | 10 | 63 | 11% | 100% |
By municipality
| Municipality | n | Score | DMARC enforced | HTTPS ok |
|---|---|---|---|---|
| Cambridge | 81 | 65 | 9% | 99% |
By platform
| Platform | n | Score | HSTS | No headers |
|---|---|---|---|---|
| WordPress | 37 | 62 | 16% | 70% |
| Custom / unidentified | 16 | 59 | 19% | 62% |
| Wix | 12 | 75 | 75% | 0% |
| Squarespace | 9 | 65 | 100% | 0% |
How Cambridge grades out
Each domain that answers gets a score out of 100 from the checks above (40 points email, 40 website, 20 platform disclosure; the method section has the rubric). The 4 domains that no longer resolve are counted in section 05 and left out of the scoring. Across the 85 scored domains in Cambridge the mean is 66 and the median 65. 10 (12%) grade A, which in this rubric means every outside-visible control a small business can set is set. 0 grade F.
Most common findings
Grade distribution
8 changes that cover most of the gap
Every one of these is a DNS record, a header, or a setting in a platform the business already pays for. None of them need new software.
- Publish a DMARC record and move it to p=quarantine, then p=reject, once the SPF and DKIM sources are listed. Most providers document this in under a page.
- Make sure SPF ends in -all (or ~all while testing) and lists only the services that send as the domain. Delete the record for any domain that doesn't send mail and add a null MX.
- Turn on DKIM signing in the mail platform. Microsoft 365 and Google Workspace both leave it off until an admin enables it.
- Redirect HTTP to HTTPS and add an HSTS header. On WordPress that is a 2-line change in the web server config or a setting in the host's panel.
- Remove the version strings: the WordPress generator tag, the Server and X-Powered-By headers. None of them are needed for the site to work.
- Add the 4 basic headers (X-Content-Type-Options, X-Frame-Options or a frame-ancestors CSP, Referrer-Policy, Permissions-Policy). Cloudflare and most hosts can inject them without touching the site.
- Update PHP off 7.x and jQuery off 1.x, or move the site to a host that does it for you.
- Let expired or unused domains go properly: either keep renewing them with a null MX and SPF -all, or accept that the next registrant inherits the name.
Next step
Your own line from this data
Every business in the sample can have its own results, with the fix list for its platform, from the underlying dataset. Media and economic development offices can get the full regional breakdown, including the sector and municipality tables at finer grain, under the same no-names rule.
Book a scoping callOne-page summary (PDF)Media requestsGet in touch
How the numbers were collected
- Sample: 89 businesses listed in public chamber of commerce, BIA, economic development, and municipal directories for Cambridge, kept only when the directory itself published a website on the business's own domain. National chains, government, hospitals, school boards, and franchise corporate sites were excluded. One row per root domain.
- DNS: A, NS, MX, TXT (SPF), _dmarc TXT, DKIM at the selectors each mail platform uses by default plus a short generic list, _mta-sts, _smtp._tls, default._bimi, and CAA, resolved over DNS-over-HTTPS with DNSSEC validation reported by the resolver.
- Web: one request to http://domain/ following redirects, one to https://domain/ (falling back to www), response headers, certificate subject, issuer, and expiry as presented, negotiated TLS version, and a single TLS 1.1-capped handshake to see whether the server accepts it. Platform fingerprints come from the home page HTML only (generator tag, asset paths, well-known builder markers).
- Browser render: each reachable site was also loaded once in a headless Chromium browser as a normal visitor, to read the rendered page (which resolves JavaScript-built sites a plain fetch cannot fingerprint), the trackers it runs, and the third-party origins it loads. One home-page view, no clicks, no form entry.
- Hosting: the serving IP of the final HTTPS hostname was resolved over DNS, then its reverse DNS name and the announcing network (ASN and country) were read from Team Cymru's public DNS service. CDN and WAF signatures come from response header names and cookie names on the home page. One extra request per site fetched /.well-known/security.txt.
- PHP2Shell exposure is read from the version string in X-Powered-By or Server headers only, compared against the fixed releases in the PHP advisory of October 21, 2026. No request was sent that touches either vulnerability. Distributions such as Debian and Ubuntu backport fixes without changing the version number, so an old-looking version is not proof of exposure, and a hidden version is not proof of safety.
- Not done: no vulnerability scanning, no port scans, no login or admin pages, no crawling beyond the home page, no mail sent, no interaction with any form. Everything here is what a browser and a DNS resolver see on a first visit.
- Limits: DKIM is checked at known selectors only, so a domain signing at a custom selector shows as not found. Fingerprints identify a platform from markers on one page and can miss heavily customized installs. Results are a point-in-time read on the date shown and sites change daily. Sector labels are approximate.
- Scoring (100 points): email 40 (SPF present 10, SPF -all 5, DMARC present 10, DMARC quarantine or reject 10, DKIM found 5; domains with no MX are scored on the remaining 60), website 40 (valid HTTPS 15, HTTP to HTTPS redirect 5, HSTS 5, TLS 1.1 refused 5, X-Content-Type-Options 2, frame protection 3, Referrer-Policy 2, enforced CSP 3), platform 20 (no server version in headers 5, no CMS version in page 5, no jQuery 1.x 5, no mixed content 5). Grades: A 85+, B 70+, C 55+, D 40+, F below 40.
- Validation and environment correction: the data was cross-checked against an independent direct-network re-scan of the same domains (1,167 records corrected, 273 confirmed). Two collection-environment artifacts were found and removed. Serving IP addresses that the collection proxy had returned as a placeholder were replaced with the real addresses resolved over DNS. Security headers that the original high-concurrency pass had missed on some responses were recovered by taking, for each site, the union of three careful measurements, since a scan can miss a header that is present but never reports one that is absent. Certificate issuers and site status were checked and found accurate as originally collected.
- No business is named in this report. Each business can get its own line from the underlying data on request.
Author: Hans Study, CISSP, independent network and security consultant, Ontario, Canada. Published as part of the close of Cyber Security Awareness Month, October 2026. Companion reports: London-Middlesex, Sarnia-Lambton, Chatham-Kent, Kitchener-Waterloo, Brantford-Brant, Windsor-Essex. The combined numbers and the 5 fixes are on the series hub.