Lieferland wählen
Versand noch heute bei Bestellung vor 15:00 UhrVersand noch heute bei Bestellung vor 15:00 Uhr
Wisman Group
Vertrauen

Sicherheit

Sie bestellen bei uns technische Komponenten mit Unternehmensdaten, Preisvereinbarungen und Rechnungen. Auf dieser Seite erklären wir genau, wie diese Daten geschützt sind — von der Verbindung in Ihrem Browser bis hin zu den Rechten für eine einzelne Datenbankzeile.

Zuletzt aktualisiert: 20.08.2026

Verbindung
TLS 1.2+ mit HSTS, alles über HTTPS
Kartendaten
Nie bei uns — abgewickelt über Stripe
Datenbankzugriff
Sicherheit auf Zeilenebene in jeder Tabelle
Konten
Gehashte Passwörter und 2FA verfügbar
01

Grundprinzipien

Die Sicherheit dieses Webshops baut auf drei Prinzipien auf: Daten sind unterwegs und im Ruhezustand verschlüsselt, jeder Benutzer sieht ausschließlich das, was zu seinem eigenen Firmenkonto gehört, und Entscheidungen über Geld und Rechte werden immer auf dem Server getroffen — niemals im Browser.

Letzteres ist wichtiger als es klingt: Alles, was in Ihrem Browser läuft, kann von einem Besucher manipuliert werden. Deshalb prüft der Server bei jeder Bestellung Preise, Staffelrabatte, USt-Behandlung und Rechte erneut, unabhängig davon, was die Webseite mitsendet.

  • Minimale Rechte: Jede Komponente erhält nur den Zugriff, den sie wirklich benötigt.
  • Mehrschichtige Verteidigung (Defense in Depth): Wenn eine Maßnahme fehlschlägt, stehen weitere Hindernisse zwischen einem Angreifer und Ihren Daten.
  • Datenminimierung: Wir speichern keine Daten, die wir nicht zur Abwicklung Ihrer Bestellung benötigen.
  • Prüfbarkeit: Sensible Handlungen hinterlassen Spuren in Protokolldateien.
02

Verschlüsselte Verbindung und Sicherheits-Header

Der gesamte Datenverkehr zwischen Ihrem Browser und dem Webshop läuft über HTTPS mit TLS 1.2 oder höher. Anfragen über HTTP werden automatisch auf HTTPS umgeleitet und die Seite sendet einen HSTS-Header mit, sodass Ihr Browser künftig von sich aus unverschlüsselte Verbindungen verweigert.

Zusätzlich sendet der Server eine Reihe von Sicherheits-Headern mit, die den Spielraum eines potenziellen Angriffs verkleinern.

  • Content-Security-Policy: Legt fest, welche Skripte, Stile, Bilder und Verbindungen erlaubt sind, wodurch injizierter Code nicht einfach ausgeführt oder weitergeleitet werden kann.
  • X-Content-Type-Options: nosniff — Der Browser darf Dateitypen nicht eigenmächtig neu interpretieren.
  • X-Frame-Options / frame-ancestors: Der Webshop kann nicht in einem Frame einer anderen Seite geladen werden (Clickjacking).
  • Referrer-Policy: Beim Verlassen der Seite wird keine vollständige URL mit Parametern übermittelt.
  • Permissions-Policy: Kamera, Mikrophon und Standort werden blockiert; der Webshop benötigt sie nicht.
03

Konten und Anmeldung

Konten laufen auf einer verwalteten Authentifizierungsplattform. Passwörter werden niemals im Klartext gespeichert: Sie werden mit einer modernen, gesalzenen Hash-Funktion gespeichert und sind auch für uns weder einsehbar noch rückrechenbar. Es gibt keine anonyme Selbstregistrierung mit erhöhten Rechten; neue Geschäftskundenkonten werden mit einem Unternehmen verknüpft.

Nach dem Anmelden erhalten Sie ein kurzlebiges Zugriffstoken sowie ein Refresh-Token. Das Zugriffstoken läuft automatisch ab, sodass ein abgeflossenes Token nur kurze Zeit nutzbar ist. Abmelden widerruft die Sitzung.

  • Zwei-Faktor-Authentifizierung (2FA) über eine Authenticator-App kann pro Benutzer aktiviert werden.
  • E-Mail-Adressen werden verifiziert, bevor ein Konto vollständig aktiv ist.
  • Passwort-Rücksetzungen laufen über einen einmaligen Link mit kurzer Gültigkeit.
  • Anmeldeversuche sind begrenzt, damit Passwörter nicht systematisch erraten werden können.
  • Auch während des Bestellvorgangs können Sie sich sicher anmelden; Ihr Warenkorb bleibt dabei erhalten.
04

Firmenkonten, Rollen und Datentrennung

