Versand noch heute bei Bestellung vor 15:00 UhrVersand noch heute bei Bestellung vor 15:00 Uhr
WWisman Group
Vertrauen

Sicherheit

Sie bestellen bei uns technische Komponenten mit Firmendaten, vereinbarten Preisen und Rechnungen. Diese Seite erklärt genau, wie diese Daten geschützt sind — von der Verbindung in Ihrem Browser bis zu den Rechten an einer einzelnen 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

Grundsätze

Die Sicherheit dieses Webshops beruht auf drei Grundsätzen: Daten sind bei der Übertragung und im Ruhezustand verschlüsselt, jeder Nutzer sieht ausschließlich das, was zu seinem eigenen Firmenkonto gehört, und Entscheidungen über Geld und Rechte werden immer auf dem Server getroffen — nie im Browser.

Der letzte Punkt ist wichtiger, als er klingt: Alles, was im Browser läuft, kann von Besuchern verändert werden. Deshalb berechnet der Server bei jeder Bestellung Preise, Staffelrabatte, Umsatzsteuerbehandlung und Berechtigungen erneut — unabhängig davon, was die Seite übermittelt.

  • Minimale Rechte: Jede Komponente erhält nur den Zugriff, den sie wirklich benötigt.
  • Mehrschichtige Verteidigung: Fällt eine Maßnahme aus, stehen weitere zwischen Angreifer und Daten.
  • Datenminimierung: Wir speichern keine Daten, die wir zur Auftragsabwicklung nicht brauchen.
  • Nachvollziehbarkeit: Sensible Vorgänge hinterlassen Spuren in den Protokollen.
02

Verschlüsselte Verbindung und Sicherheits-Header

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

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

  • Content-Security-Policy: legt fest, welche Skripte, Stile, Bilder und Verbindungen erlaubt sind, sodass eingeschleuster Code nicht einfach ausgeführt wird.
  • X-Content-Type-Options: nosniff — der Browser darf Dateitypen nicht eigenmächtig umdeuten.
  • X-Frame-Options / frame-ancestors: Der Webshop kann nicht in einen fremden Frame geladen werden (Clickjacking).
  • Referrer-Policy: Beim Verlassen der Seite werden keine vollständigen URLs mit Parametern übergeben.
  • Permissions-Policy: Kamera, Mikrofon und Standort sind blockiert; der Webshop benötigt sie nicht.
03

Konten und Anmeldung

Konten laufen über eine verwaltete Authentifizierungsplattform. Passwörter werden nie im Klartext gespeichert: Sie liegen als moderner, gesalzener Hash vor und sind auch für uns weder einsehbar noch rückrechenbar. Eine anonyme Selbstregistrierung mit erhöhten Rechten gibt es nicht; neue Geschäftskonten werden einem Unternehmen zugeordnet.

Nach der Anmeldung erhalten Sie ein kurzlebiges Zugriffstoken sowie ein Erneuerungstoken. Das Zugriffstoken läuft automatisch ab, sodass ein abgeflossenes Token nur kurz nutzbar ist. Das Abmelden entzieht die Sitzung.

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

Firmenkonten, Rollen und Datentrennung

Ein Firmenkonto kann mehrere Mitarbeitende umfassen. Jede Person hat eine Rolle, die festlegt, was sie darf: bestellen, nur ansehen oder das Konto verwalten. Rollen liegen in einer separaten Tabelle, nicht im Benutzerprofil — genau damit sich niemand über eine Profiländerung selbst zum Administrator machen kann.

Rollenprüfungen erfolgen stets in der Datenbank über feste, nur lesende Hilfsfunktionen. Der Browser darf wissen, was er anzeigen soll, entscheidet aber nie, was Sie tun dürfen.

  • Besteller: darf innerhalb des vereinbarten Kreditlimits bestellen und Bestellreferenzen angeben.
  • Betrachter: darf Aufträge und Rechnungen einsehen, aber nicht bestellen.
  • Administrator: darf Mitarbeitende anlegen, Rechte anpassen und Firmendaten verwalten.
  • Mitarbeitende von Firma A können Aufträge, Rechnungen oder Preise von Firma B technisch nicht abrufen.
05

Datenbanksicherheit: Sicherheit auf Zeilenebene

Die Datenbank steht nicht offen. Für jede Tabelle mit Kundendaten ist Sicherheit auf Zeilenebene aktiviert, mit ausdrücklichen Regeln, die je Zeile bestimmen, wer sie lesen, anlegen, ändern oder löschen darf. Ohne passende Regel ist eine Zeile schlicht unsichtbar — auch bei einer fehlerhaften Abfrage der Anwendung.

Zudem wurden die Standardrechte im Schema entzogen und nur gezielt erteilt. Öffentliche Daten wie Produkttexte, Maße und Kategorien sind bewusst lesbar; alles Kundenbezogene nicht.

  • Aufträge, Angebote, Rechnungen und Adressen sind an das Unternehmen des angemeldeten Nutzers gebunden.
  • Einträge aus Kontakt- und Angebotsformularen können erstellt, aber nie öffentlich zurückgelesen werden.
  • Administrationsfunktionen sind durch eine separate Rollenprüfung geschützt und für normale Konten nicht erreichbar.
  • Datenbankfunktionen mit erhöhten Rechten haben einen fixierten Suchpfad und sind für anonyme Besucher nicht ausführbar.
