Verzending vandaag bij bestelling vóór 15:00Verzending vandaag bij bestelling vóór 15:00
WWisman Group
Vertrouwen

Beveiliging

Je bestelt technische componenten bij ons met bedrijfsgegevens, prijsafspraken en facturen. Op deze pagina leggen we precies uit hoe die gegevens beschermd zijn — van de verbinding in je browser tot de rechten op één enkele databaseregel.

Laatst bijgewerkt: 20-08-2026

Verbinding
TLS 1.2+ met HSTS, alles via HTTPS
Kaartgegevens
Nooit bij ons — afgehandeld door Stripe
Databasetoegang
Rij-niveau beveiliging op elke tabel
Accounts
Gehashte wachtwoorden en 2FA beschikbaar
01

Uitgangspunten

De beveiliging van deze webshop is opgebouwd rond drie principes: gegevens zijn onderweg en in rust versleuteld, iedere gebruiker ziet uitsluitend wat bij zijn eigen bedrijfsaccount hoort, en beslissingen over geld en rechten worden altijd op de server genomen — nooit in de browser.

Dat laatste is belangrijker dan het klinkt: alles wat in je browser draait kan door een bezoeker aangepast worden. Daarom controleert de server bij elke bestelling opnieuw de prijzen, staffelkortingen, btw-behandeling en rechten, ongeacht wat de webpagina meestuurt.

  • Minimale rechten: elk onderdeel krijgt alleen de toegang die het echt nodig heeft.
  • Verdediging in lagen: als één maatregel faalt, staan er nog andere tussen een aanvaller en je gegevens.
  • Dataminimalisatie: we slaan geen gegevens op die we niet nodig hebben om je order uit te voeren.
  • Controleerbaar: gevoelige handelingen laten sporen na in logbestanden.
02

Versleutelde verbinding en beveiligingsheaders

Al het verkeer tussen jouw browser en de webshop loopt over HTTPS met TLS 1.2 of hoger. Verzoeken via HTTP worden automatisch doorgestuurd naar HTTPS en de site stuurt een HSTS-header mee, zodat je browser voortaan zelf weigert om onversleuteld te verbinden.

Daarnaast stuurt de server een set beveiligingsheaders mee die de speelruimte van een eventuele aanval verkleinen.

  • Content-Security-Policy: bepaalt welke scripts, stijlen, afbeeldingen en verbindingen zijn toegestaan, waardoor ingespoten code niet zomaar uitgevoerd of doorgestuurd wordt.
  • X-Content-Type-Options: nosniff — de browser mag bestandstypen niet zelf herinterpreteren.
  • X-Frame-Options / frame-ancestors: de webshop kan niet in een frame van een andere site worden geladen (clickjacking).
  • Referrer-Policy: bij het verlaten van de site wordt geen volledige URL met parameters meegegeven.
  • Permissions-Policy: camera, microfoon en locatie worden geblokkeerd; de webshop heeft ze niet nodig.
03

Accounts en inloggen

Accounts draaien op een beheerd authenticatieplatform. Wachtwoorden worden nooit leesbaar opgeslagen: ze worden met een moderne, salted hashfunctie opgeslagen en zijn ook voor ons niet in te zien of terug te rekenen. Er is geen anonieme zelfregistratie met verhoogde rechten; nieuwe zakelijke accounts worden gekoppeld aan een bedrijf.

Na het inloggen krijg je een kortlevend toegangstoken plus een vernieuwingstoken. Het toegangstoken verloopt automatisch, zodat een gelekt token slechts korte tijd bruikbaar is. Uitloggen trekt de sessie in.

  • Tweestapsverificatie (2FA) via een authenticator-app kan per gebruiker worden ingeschakeld.
  • E-mailadressen worden geverifieerd voordat een account volledig actief is.
  • Wachtwoordherstel loopt via een eenmalige link met korte geldigheid.
  • Inlogpogingen zijn begrensd, zodat wachtwoorden niet stelselmatig geraden kunnen worden.
  • Ook tijdens het afrekenen kun je veilig inloggen; je winkelwagen blijft daarbij behouden.
04

Bedrijfsaccounts, rollen en scheiding van gegevens

