Beveiliging en hardening

Wat dit is

We nemen een website of applicatie die al in productie draait en zetten de verdediging op, met een meting vooraf en een meting achteraf. Je krijgt een beginscore, de lijst met wat ontbreekt, het werk zelf en een tweede meting bij de oplevering.

Een site hoeft niet gehackt te zijn om door een beveiligingscontrole te zakken. In één opdracht was de aanleiding commercieel en geen incident: het bedrijfs-DNS-filter van een van zijn eigen afnemers weigerde het domein van onze klant, waardoor die niet meer als leverancier kon werken. Binnen een week leverden we het rapport over beveiliging, SSL en reputatie op, met openbare referentietools. De site was niet gecompromitteerd en stond op geen enkele blacklist. TLS was al in orde voordat we begonnen: geldig certificaat, TLS 1.3, geen zwakke ciphers, geldige keten, forward secrecy en een A op de publieke SSL-test. Wat het automatische oordeel "lage beveiligingsstatus" veroorzaakte, waren drie andere dingen: ontbrekende HTTP-securityheaders, een verlopen en niet passend reservecertificaat dat de gedeelde hosting blootgaf, en zichtbare serverfingerprints (versie van de interpreter, handtekening van het beheerpaneel en technologieheader).

Waar we aan werken

De buitenste laag

Headers zijn de goedkoopste verdediging die er is, en het eerste wat een bedrijfsfilter leest. Wat ontbrak bij de start van die opdracht: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy. Wat er na het werk daadwerkelijk werd geserveerd: HSTS met includeSubdomains, een contentbeleid, nosniff, X-Frame-Options SAMEORIGIN, een strikte Referrer-Policy, Permissions-Policy met de gevoelige browser-API's uitgezet, en een serverheader zonder versienummer. Het headercijfer ging van F naar A+, gemeten op de stagingomgeving vóór de DNS-wissel.

We lezen ook de TLS-versie en de ciphers, de certificaatketen, elk tweede certificaat dat de hosting op hetzelfde adres blootgeeft, en de cookievlaggen (Secure, HttpOnly, SameSite).

De applicatie

Serverfingerprints verbergen, bruteforcebescherming op de login, een firewall op applicatieniveau met automatische IP-blokkade, verouderde discovery-endpoints en remote protocollen uitzetten, en een inventaris van dependencies en extensies met per stuk de versie erbij. AI-crawlers blijven bewust toegestaan: hardening mag je zichtbaarheid in zoekmachines en AI-assistenten niet kosten.

Tenant-isolatie

Zodra één database gegevens van meerdere klanten bevat, is isolatie geen instelling maar een test. Row level security op elke tabel met een tenantkolom, en een bewaker die de tabellen zelf ontdekt in plaats van ze met de hand op te sommen, zodat een nieuwe tabel niet vergeten wordt. Op ons eigen multi-tenantplatform bewaakte die in augustus 2026 81 tabellen met een tenant-identificatie, hij draait bij elke continuous-integrationbuild, en zijn test tussen twee echte tenants vond geen kruislingse leesactie. Op een ander platform dat we hebben gehardend gingen de securityadviezen van de database van 4 naar 0 en de row level policies met een prestatieprobleem van 51 naar 0.

Verhuizen als er geen andere weg is

In die opdracht was het beheerpaneel van het CMS de enige toegang die er was. Zonder toegang tot de hosting was hardening op serverniveau eenvoudigweg niet toepasbaar op de oorspronkelijke infrastructuur. De oorspronkelijke leverancier kreeg de lijst met correcties en antwoordde formeel dat die buiten zijn scope viel; er gingen ongeveer drie maanden op aan die onderhandeling voordat de klant van leverancier wisselde.

Een herbouw in code schatten we op drie tot zes weken, met het domein al die tijd geblokkeerd. Het CMS verhuizen naar hosting die de klant zelf beheert en het daar hardenen was omkeerbaar en zette de correcties veel eerder live, dus dat is de route geworden. De herbouw bleef een uitgestelde fase.

Wat we beweren houdt op waar ons eigen werk ophoudt. Of het filter van die fabrikant daarna is opgeheven, is aan die fabrikant, we hebben er geen meting van en we presenteren het niet als resultaat.

DNS verhuist met een sluitende overdracht: TTL 24 tot 48 uur van tevoren omlaag, A-record aangepast en de mailrecords (MX, SPF, DKIM, DMARC) ongemoeid, zodat de zakelijke e-mail op dat domein blijft werken.

Niets is af tot het live is gecontroleerd

Na de DNS-wissel deden we een linkaudit pagina voor pagina over 24 pagina's, 12 per taal. Daaruit bleek dat de eerste bulkvervanging van URL's onvolledig was geweest: verwijzingen naar de stagingomgeving in de globale footer, in de CTA's van de paginabouwer, in de toestemmingslinks van de formulieren, in meerdere PDF's, in juridische teksten en in een icoonfont van het thema dat een foutmelding gaf. De vervanging was in simulatie gedraaid en voor afgerond aangenomen. Een wijziging is pas af als een echt verzoek aan de live site dat bevestigt.

Wat een cijfer waard is

Een A+ is een foto van één host op één datum, geen eigenschap van het systeem. Hetzelfde geldt voor een schone isolatietest: die is waar als uitkomst van een gedateerde controle, niet als permanente garantie. Daarom vermeldt elke meting in het rapport de host, de datum en de tool, en telt alleen de scan op het productiedomein ná de wissel, niet die op staging.

We beloven geen veilige site. We beloven meetbare gaten, gemeten, gedicht en opnieuw gemeten.

Wat je bij de oplevering krijgt

Een opleverrapport als PDF met het voor en na, de linkaudit en 30 dagen technische garantie op het werk. Wil je de status onderhouden in plaats van eenmalig laten controleren, dan loopt het door als maandelijks onderhoud.