Beveiliging die in de structuur zit.
Isolatie die je niet verkeerd kunt configureren wint het van een beleid dat niemand leest. Deze pagina zet op een rij wat de gegevens van je klanten beschermt — regel voor regel getoetst aan de broncode, het adresregister en onze hostingpartij.
- 12
- BCrypt-werkfactor
- 15
- Minuten tot een toegangstoken verloopt
- 7
- Afgedwongen rate-limitregels
- 27
- Dreigingen geanalyseerd in het STRIDE-model
Waar je gegevens staan.
Eerst scheiding, dan versleuteling, en een uitgang die een bestand is — geen onderhandeling.
Tenantisolatie
Een account dat via de aanmelding wordt aangemaakt, krijgt een eigen database, en elke geïnstalleerde module bewaart zijn tabellen daarbinnen in een eigen schema. Ook in de eigen identiteitstabellen van het platform wordt de tenantafbakening door de datalaag toegepast, in plaats van aan elke query overgelaten.
Waar het draait
De servers van het platform staan in Nederland, gehost door TransIP. E-mailbezorging en sms lopen via leveranciers buiten de EU; de privacyverklaring benoemt elke leverancier en wat die ontvangt.
Versleuteling in rust
De databases draaien met SQL Server Transparent Data Encryption, zodat de databasebestanden versleuteld op schijf staan.
Opgeslagen toegangsgegevens
Connectionstrings van databases en toegangsgegevens van betaalproviders worden versleuteld met ASP.NET Core Data Protection voordat ze worden opgeslagen, en komen nooit in logs terecht.
Je gegevens meenemen
Voor een account met een eigen database kunnen we op verzoek een volledige kopie voor je exporteren, als standaard .bacpac-bestand van SQL Server.
Identiteit en sessies.
Standaard kort geldig, in één beweging in te trekken — en elk getal hieronder ligt vast in de code.
- 15min
- levensduur toegangstoken
- 256bit
- willekeurige refresh-tokens
- 5min
- vervaltijd eenmalige code
- 3pogingen
- limiet eenmalige code
- 5pogingen
- drempel voor blokkering
- 12
- BCrypt-werkfactor
Wachtwoorden
Gehasht met BCrypt op werkfactor 12, vastgelegd in de code. Standaard blokkering na 5 mislukte pogingen — per tenant instelbaar, en uit te zetten.
Sessies
Toegangstokens verlopen na 15 minuten. Refresh-tokens zijn willekeurige waarden van 256 bits, worden alleen als hash opgeslagen, zijn eenmalig bruikbaar en worden bij elke verversing vervangen.
Eenmalige codes
Optionele codes van 6 cijfers via e-mail of sms, gehasht opgeslagen, 5 minuten geldig en met een limiet van 3 pogingen.
Vertrouwde apparaten
Cookies met host-prefix, secure en SameSite op strict, met een waarde die aan de serverkant als hash is opgeslagen. Wordt een inmiddels vervangen cookie aangeboden, dan wordt het apparaat ingetrokken en de inlogpoging geblokkeerd.
Toegang intrekken
Alle vertrouwde apparaten zijn in één keer in te trekken — en die intrekking gebeurt vanzelf na een wachtwoordwijziging, een blokkering, het uitschakelen van tweefactorauthenticatie, of een wijziging van e-mailadres of telefoonnummer.
Grenzen, limieten en het logboek.
Controles aan de rand, limieten op de weg naar binnen, en achter elke wijziging een spoor dat alleen aangroeit.
Autorisatie
Endpoints achter een recht benoemen zelf welk recht ze vereisen; dat wordt op de HTTP-grens gecontroleerd tegen de claims in het ondertekende token, zonder dat daar een database-aanroep voor nodig is. Endpoints die alleen de eigen gegevens van de ingelogde gebruiker teruggeven, zijn afgeschermd met alleen authenticatie.
Rate-limits en headers
Zeven afgedwongen rate-limitregels, en acht beveiligingsheaders op API-antwoorden, waaronder HSTS en een content-security-policy die standaard alles weigert.
Auditlogboek
Wijzigingen in de eigen tabellen van het platform — inloggen, rollen, rechten, instellingen — worden append-only vastgelegd: wie, wat, welke tabel en rij, wanneer, en de waarden na de wijziging. Wachtwoordhashes, hashes van eenmalige codes, geheime sleutels voor tweefactorauthenticatie en security stamps blijven erbuiten. Bij een verwijdering wordt de sleutel van de rij vastgelegd, niet wat erin stond.
Dreigingsmodel
Een uitgeschreven STRIDE-model: 27 geanalyseerde dreigingen over vier vertrouwenszones en de grens tussen host en tenant, met vier geaccepteerde restrisico's expliciet benoemd.
Elke regel hierboven is voor het laatst gecontroleerd op 19 juli 2026 — getoetst aan de broncode, en voor hosting en schijfversleuteling aan het adresregister en onze hostingpartij.
Stuur ons je beveiligingsvragenlijst.
Die beantwoorden we regel voor regel, met de mensen die de code hebben geschreven.
Neem contact op