--- title: "Security hardening · Polargate" description: "Hardening for websites and applications that are already in production: headers, content policy, HSTS, cookies, TLS, dependencies and tenant isolation…" url: https://polargate.ai/services/care/security-hardening locale: en publisher: POLARGATE S.L. --- Care // Take a site that is already live and put its defences up, measured before and after. # Security hardening Hardening for websites and applications that are already in production: headers, content policy, HSTS, cookies, TLS, dependencies and tenant isolation, with a measured grade at the start and a second measurement at the end. Every number in the report carries the host it was measured on, the date and the tool that produced it. In short Polargate hardens sites and apps that are already live. We measure the starting posture (HTTP headers, SSL and TLS, domain reputation), close what is missing (headers, HSTS, content policy, cookie flags, server fingerprints, the application layer and tenant isolation in the database), and measure again at the end. In one engagement the header grade went from F to A+, measured on the staging host before the DNS change, while SSL was already at A before we touched anything. A grade is a photograph of one host on one date, so the report always says which host and when. ## 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. What you get - A measured starting diagnosis: HTTP headers, SSL and TLS, domain reputation, safe browsing and multi engine scanning, each reading labelled with its tool and date - Headers actually served, not just configured: HSTS with includeSubdomains, a content security policy, nosniff, X-Frame-Options, a strict Referrer-Policy and Permissions-Policy with the sensitive browser APIs disabled - A review of TLS version and ciphers, certificate chain, any backup certificate the hosting exposes, and cookie flags (Secure, HttpOnly, SameSite) - Application layer hardening: server fingerprints hidden, brute force protection on the login, an application firewall with automatic IP blocking, and legacy discovery endpoints turned off, with AI crawlers deliberately left allowed - An inventory of dependencies and extensions with the version of each one recorded - Tenant isolation when the database holds several customers: row level security on every table with a tenant column, and a guard that discovers tables instead of listing them, running in continuous integration - A hosting or DNS move with chain of custody when there is no other route, mail records left intact, followed by a page by page link audit against the live site - A delivery report with the before and after grade, the host and date of every measurement, and a 30-day technical warranty Engagement Timeline The diagnosis arrives within a week of getting access. On a small site the hardening itself has taken around twelve effective hours, spread over two intensive sessions plus one audit session, and four days from go ahead to technical close. If the hosting has to move, add the TTL reduction 24 to 48 hours in advance and the page by page link audit after the switch. One warning from experience: the same project took four months end to end, and around three of those went on negotiating fixes with the previous provider before the client changed supplier. Team Two people, and neither of them sells. Pedro Ciordia, founder and CTO of Polargate, runs the diagnosis, the hardening and the verification himself, and brings in specialists from the studio's network when the work needs them. The person who measures your site at the start is the person who measures it again at the end. Price Fixed price per engagement, quoted after the diagnosis and split into three phases: diagnosis, hardening, and closing with the link audit and the report. Keeping the posture up afterwards runs as a monthly maintenance fee. We do not sell this by the hour. Stack - Vercel - Supabase ## Proof Elite Smart Build ### A custom operating system for Elite Smart Build Elite Smart Build, a Spanish hotel refurbishment contractor working in more than twenty countries, ran every site on spreadsheets and email. Polargate replaced that with eleven modules on Supabase and React: daily Gantt, role-masked margins, per-department alerts and material reception with automatic incidents. 2026 Read the case [A custom operating system for Elite Smart Build](https://polargate.ai/work/hotel-refurbishment-operating-system) FAQ ## Questions, answered Can you secure a site that is already live without rebuilding it? Usually yes, and rebuilding is often the slower answer. In one engagement we put a rebuild in code at three to six weeks, with the domain blocked by a corporate DNS filter the whole time, while migrating the CMS to hosting the client controlled and hardening it there was reversible and got the fixes live far sooner. We rebuild only when the platform itself is the problem, and when we do, it goes in as a separate later phase, not as the price of getting the headers right. Why would a corporate filter block my domain if my site is not infected? Because those filters score configuration, not only infection. In the engagement we describe on this page the diagnosis was clear: the site was neither compromised nor blacklisted, and its SSL already scored A before we touched anything. What was triggering the automatic "low security posture" verdict was three things: no HTTP security headers at all, an expired and non matching backup certificate exposed by the shared hosting, and server fingerprints on show. The header grade at that point was F. That is a configuration problem, and configuration is fixable in days. 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. [Start your project](https://polargate.ai/start) · [Talk to us](https://polargate.ai/start#static-brief-heading)