Skip to content

03.03 / Care

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.

modules delivered in Phase 1Elite Smart Build
11
A monitor late at night: the security audit of a logistics company's platform, with findings by severity, who handles each one and its status, and the list of controls reviewed.

In detail

What you should know.

A man in a white shirt pulls a locked drawer full of files from a wall of dark filing cabinets, a glass partition and a lit desk behind him

For example: 11 modules delivered in Phase 1. Elite Smart Build

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 the client wanted to keep working smoothly 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 has to be tested. 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 real tenants found no cross tenant read. On another platform we hardened, the database security advisors and the row level policies with a performance warning both sit at 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 fixes were outside the scope of the original hosting service, so the client moved to a new 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 customer lifts its filter is the customer's call, 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 caught and fixed every staging reference the first bulk URL replacement had left behind: in the global footer, in the page builder CTAs, in the form consent links, in several PDFs, in legal text and in a theme icon font. 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 to close gaps that can be measured, and to measure them again at the end.

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

What you take away.

Everything is written down before we start, and everything stays in accounts your company owns.

01Deliverables

  1. 01

    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

  2. 02

    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

  3. 03

    A review of TLS version and ciphers, certificate chain, any backup certificate the hosting exposes, and cookie flags (Secure, HttpOnly, SameSite)

  4. 04

    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

  5. 05

    An inventory of dependencies and extensions with the version of each one recorded

  6. 06

    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

  7. 07

    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

  8. 08

    A delivery report with the before and after grade, the host and date of every measurement, and a 30-day technical warranty

02How it runs

  1. 01 · Week 1 to 2

    Takeover and baseline audit

    We take access to the repository, hosting, database, domain and analytics, then audit the live site from the outside and the code from the inside. You get a ranked list of findings and a short risk register, so you see the real state of what you own before anything is touched.

  2. 02 · Week 2 to 4

    Close the critical findings

    Critical issues go first: security headers, exposed permissions, soft 404s, broken indexation, performance blockers. Each fix travels as a reviewed pull request and is deployed with your approval, so the retainer starts from a clean, known baseline instead of inheriting debt quietly.

  3. 03 · Every month

    The monthly cycle

    Tickets flow through the ServiceDesk against your hour pool, the scheduled audit runs over the live site and the repository, and the fix agent proposes changes as pull requests. A human reviews and merges. At the end of the month you get a report of what changed, why and at what cost in hours.

  4. 04 · Every quarter

    Review and re-plan

    Every quarter we look at consumption, recurring issues and what the product needs next. The hour pool is resized up or down to match reality, evolution work is agreed as a small roadmap, and anything that has grown into a project is quoted separately instead of eating the retainer.

For example: 23 Postgres tables with row-level security forced. Elite Smart Build

Who it is for

We don't take every project.

We would rather tell you now than halfway through. If you recognise yourself on the left, let's talk.

It fits if

  • You have software in production that your business needs every day
  • You want a senior team that answers, not a ticket queue with no owner
  • You prefer a known monthly fee to surprise hourly invoices
  • You are fine with an agent proposing fixes as long as a person reviews every change

It is not for you if

  • You need round-the-clock cover with a response in minutes
  • You want changes in production without anyone reviewing the diff
  • You are only looking for cheap hosting
  • Nobody can give us access to the code or the servers

For example: ~1 month from development start to first testable version in production. Elite Smart Build

Timing and budget

How we quote.

No price list and no hourly billing during a build. After a short call you get a written quote for your project.

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.
Team
Our team runs the diagnosis, the hardening and the verification, and the people who measure your site at the start measure it again at the end. Pedro Ciordia, CTO, reviews the findings and every change before it reaches production.
How the price is set
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.
The stack
VercelSupabase

For example: 10 role-based accounts live on the client's own domain. Elite Smart Build

Work

Where we did it.

Real projects. Open each one to see what we built and the figures we measured.

For example: 59 audit findings confirmed and fixed before client testing. Elite Smart Build

Same line

Other services in Care.

Each service has its own page with what it includes, the usual timeline and the projects where we did it.

For example: 11 modules delivered in Phase 1. Elite Smart Build

FAQ

What people ask us.

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.

For example: 23 Postgres tables with row-level security forced. Elite Smart Build

Get started

Tell us what you want to build.

Websites, apps, custom systems and AI for companies that need them in production in weeks. Fill in the form or book a 30 minute call: a senior engineer answers within 48 business hours with a first take on scope, timeline and price.

What do you need?
Budget
When

At least ten characters.

Answer in writing within 48 business hours. No newsletter, no automatic sequence.

Rather answer the full brief?

First step

Discovery Sprint

Two weeks to close scope, architecture and price before anything is built.

No price list. You get a private quote, in writing, after a short call.

Then, to build, always at a fixed price

Not ready yet?

AI-native digital studio for mid-market companies

POLARGATE, S.L. · CIF B24895005
Calle Electrónica 6, 28027 Madrid, Spain