Een bedrijfsaccount kan meerdere medewerkers bevatten. Iedere medewerker heeft een rol die bepaalt wat hij mag: bestellen, alleen bekijken of het account beheren. Rollen staan in een aparte tabel, niet in het profiel van de gebruiker — juist om te voorkomen dat iemand zichzelf via een profielbewerking tot beheerder kan promoveren.

Rolcontroles gebeuren altijd in de database met vaste, alleen-lezen hulpfuncties. De browser mag wel weten wat hij mag tonen, maar bepaalt nooit wat je mag doen.

  • Besteller: mag bestellen binnen de afgesproken kredietlimiet en PO-referenties invullen.
  • Kijker: mag orders en facturen inzien, maar niets bestellen.
  • Beheerder: mag medewerkers toevoegen, rechten aanpassen en bedrijfsgegevens beheren.
  • Medewerkers van bedrijf A kunnen orders, facturen en prijzen van bedrijf B technisch niet opvragen.
05

Databasebeveiliging: rij-niveau beveiliging

De database staat niet open. Op elke tabel met klantgegevens is rij-niveau beveiliging (RLS) ingeschakeld, met expliciete regels die per rij bepalen wie hem mag lezen, aanmaken, wijzigen of verwijderen. Zonder passende regel is een rij simpelweg onzichtbaar, ook bij een verkeerd geschreven query in de applicatie.

Bovendien zijn de standaardrechten op het databaseschema ingetrokken en alleen gericht toegekend. Publieke gegevens — zoals productteksten, afmetingen en categorieën — zijn bewust leesbaar; alles wat aan een klant hangt niet.

  • Orders, offertes, facturen en adressen zijn gekoppeld aan het bedrijf van de ingelogde gebruiker.
  • Berichten uit contact- en offerteformulieren kunnen wel worden aangemaakt, maar niet publiek worden teruggelezen.
  • Beheerfuncties zijn afgeschermd met een aparte rollencontrole en zijn niet bereikbaar voor gewone accounts.
  • Databasefuncties met verhoogde rechten hebben een vastgezet zoekpad en zijn niet uitvoerbaar voor niet-ingelogde bezoekers.
06

Betalingen

Betalingen lopen via Stripe, een PCI-DSS-gecertificeerde betaaldienstverlener. Je kaart- of iDEAL-gegevens worden ingevoerd in een omgeving van Stripe en komen nooit door onze servers of in onze database. Wij ontvangen alleen de betaalstatus en een transactiereferentie.

Het bedrag dat je betaalt wordt op de server samengesteld: artikelprijzen, staffelkortingen, verzendkosten en btw worden opnieuw berekend uit de database. Een gemanipuleerde winkelwagen of aangepaste prijs in de browser leidt dus niet tot een goedkopere bestelling.

  • Terugkoppeling van Stripe komt binnen via een webhook waarvan de handtekening cryptografisch wordt gecontroleerd.
  • Webhooks zijn idempotent: een dubbel binnengekomen melding leidt niet tot een dubbele order of dubbele verwerking.
  • Een order wordt pas als betaald gemarkeerd na bevestiging door Stripe, niet na terugkeer in de browser.
  • Btw-behandeling (waaronder verlegging binnen de EU) wordt server-side bepaald, met validatie van het btw-nummer via VIES.
07

Bescherming tegen misbruik en overbelasting

Formulieren en gevoelige eindpunten zijn voorzien van snelheidsbegrenzing: het aantal pogingen per bezoeker binnen een tijdvenster is beperkt. Dat remt geautomatiseerd spammen, het aftasten van accounts en het uitputten van onze e-mailcapaciteit.

De teller voor deze begrenzing is zo afgeschermd dat gebruikers hem niet zelf kunnen aanroepen of beïnvloeden; alleen de server werkt hem bij.

  • Offerte-, contact- en registratieformulieren zijn begrensd per IP-adres en per account.
  • Alle invoer wordt server-side gevalideerd op type, lengte en formaat voordat er iets wordt opgeslagen.
  • Bestandsuploads zijn beperkt in type en omvang en worden buiten de applicatieomgeving opgeslagen.
  • Zoek- en filterparameters worden geparseerd en gecontroleerd, nooit rechtstreeks in een query geplakt.
