Security hardening

What this is

We take a website or an application that is already in production and put its defences up, with a measured before and after. You get a starting grade, the list of what is missing, the work itself, and a second measurement at the end.

A site does not have to be hacked to fail a security check. In one engagement the trigger was commercial, not an incident: the corporate DNS filter of one of our client's own customers was rejecting the domain, and that stopped them operating as a supplier. We delivered the security, SSL and reputation report in a week, using public reference tools. The site was neither compromised nor blacklisted. TLS was already in good shape before we started: valid certificate, TLS 1.3, no weak ciphers, valid chain, forward secrecy, and an A on the public SSL test. What was triggering the automatic "low security posture" verdict was three other things: no HTTP security headers, an expired and non matching backup certificate exposed by the shared hosting, and server fingerprints on show (interpreter version, control panel signature, technology header).

What we work on

The edge

Headers are the cheapest defence there is, and the first thing a corporate filter reads. Missing at the start of that engagement: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Actually served after the work: HSTS with includeSubdomains, a content security policy, nosniff, X-Frame-Options SAMEORIGIN, a strict referrer policy, Permissions-Policy with the sensitive browser APIs disabled, and a server header with no version in it. The header grade went from F to A+, measured on the staging host before the DNS change.

We also read the TLS version and cipher list, the certificate chain, any second certificate the hosting exposes on the same address, and the cookie flags (Secure, HttpOnly, SameSite).

The application

Hiding server fingerprints, brute force protection on the login, an application layer firewall with automatic IP blocking, legacy discovery endpoints and remote protocols turned off, and an inventory of dependencies and extensions with the version of each one written down. AI crawlers stay allowed on purpose: hardening should not cost you your visibility in search and in answer engines.

Tenant isolation

When one database holds data from several customers, isolation is not a setting, it is a test. Row level security on every table that carries a tenant column, and a guard that discovers the tables instead of listing them by hand, so a new table cannot be forgotten. On our own multi-tenant platform that guard was watching 81 tables carrying a tenant identifier in August 2026, it runs on every continuous integration build, and its run across two real tenants found no cross tenant read. On another platform we hardened, the database security advisors went from 4 to 0 and the row level policies with a performance problem from 51 to 0.

Moving the site when there is no other way

In that engagement the only access available was the CMS admin panel. With no hosting access, server level hardening simply did not apply to the original infrastructure. The original provider received the list of fixes and answered formally that it fell outside their scope, and around three months went by in that negotiation before the client changed provider.

We put a rebuild in code at three to six weeks, with the domain blocked throughout. Migrating the CMS to hosting the client controls and hardening it there was reversible and got the fixes live far sooner, so that is the route we took. The rebuild stayed as a deferred phase.

What we claim ends where our own work ends. Whether that manufacturer's filter lifted afterwards is the manufacturer's call, we have no measurement of it, and we do not present it as a result.

DNS moves with a chain of custody: TTL lowered 24 to 48 hours in advance, A record changed, and the mail records (MX, SPF, DKIM, DMARC) left untouched so the corporate email on that domain keeps working.

Nothing is done until it is checked live

After the DNS change we ran a page by page link audit over 24 pages, 12 in each language. It found that the initial bulk URL replacement had been incomplete: staging references left in the global footer, in the page builder CTAs, in the form consent links, in several PDFs, in legal text, and a theme icon font that returned an error. The replacement had been run in simulation and taken as done. A change is not done until a real request against the live site says it is.

What a grade is worth

An A+ is a photograph of one host on one date, not a property of the system. The same goes for a clean isolation test: it is true as the result of a dated check, not as a permanent guarantee. So every measurement in the report names its host, its date and the tool, and the scan that counts is the one against the production domain after the switch, not the one against staging.

We do not promise a secure site. We promise gaps that were measurable, measured, closed and measured again.

What you get at the end

A delivery report as a PDF with the before and after, the link audit, and a 30-day technical warranty on the work. If you want the posture kept up rather than checked once, it continues as monthly maintenance.