B2B services

Hardening a corporate website that a DNS filter was blocking

A customer's corporate DNS filter was rejecting our client's domain, and that stopped the client operating as one of that customer's suppliers. The site was not compromised and not blacklisted. It was simply unhardened. Polargate diagnosed it in a week, migrated the CMS to hosting the client controls, and hardened it there, because the CMS admin panel was the only access available.

A laptop on a meeting room table at night shows a website security report with a grade and a list of headers, a ticked checklist beside it

6
standard security headers missing before the work: 24
pages audited link by link after the DNS cutover, 12 per language: 4
days from award to technical close

The problem

The trigger was not a security incident, it was a commercial block. A customer's corporate DNS filter was rejecting our client's domain, and that stopped the client working as one of that customer's suppliers. Nothing was infected: the diagnosis found no compromise and no blacklist entry. What tripped the automatic classification of low security posture was configuration. The original provider received the list of fixes and formally answered that they fell outside its scope. Around three months were lost in that negotiation before the client changed provider. And the only access available to us was the CMS admin panel.

What we built

One week of diagnosis with public reference scanners: SSL analysis, HTTP header scan, domain reputation, safe browsing and multi-engine antivirus. Then three phases. Migration of the CMS to hosting under the client's control, with functional verification and a pass over URLs and permalinks. Hardening: the six missing headers plus a strict Referrer-Policy, a Permissions-Policy with the sensitive APIs disabled and a server header without a version, along with CMS-level work (login path moved, common paths and files hidden, brute force protection, an application firewall with automatic IP blocking, XML-RPC and discovery endpoints off). Then reputation cleanup. The DNS cutover lowered the TTL 24 to 48 hours ahead and left the mail records untouched.

The outcome

Headers went from F at the initial diagnosis to A+ after hardening, on a forced no-cache scan with no warnings. That reading was taken on the migration host in 2026, before the live domain was cut over, and we hold no record of a re-scan of the live domain afterwards, so we do not present it as a production grade. After the cutover we audited 24 pages, 12 per language, link by link, and found the initial mass URL replacement had been incomplete. Closed in four days from award, with a delivery report and a 30-day technical warranty.

What actually triggered it

Not an incident. A commercial block. A customer's corporate DNS filter was rejecting our client's domain, and a supplier whose website a customer's network refuses to resolve has a business problem, not an IT one.

The brief we were given was "our site looks hacked to them". It was not.

The diagnosis, in a week

We delivered a technical report on security, SSL and reputation, built on public reference scanners: SSL analysis, HTTP header scan, domain reputation, safe browsing and multi-engine antivirus. Anyone can re-run all of them, which is the point.

The conclusion was clear. The site was not compromised and it was not on any blacklist. This was a hardening and configuration problem, not an infection.

TLS was already in good shape before we started: valid certificate, TLS 1.3 active, no weak ciphers, valid chain, forward secrecy. SSL graded A at the initial diagnosis, before we touched anything. Three other things were driving the automatic "low security posture" classification that corporate filters act on:

No HTTP security headers at all. Header grade: F.
An expired, non-matching backup certificate exposed by the shared hosting.
Visible server fingerprints: interpreter version, control panel signature and technology header.

The constraint that decided the architecture

The only access available was the CMS admin panel. No hosting access means server-level hardening is not applicable on the original infrastructure, so migrating was not an aesthetic preference. It was the only route.

The other option was rebuilding the site in code: an estimated three to six weeks, with the domain still blocked for all of them. The migration was reversible and unblocked sooner. The static rebuild stayed on the shelf as a deferred phase.

What changed, exactly

The work ran in three phases: migration with functional verification and a pass over URLs and permalinks, security and configuration hardening, and reputation cleanup.

Headers actually served after hardening

HSTS with includeSubdomains, a Content-Security-Policy, the legacy XSS protection header, nosniff, X-Frame-Options set to SAMEORIGIN, a strict Referrer-Policy, a Permissions-Policy with the full list of sensitive APIs disabled, and a server header with no version in it.