06

Zahlungen

Zahlungen laufen über Stripe, einen PCI-DSS-zertifizierten Zahlungsdienstleister. Ihre Karten- oder iDEAL-Daten werden in der Umgebung von Stripe eingegeben und erreichen weder unsere Server noch unsere Datenbank. Wir erhalten nur den Zahlungsstatus und eine Transaktionsreferenz.

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

  • Rückmeldungen von Stripe kommen über einen Webhook, dessen Signatur kryptografisch geprüft wird.
  • Webhooks sind idempotent: Eine doppelt eingehende Meldung erzeugt keine doppelte Bestellung.
  • Eine Bestellung gilt erst nach Bestätigung durch Stripe als bezahlt, nicht bei Rückkehr in den Browser.
  • Die Umsatzsteuerbehandlung (inkl. innergemeinschaftlicher Umkehr der Steuerschuld) wird serverseitig bestimmt, mit USt-IdNr.-Prüfung über VIES.
07

Schutz vor Missbrauch und Überlastung

Formulare und sensible Endpunkte sind ratenbegrenzt: Die Anzahl der Versuche pro Besucher in einem Zeitfenster ist gedeckelt. Das bremst automatisierten Spam, das Abtasten von Konten und die Erschöpfung unserer E-Mail-Kapazität.

Der Zähler dieser Begrenzung ist so abgeschottet, dass Nutzer 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 geprüft, bevor etwas gespeichert wird.
  • Datei-Uploads sind in Typ und Größe begrenzt und werden außerhalb der Anwendungsumgebung gespeichert.
  • Such- und Filterparameter werden geparst und validiert, nie direkt in eine Abfrage eingefügt.
08

Sichere Entwicklung

Der Webshop ist eine moderne serverseitig gerenderte Anwendung, in der Datenbankzugriffe ausschließlich über typisierte Serverfunktionen laufen. Abfragen sind parametrisiert, sodass SQL-Injection keinen Ansatzpunkt hat, und Ausgaben werden vom Framework standardmäßig maskiert, was Cross-Site-Scripting entgegenwirkt.

Geheimnisse wie API-Schlüssel stehen nie im Quellcode oder im Browser-Bundle. Sie werden als geschützte Umgebungsvariablen gelesen, wenn eine Serverfunktion ausgeführt wird.

  • Client- und Servercode sind strikt getrennt; reine Servermodule gelangen nicht in das Browser-Bundle.
  • Abhängigkeiten werden regelmäßig auf bekannte Schwachstellen geprüft und aktualisiert.
  • Änderungen werden vor dem Livegang in einer Vorschauumgebung getestet.
  • Die Datenbank wird regelmäßig mit einem Sicherheits-Linter auf fehlende Regeln und zu weite Rechte geprüft.
09

Hosting, Backups und Kontinuität

Die Anwendung läuft auf einer verwalteten Infrastruktur mit automatischer Zertifikatserneuerung, DDoS-Abwehr auf Netzwerkebene und einem weltweit verteilten Edge-Netzwerk. Die Datenbank steht in einem Rechenzentrum innerhalb der Europäischen Union, die Speicherung erfolgt verschlüsselt.

Backups werden täglich erstellt, mit Wiederherstellung auf einen früheren Zeitpunkt. Wiederherstellungsverfahren werden regelmäßig getestet.

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

Protokollierung, Überwachung und Datenpannen

Wichtige Ereignisse — Anmeldeversuche, Statusänderungen von Bestellungen, Administrationsvorgänge und Serverfehler — werden protokolliert. Protokolle enthalten keine Passwörter oder Zahlungsdaten und werden höchstens zwölf Monate aufbewahrt.

Bei Verdacht auf eine Datenpanne prüfen wir sofort den Umfang, schließen die Lücke und informieren Betroffene sowie, wo die DSGVO dies verlangt, die Aufsichtsbehörde innerhalb von 72 Stunden.

11

Was Sie selbst tun können

Sicherheit ist eine gemeinsame Aufgabe. Die meisten Vorfälle beginnen nicht bei der Website, sondern bei einem wiederverwendeten Passwort oder einer überzeugenden Phishing-Mail.

  • Verwenden Sie ein einzigartiges, langes Passwort und einen Passwortmanager.
  • Aktivieren Sie die Zwei-Faktor-Authentifizierung für alle im Firmenkonto.
  • Entfernen Sie ausgeschiedene Mitarbeitende sofort aus dem Konto.
  • Wir fragen niemals per E-Mail oder Telefon nach Passwort oder 2FA-Code.
  • Prüfen Sie geänderte Bankverbindungen auf Rechnungen immer telefonisch über die Nummer auf dieser Website.
12

Verantwortungsvolle Meldung von Schwachstellen

Sie haben eine Schwachstelle entdeckt? Melden Sie sie uns, bevor Sie sie veröffentlichen. Senden Sie eine E-Mail mit Beschreibung, betroffener URL und Reproduktionsschritten. Wir bestätigen den Eingang, halten Sie auf dem Laufenden und nennen Sie auf Wunsch namentlich, sobald das Problem behoben ist.

Wir bitten Sie: keine automatisierten Angriffe, die den Dienst stören, kein Zugriff auf Daten anderer Kunden, keine Änderungen oder Löschungen.

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.