Ein Firmenkonto kann mehrere Mitarbeiter enthalten. Jeder Mitarbeiter hat eine Rolle, die bestimmt, was er darf: bestellen, nur einsehen oder das Konto verwalten. Rollen stehen in einer separaten Tabelle, nicht im Profil des Benutzers — genau um zu verhindern, dass sich jemand über eine Profilbearbeitung selbst zum Administrator befördert.

Rollenprüfungen erfolgen immer in der Datenbank mit festen Schreibschutz-Hilfsfunktionen. Der Browser darf zwar wissen, was er anzeigen darf, bestimmt aber niemals, was Sie tun dürfen.

  • Besteller: Darf innerhalb des vereinbarten Kreditlimits bestellen und PO-Referenzen eintragen.
  • Betrachter: Darf Bestellungen und Rechnungen einsehen, aber nichts bestellen.
  • Administrator: Darf Mitarbeiter hinzufügen, Rechte anpassen und Unternehmensdaten verwalten.
  • Mitarbeiter von Unternehmen A können Bestellungen, Rechnungen und Preise von Unternehmen B technisch nicht abrufen.
05

Datenbanksicherheit: Zeilenebene-Sicherheit (RLS)

Die Datenbank ist nicht offen zugänglich. Für jede Tabelle mit Kundendaten ist Zeilenebene-Sicherheit (Row Level Security, RLS) aktiviert, mit expliziten Regeln, die pro Zeile festlegen, wer sie lesen, erstellen, ändern oder löschen darf. Ohne passende Regel ist eine Zeile schlichtweg unsichtbar, selbst bei einer falsch geschriebenen Abfrage in der Anwendung.

Zudem wurden die Standardrechte für das Datenbankschema entzogen und nur gezielt zugewiesen. Öffentliche Daten — wie Produkttexte, Abmessungen und Kategorien — sind bewusst lesbar; alles, was an einem Kunden hängt, nicht.

  • Bestellungen, Angebote, Rechnungen und Adressen sind mit dem Unternehmen des angemeldeten Benutzers verknüpft.
  • Nachrichten aus Kontakt- und Angebotsformularen können zwar erstellt, aber nicht öffentlich zurückgelesen werden.
  • Verwaltungsfunktionen sind durch eine separate Rollenprüfung geschützt und für normale Konten nicht erreichbar.
  • Datenbankfunktionen mit erhöhten Rechten haben einen festgelegten Suchpfad und sind für nicht angemeldete Besucher nicht ausführbar.
06

Zahlungen

Zahlungen laufen über Stripe, einen PCI-DSS-zertifizierten Zahlungsdienstleister. Ihre Karten- oder Zahlungsdaten werden in einer Umgebung von Stripe eingegeben und gelangen niemals auf unsere Server oder in unsere Datenbank. Wir erhalten lediglich den Zahlungsstatus und eine Transaktionsreferenz.

Der zu zahlende Betrag wird auf dem Server zusammengestellt: Artikelpreise, Staffelrabatte, Versandkosten und USt. werden aus der Datenbank neu berechnet. Ein manipulierter Warenkorb oder ein angepasster Preis im Browser führt daher nicht zu einer günstigeren Bestellung.

  • Rückmeldungen von Stripe gehen über einen Webhook ein, dessen Signatur kryptografisch überprüft wird.
  • Webhooks sind idempotent: Eine doppelt eingegangene Meldung führt nicht zu einer doppelten Bestellung oder doppelten Verarbeitung.
  • Eine Bestellung wird erst nach Bestätigung durch Stripe als bezahlt markiert, nicht nach der Rückkehr in den Browser.
  • Die USt-Behandlung (einschließlich Steuerschuldumkehr innergemeinschaftlich) wird serverseitig bestimmt, mit Validierung der USt-IdNr. über VIES.
07

Schutz vor Missbrauch und Überlastung

Formulare und sensible Endpunkte sind mit Ratenbegrenzung (Rate Limiting) versehen: Die Anzahl der Versuche pro Besucher innerhalb eines Zeitfensters ist beschränkt. Das bremst automatisiertes Spammen, das Austesten von Konten und das Erschöpfen unserer E-Mail-Kapazitäten.

Der Zähler für diese Begrenzung ist so geschützt, dass Benutzer ihn nicht selbst aufrufen oder beeinflussen können; nur der Server aktualisiert ihn.

  • Angebots-, Kontakt- und Registrierungsformulare sind pro IP-Adresse und pro Konto begrenzt.
  • Alle Eingaben werden serverseitig auf Typ, Länge und Format validiert, bevor etwas gespeichert wird.
  • Datei-Uploads sind in Typ und Umfang beschränkt und werden außerhalb der Anwendungsumgebung gespeichert.
  • Such- und Filterparameter werden geparst und überprüft, niemals direkt in eine Abfrage eingefügt.
08

Sichere Entwicklung