The CMS layer

Internal paths remapped, common paths and files hidden, the login path moved with a custodied emergency URL, brute force protection, an application firewall that blocks IPs automatically, XML-RPC disabled, discovery endpoints switched off and theme detectors blocked. AI crawlers were left allowed on purpose, because search visibility was part of the job.

What we did not do, and will not claim

There was no network WAF and no CDN in this project. The only firewall was the one inside the CMS hardening plugin. On cookies, the site kept its legacy consent plugin and we hold no record of work on cookie flags, so we claim none. On dependencies, the final inventory was around twenty plugins, three of them added by us; no CVE list or vulnerability count was recorded, so we publish no number of vulnerabilities closed.

The DNS cutover

TTL lowered 24 to 48 hours ahead, A record changed, and the mail records (MX, SPF, DKIM and DMARC) left untouched, so corporate mail on the domain never stopped.

How it was measured, and what that measurement is worth

Before: headers F, SSL A. After hardening: A+ on headers, from a scan forced without cache and returning no warnings.

That A+ was read on the migration host, in 2026, before the live domain was cut over. We have no record of a re-scan of the live domain after the cutover, so we do not present A+ as a production result.

This matters beyond one project. A header grade is a dated photograph of one host, not a property the site owns from then on. A new embed, a new plugin, a provider default and the grade moves. If you want to know what a site scores today, scan it today.

The link audit, and why it exists

After the DNS change we audited 24 pages, 12 in each language, link by link. That is where we found the initial mass URL replacement had been incomplete. References to the staging environment had survived in the global footer, in the page builder CTAs, in the consent links inside forms, in several PDFs, in legal texts, and in a theme icon font that was returning an error.

The reusable lesson: a mass replacement can run in dry-run mode and be assumed done. A change is not done until a real request against the live site proves it.

Close, and what we do not claim

The project closed with a delivery report as a PDF, the technical work complete, a clean link audit and a 30-day technical warranty. Four days from award to technical close. Four months from the original incident, of which around three were lost negotiating with the previous provider.

Two things we deliberately do not claim. We have no record that the customer lifted the DNS block. And the reputation review requests filed at the end were still pending at close, with no outcome recorded.

The method, in order

The order is the method, and the order is the part that transfers to the next site. Measure with public tools anyone can re-run. Fix the configuration rather than the story. Measure again, naming the host and the date of the scan. Then audit against the live site instead of against the plan.

Build →Care →Corporate groups →

FAQ

Questions about this project

Can you fix a website that a corporate DNS filter is blocking?

Usually the block is about security posture, not infection. In this case the public scanners found no compromise and no blacklist entry: TLS was already sound, but the site served no security headers, the shared hosting exposed an expired backup certificate and the server advertised its versions. Those are configuration problems, and they are what an automatic classifier reads. The honest limit: we can fix and evidence the posture, we cannot promise a third party will lift its block, and we have no record that this one did.

Is an A+ security headers grade permanent?

No. A grade is a dated reading of one host at one moment, and that is how we publish it. The A+ in this case was measured on the migration host in 2026, on a forced no-cache scan, before the live domain was cut over. We hold no record of a re-scan of the live domain afterwards, so we do not present it as a production result. Grades also move on their own: a new embed, a new plugin or a provider default can change what the site serves. If a grade matters to your buyers, it needs re-measuring on a schedule.

Do you need access to our hosting to harden our site?

To harden it where it lives, yes. Headers, TLS behaviour and server fingerprints are configured at the server, not in the CMS. In this project the only access available was the CMS admin panel, and the incumbent provider formally answered that the fixes were outside its scope, so migrating to hosting the client controls was the only route left. We chose migration over a rebuild because it was reversible and unblocked the client sooner: a rebuild was an estimated three to six weeks with the site still blocked.

Related work

INITIATE

Start the engine

Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price.