Security

Security in this webshop rests on three principles: data is encrypted in transit and at rest, every user only ever sees what belongs to their own company account, and decisions about money and permissions are always made on the server — never in the browser.

That last point matters more than it sounds: anything running in your browser can be modified by the visitor. That is why the server recalculates prices, volume discounts, VAT treatment and permissions for every order, regardless of what the page submits.

• Least privilege: every component gets only the access it truly needs.
• Defence in depth: if one control fails, others still stand between an attacker and your data.
• Data minimisation: we do not store data we do not need to fulfil your order.
• Accountability: sensitive actions leave a trace in the logs.

All traffic between your browser and the webshop runs over HTTPS with TLS 1.2 or higher. HTTP requests are redirected to HTTPS and the site sends an HSTS header, so your browser refuses unencrypted connections from then on.

In addition, the server sends a set of security headers that shrink the room an attack has to manoeuvre.

• Content-Security-Policy: defines which scripts, styles, images and connections are allowed, so injected code cannot simply run or exfiltrate.
• X-Content-Type-Options: nosniff — the browser may not reinterpret file types on its own.
• X-Frame-Options / frame-ancestors: the webshop cannot be embedded in another site's frame (clickjacking).
• Referrer-Policy: full URLs with parameters are not leaked when you leave the site.
• Permissions-Policy: camera, microphone and geolocation are blocked; the webshop does not need them.

Accounts run on a managed authentication platform. Passwords are never stored in readable form: they are stored using a modern salted hash function and cannot be read or reversed, not even by us. There is no anonymous self-registration with elevated rights; new business accounts are linked to a company.

After signing in you receive a short-lived access token plus a refresh token. The access token expires automatically, so a leaked token is only briefly usable. Signing out revokes the session.

• Two-factor authentication (2FA) via an authenticator app can be enabled per user.
• Email addresses are verified before an account becomes fully active.
• Password recovery uses a single-use link with a short validity window.
• Sign-in attempts are rate limited, so passwords cannot be guessed systematically.
• You can also sign in securely during checkout; your cart is preserved.

A company account can contain multiple employees. Each has a role that defines what they may do: order, view only, or manage the account. Roles live in a separate table, not on the user profile — precisely to prevent someone from promoting themselves to administrator by editing their profile.

Role checks always happen in the database through fixed, read-only helper functions. The browser may know what to display, but never decides what you are allowed to do.

• Buyer: may order within the agreed credit limit and enter PO references.
• Viewer: may inspect orders and invoices but cannot order.
• Administrator: may add employees, adjust rights and manage company details.
• Employees of company A technically cannot retrieve orders, invoices or pricing of company B.

The database is not open. Every table holding customer data has row-level security enabled, with explicit policies deciding per row who may read, create, update or delete it. Without a matching policy a row is simply invisible, even if the application issues a badly written query.

Default privileges on the schema have also been revoked and are granted only where needed. Public data — product copy, dimensions, categories — is intentionally readable; anything tied to a customer is not.

• Orders, quotes, invoices and addresses are scoped to the company of the signed-in user.
• Contact and quote form submissions can be created but never publicly read back.
• Admin functionality is gated by a separate role check and unreachable for regular accounts.
• Elevated database functions have a pinned search path and are not executable by anonymous visitors.

Payments run through Stripe, a PCI-DSS certified payment provider. Your card or iDEAL details are entered in Stripe's environment and never pass through our servers or database. We only receive the payment status and a transaction reference.

The amount you pay is assembled on the server: item prices, volume discounts, shipping and VAT are recalculated from the database. A tampered cart or an edited price in the browser therefore cannot produce a cheaper order.

• Stripe's callbacks arrive via a webhook whose signature is verified cryptographically.
• Webhooks are idempotent: a duplicate notification never creates a duplicate order or duplicate processing.
• An order is only marked paid after Stripe confirms it, not when the browser returns.
• VAT treatment (including EU reverse charge) is determined server-side, with VAT number validation via VIES.

Forms and sensitive endpoints are rate limited: the number of attempts per visitor within a time window is capped. That curbs automated spam, account probing and exhaustion of our email capacity.

The counter behind this limiter is locked down so users cannot call or influence it themselves; only the server updates it.

• Quote, contact and registration forms are limited per IP address and per account.
• All input is validated server-side for type, length and format before anything is stored.
• File uploads are restricted in type and size and stored outside the application environment.
• Search and filter parameters are parsed and validated, never pasted straight into a query.

The webshop is a modern server-rendered application in which database access runs exclusively through typed server functions. Queries are parameterised, leaving SQL injection no foothold, and output is escaped by the framework by default, which counters cross-site scripting.

Secrets such as API keys are never in the source code or the browser bundle. They are read as protected environment variables at the moment a server function runs.

• Client and server code are strictly separated; server-only modules cannot end up in the browser bundle.
• Dependencies are scanned periodically for known vulnerabilities and updated.
• Changes are tested on a preview environment before going live.
• The database is regularly reviewed with a security linter for missing policies and overly broad grants.

The application runs on managed infrastructure with automatic certificate renewal, network-level DDoS mitigation and a globally distributed edge network. The database resides in a data centre inside the European Union and storage is encrypted at rest.

Backups are taken daily with point-in-time restore. Recovery procedures are tested periodically so a restore is never improvised.

• Encryption at rest at database and object-storage level.
• Daily backups with a retention window and point-in-time recovery.
• Administrative access to the infrastructure is limited to a few people and protected with 2FA.
• Health checks and server errors are monitored so outages surface quickly.

Important events — sign-in attempts, order status changes, admin actions and server errors — are logged. Logs contain no passwords or payment data and are kept for at most twelve months.

If we suspect a data breach we immediately assess the scope, close the gap and inform those affected and, where the GDPR requires it, the supervisory authority within 72 hours.

Security is a shared responsibility. Most webshop incidents do not start at the website but with a reused password or a convincing phishing email.

• Use a unique, long password and keep it in a password manager.
• Enable two-factor authentication for everyone in your company account.
• Remove employees who leave the company from the account immediately.
• We never ask for your password or 2FA code by email or phone.
• If a bank account number on an invoice changes, always verify by calling the number listed on this site.

Found a weakness? Report it to us before making it public. Send an email with a description, the affected URL and reproduction steps. We confirm receipt, keep you posted and credit you by name if you wish once the issue is fixed.

We ask that you do not use automated attacks that disrupt the service, do not access other customers' data, and do not modify or delete anything.