Der Webshop ist mit einer modernen, serverseitig rendernenden Anwendung aufgebaut, in der der Datenbankzugriff ausschließlich über typisierte Serverfunktionen erfolgt. Abfragen sind parametrisiert, sodass SQL-Injection keine Angriffsfläche bietet, und Ausgaben werden vom Framework standardmäßig maskiert (escaped), was Cross-Site-Scripting verhindert.

Geheimnisse wie API-Schlüssel stehen niemals im Quellcode oder im Browser-Bundle. Sie werden als geschützte Umgebungsvariablen in dem Moment eingelesen, in dem eine Serverfunktion ausgeführt wird.

  • Client- und Servercode sind strikt getrennt; Server-only-Module können nicht im Browser-Bundle landen.
  • Abhängigkeiten werden regelmäßig auf bekannte Schwachstellen gescannt und aktualisiert.
  • Änderungen werden zuerst in einer Vorschau-Umgebung getestet, bevor sie live gehen.
  • Die Datenbank wird regelmäßig mit einem Sicherheits-Linter auf fehlende Regeln und zu weit gefasste Rechte geprüft.
09

Hosting, Backups und Kontinuität

Die Anwendung läuft auf einer verwalteten Infrastruktur mit automatischer Zertifikatserneuerung, DDoS-Mitigation auf Netzwerkebene und einem weltweit verteilten Edge-Netzwerk. Die Datenbank befindet sich in einem Rechenzentrum innerhalb der Europäischen Union und der Speicher ist im Ruhezustand verschlüsselt.

Es werden täglich Backups mit der Möglichkeit zur Wiederherstellung auf einen früheren Zeitpunkt erstellt. Wiederherstellungsverfahren werden regelmäßig getestet, damit ein Wiederherstellungsvorgang keine Improvisation ist.

  • Verschlüsselung im Ruhezustand auf Datenbank- und Objektspeicherebene.
  • Tägliche Backups mit Aufbewahrungsfrist und Point-in-Time-Wiederherstellung.
  • Der Administratorzugriff auf die Infrastruktur ist auf wenige Personen beschränkt und mit 2FA geschützt.
  • Statusprüfungen und Fehlermeldungen werden überwacht, sodass Störungen schnell auffallen.
10

Protokollierung, Überwachung und Datenpannen

Wichtige Ereignisse — Anmeldeversuche, Statusänderungen von Bestellungen, Aktionen von Administratoren und Fehler auf dem Server — werden protokolliert. Protokolldateien enthalten keine Passwörter oder Zahlungsdaten und werden maximal zwölf Monate aufbewahrt.

Bei dem Verdacht einer Datenpanne untersuchen wir unverzüglich das Ausmaß, schließen die Lücke und informieren Betroffene sowie, wo die DSGVO dies verlangt, die Datenschutzbehörde (Autoriteit Persoonsgegevens) innerhalb von 72 Stunden.

11

Was Sie selbst tun können

Sicherheit ist eine geteilte Verantwortung. Die meisten Vorfälle bei Webshops beginnen nicht bei der Website selbst, sondern bei einem wiederverwendeten Passwort oder einer überzeugenden Phishing-E-Mail.

  • Nutzen Sie ein einzigartiges, langes Passwort und bewahren Sie es in einem Passwort-Manager auf.
  • Aktivieren Sie die Zwei-Faktor-Authentifizierung für jeden Benutzer in Ihrem Firmenkonto.
  • Entfernen Sie Mitarbeiter, die das Unternehmen verlassen, umgehend aus dem Konto.
  • Wir fragen Sie niemals per E-Mail oder Telefon nach Ihrem Passwort oder 2FA-Code.
  • Überprüfen Sie bei einer geänderten Bankverbindung auf einer Rechnung diese immer telefonisch bei uns über die Nummer auf dieser Website.
12

Verantwortungsvolle Meldung von Schwachstellen (Responsible Disclosure)

Haben Sie eine Schwachstelle entdeckt? Melden Sie uns diese, bevor Sie sie öffentlich machen. Senden Sie eine E-Mail mit einer Beschreibung, der betroffenen URL und Schritten zur Reproduktion. Wir bestätigen den Eingang, halten Sie auf dem Laufenden und nennen Sie auf Wunsch namentlich, sobald das Problem behoben ist.

Wir bitten Sie dabei: Nutzen Sie keine automatisierten Angriffe, die den Dienst stören, greifen Sie nicht auf Daten anderer Kunden zu und ändern oder löschen Sie nichts.

Schwachstelle gefunden oder Frage zur Sicherheit?

Melden Sie sich per E-Mail mit Beschreibung und Reproduktionsschritten. Wir antworten in der Regel innerhalb von zwei Werktagen und halten Sie bis zur Behebung auf dem Laufenden. Bitte testen Sie nie mit echten Kundendaten und vermeiden Sie Angriffe, die den Dienst stören.