08

Veilig ontwikkelen

De webshop is opgebouwd met een moderne server-side gerenderde applicatie waarin databasetoegang uitsluitend via getypeerde serverfuncties verloopt. Queries zijn geparametriseerd, waardoor SQL-injectie geen aangrijpingspunt heeft, en uitvoer wordt door het framework standaard ge-escaped, wat cross-site scripting tegengaat.

Geheimen zoals API-sleutels staan nooit in de broncode of in de browserbundel. Ze worden als beveiligde omgevingsvariabelen ingelezen op het moment dat een serverfunctie draait.

  • Client- en servercode zijn strikt gescheiden; server-only modules kunnen niet in de browserbundel belanden.
  • Afhankelijkheden worden periodiek gescand op bekende kwetsbaarheden en bijgewerkt.
  • Wijzigingen worden eerst op een preview-omgeving getest voordat ze live gaan.
  • De database wordt regelmatig doorgelicht met een beveiligingslinter op ontbrekende regels en te ruime rechten.
09

Hosting, back-ups en continuïteit

De applicatie draait op een beheerde infrastructuur met automatische certificaatvernieuwing, DDoS-mitigatie op netwerkniveau en een wereldwijd verdeeld edge-netwerk. De database staat in een datacenter binnen de Europese Unie en de opslag is versleuteld in rust.

Er worden dagelijks back-ups gemaakt met terugzetmogelijkheid naar een eerder tijdstip. Herstelprocedures worden periodiek getest, zodat een terugzetactie geen improvisatie is.

  • Versleuteling in rust op database- en objectopslagniveau.
  • Dagelijkse back-ups met bewaartermijn en point-in-time herstel.
  • Beheerderstoegang tot de infrastructuur is beperkt tot enkele personen en met 2FA beveiligd.
  • Statuscontroles en foutmeldingen worden bewaakt, zodat storingen snel opvallen.
10

Logging, monitoring en datalekken

Belangrijke gebeurtenissen — inlogpogingen, orderstatuswijzigingen, beheeracties en fouten op de server — worden gelogd. Logbestanden bevatten geen wachtwoorden of betaalgegevens en worden maximaal twaalf maanden bewaard.

Bij een vermoeden van een datalek onderzoeken we direct de omvang, dichten we het lek en informeren wij betrokkenen en, waar de AVG dat vereist, de Autoriteit Persoonsgegevens binnen 72 uur.

11

Wat jij zelf kunt doen

Beveiliging is een gedeelde verantwoordelijkheid. De meeste incidenten in webshops beginnen niet bij de website, maar bij een hergebruikt wachtwoord of een overtuigende phishingmail.

  • Gebruik een uniek, lang wachtwoord en bewaar het in een wachtwoordmanager.
  • Zet tweestapsverificatie aan voor iedereen binnen je bedrijfsaccount.
  • Verwijder medewerkers die uit dienst gaan direct uit het account.
  • Wij vragen nooit per e-mail of telefoon om je wachtwoord of 2FA-code.
  • Controleer bij een gewijzigd bankrekeningnummer op een factuur altijd telefonisch bij ons via het nummer op deze site.
12

Verantwoord melden van kwetsbaarheden

Ontdek je een zwakke plek? Meld het bij ons voordat je het publiek maakt. Stuur een e-mail met een omschrijving, de betrokken URL en reproductiestappen. We bevestigen de ontvangst, houden je op de hoogte en noemen je desgewenst bij naam zodra het probleem is verholpen.

Wij vragen je daarbij: gebruik geen geautomatiseerde aanvallen die de dienst verstoren, benader geen gegevens van andere klanten, en wijzig of verwijder niets.

Kwetsbaarheid gevonden of vraag over beveiliging?

Meld het bij ons via e-mail met een beschrijving en reproductiestappen. We reageren doorgaans binnen twee werkdagen en houden je op de hoogte tot het is opgelost. Test alsjeblieft nooit met echte klantgegevens en voer geen aanvallen uit die de dienst verstoren.