--- title: "Beveiliging en hardening · Polargate" description: "Hardening van websites en applicaties die al in productie draaien: headers, contentbeleid, HSTS, cookies, TLS, dependencies en tenant-isolatie…" url: https://polargate.ai/nl/services/care/security-hardening locale: nl publisher: POLARGATE S.L. --- - [Polargate](https://polargate.ai/nl) - [Diensten](https://polargate.ai/nl/services) - [Care](https://polargate.ai/nl/services/care) - Beveiliging en hardening Care // Een site die al live staat de verdediging geven die hij mist, gemeten voor en na. # Beveiliging en hardening Hardening van websites en applicaties die al in productie draaien: headers, contentbeleid, HSTS, cookies, TLS, dependencies en tenant-isolatie, met een gemeten score aan het begin en een tweede meting aan het eind. Elk cijfer in het rapport vermeldt de host, de datum en de tool waarmee het is gemeten. Kort gezegd Polargate hardent sites en apps die al live staan. We meten de uitgangssituatie (HTTP-headers, SSL en TLS, domeinreputatie), dichten wat ontbreekt (headers, HSTS, contentbeleid, cookievlaggen, serverfingerprints, de applicatielaag en tenant-isolatie in de database) en meten aan het eind opnieuw. In één opdracht ging het headercijfer van F naar A+, gemeten op de stagingomgeving vóór de DNS-wissel, terwijl SSL al op A stond voordat we iets aanraakten. Een cijfer is een foto van één host op één datum, dus het rapport noemt altijd welke host en wanneer. ## 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. Wat je krijgt - Een gemeten uitgangsdiagnose: HTTP-headers, SSL en TLS, domeinreputatie, safe browsing en multi-enginescans, elke meting met de tool en de datum erbij - Headers die daadwerkelijk worden geserveerd, niet alleen ingesteld: HSTS met includeSubdomains, een contentbeleid, nosniff, X-Frame-Options, een strikte Referrer-Policy en Permissions-Policy met de gevoelige browser-API's uitgezet - Controle van TLS-versie en ciphers, de certificaatketen, elk reservecertificaat dat de hosting blootgeeft en de cookievlaggen (Secure, HttpOnly, SameSite) - Hardening van de applicatielaag: serverfingerprints verbergen, bruteforcebescherming op de login, een applicatiefirewall met automatische IP-blokkade en verouderde discovery-endpoints uit, met AI-crawlers bewust toegestaan - Een inventaris van dependencies en extensies met per stuk de versie - Tenant-isolatie zodra de database meerdere klanten bevat: row level security op elke tabel met een tenantkolom en een bewaker die tabellen ontdekt in plaats van ze op te sommen, draaiend in continuous integration - Een hosting- of DNS-verhuizing met sluitende overdracht als er geen andere weg is, mailrecords ongemoeid, gevolgd door een linkaudit pagina voor pagina op de live site - Een opleverrapport met de score voor en na, de host en datum van elke meting, en 30 dagen technische garantie Samenwerking Doorlooptijd De diagnose ligt er binnen een week nadat we toegang hebben. Op een kleine site kostte de hardening zelf ongeveer twaalf effectieve uren, verdeeld over twee intensieve sessies plus een auditsessie, en vier dagen van akkoord tot technische oplevering. Moet de hosting mee verhuizen, reken dan de TTL-verlaging 24 tot 48 uur vooraf en de linkaudit pagina voor pagina na de wissel erbij. Eén waarschuwing uit ervaring: datzelfde project duurde van begin tot eind vier maanden, waarvan er ongeveer drie opgingen aan onderhandelen over correcties met de vorige leverancier voordat de klant overstapte. Team Wij zijn met z'n tweeën, en geen van beiden is verkoper. Pedro Ciordia, oprichter en CTO van Polargate, doet de diagnose, de hardening en de verificatie zelf, en haalt specialisten uit het netwerk van de studio erbij als het werk daarom vraagt. Wie je site aan het begin meet, meet hem aan het eind opnieuw. Prijs Vaste prijs per opdracht, begroot na de diagnose en verdeeld over drie fasen: diagnose, hardening, en afsluiting met de linkaudit en het rapport. Het daarna bijhouden loopt als maandelijks onderhoud. We verkopen dit niet per uur. Stack - Vercel - Supabase ## Bewijs Elite Smart Build ### Een op maat gebouwd operatiesysteem voor Elite Smart Build Elite Smart Build, een Spaanse aannemer gespecialiseerd in hotelrenovaties en actief in ruim twintig landen, stuurde elk project aan met spreadsheets en e-mail. Polargate verving dat door elf modules op Supabase en React: dagelijkse Gantt, marges afgeschermd per rol, meldingen per afdeling en materiaalontvangst met automatische incidenten. 2026 Bekijk de case [Een op maat gebouwd operatiesysteem voor Elite Smart Build](https://polargate.ai/nl/work/hotel-refurbishment-operating-system) FAQ ## Vragen, beantwoord Kunnen jullie een site die al live staat beveiligen zonder hem opnieuw te bouwen? Meestal wel, en opnieuw bouwen is vaak het traagste antwoord. In één opdracht schatten we een herbouw in code op drie tot zes weken, met het domein die hele tijd geblokkeerd door een bedrijfs-DNS-filter, terwijl het CMS verhuizen naar hosting die de klant zelf beheerde en het daar hardenen omkeerbaar was en de correcties veel eerder live zette. We bouwen alleen opnieuw als het platform zelf het probleem is, en dan als aparte latere fase, niet als tol om de headers goed te krijgen. Waarom blokkeert een bedrijfsfilter mijn domein als mijn site niet geïnfecteerd is? Omdat die filters configuratie beoordelen, niet alleen infectie. In de opdracht die op deze pagina staat was de diagnose helder: de site was niet gecompromitteerd en stond op geen blacklist, en het SSL scoorde al een A voordat we iets aanraakten. Wat het automatische oordeel "lage beveiligingsstatus" veroorzaakte, waren drie dingen: helemaal geen HTTP-securityheaders, een verlopen en niet passend reservecertificaat dat de gedeelde hosting blootgaf, en zichtbare serverfingerprints. Het headercijfer was op dat moment F. Dat is een configuratieprobleem, en configuratie los je in dagen op. INITIATE ## Start de motor Vertel ons in een paar korte vragen wat je bouwt. Een senior engineer antwoordt binnen twee werkdagen schriftelijk met een eerste inschatting van scope, planning en prijs. [Start je project](https://polargate.ai/nl/start) · [Praat met ons](https://polargate.ai/nl/start#static-brief-heading)