10 Security-Fails im Web und E-Commerce

Alles, was online ist, ist ein Touchpoint – also sichtbar, auffindbar und grundsätzlich angreifbar. Intern kannst du dir manchmal einreden, dass ein Thema „später“ reicht, weil es ohnehin nur wenige sehen oder weil Konsequenzen zeitverzögert eintreten. Online funktioniert diese Logik nicht. Du siehst nicht, wer gerade scannt, testet oder automatisiert nach Schwachstellen sucht – aber du kannst sicher sein: Es passiert. Und zwar nicht als Hobby, sondern als Geschäftsmodell.

Was viele unterschätzen: Der unmittelbare Schaden entsteht selten durch „Datenschutz als Papierproblem“, sondern durch Betriebsunterbrechung. Wenn Systeme verschlüsselt sind, wenn Shops nicht mehr erreichbar sind oder wenn Accounts übernommen werden, hast du nicht irgendwann ein Ergebnis aus einem Verfahren – du hast sofort ein Problem im Betrieb. Genau deshalb lohnt sich der Blick auf typische Web- und E-Commerce-Fails. Nicht, weil du paranoider werden sollst, sondern weil du die häufigsten Einfallstore mit überschaubarem Aufwand entschärfen kannst. Und ja: Die Größenordnung ist real – Bitkom beziffert die wirtschaftlichen Schäden durch Cyberangriffe auf Unternehmen in Deutschland für 2025 auf 200 Mrd. Euro.

Darum werfen wir heute einen klaren Blick auf die zehn gängigsten Sicherheits-Fails im Web und E-Commerce – nicht theoretisch, sondern so, wie sie in der Praxis wirklich passieren. Zu jedem Punkt zeige ich dir, was konkret dahintersteckt, warum es gefährlich wird und welche Maßnahmen du sofort umsetzen kannst, um dich und deine Websites wirksam zu schützen. Und damit das Ganze nicht nur Lesestoff bleibt, sondern in deinem Unternehmen auch angewendet wird, bekommst du zusätzlich eine kompakte, praxisnahe Checkliste von mir – kostenlos zum Download und direkt einsetzbar im Alltag.

Der Klassiker: Es gibt eine Entwicklungs- oder Testumgebung, eine Beta, eine alte Relaunch-Seite – und sie ist ohne Schutz erreichbar. Die Begründung ist fast immer dieselbe: „Da kommt doch keiner drauf.“ In der Praxis kommt sehr wohl jemand drauf: Suchmaschinen, Bots, Crawler und Menschen, die genau nach solchen Mustern suchen. Und wenn so eine Umgebung irgendwo verlinkt wird (intern, in Mails, in Tickets, in Projektboards), landet sie schneller in Indizes, als dir lieb ist.

Das Problem daran: Testumgebungen sind oft schlechter abgesichert als das Live-System. Sie enthalten Testdaten, manchmal sogar echte Live-Daten. Oder sie laufen mit Debug-Features, offenen Verzeichnissen, Standard-Zugängen oder „temporären“ Plugins, die nie wieder rausfliegen. Wenn du nur eine Sache hier sofort mitnimmst: Eine Testumgebung ist nicht „harmlos“, nur weil sie „Test“ heißt. Für Außenstehende ist das eine öffentlich erreichbare Anwendung – fertig.

Was du konkret tun solltest: konsequenter Zugriffsschutz (z. B. Basic Auth/htaccess oder ein Wartungsmodus mit Passwort), saubere Robots-/Index-Strategie, und vor allem: Testumgebungen wie produktive Systeme behandeln – inklusive Logging, Updates und Datenhygiene.

Viele Teams versuchen, die Datenschutzerklärung „automatisch“ zu erzeugen: einmal Online-Scanner drüberlaufen lassen, fertig. Das scheitert technisch schon daran, dass gute Webseiten Einwilligungen einholen, bevor einwilligungspflichtige Dienste geladen werden. Der Scanner kann diese Einwilligung nicht sinnvoll geben – und sieht dann im Zweifel genau die Dienste nicht, die später nach Consent geladen werden. Ergebnis: unvollständige Datenschutzerklärungen, fehlende Dienstelisten, falsche Annahmen.

In der Praxis brauchst du zwei Dinge: Erstens eine verlässliche Liste aller eingesetzten Dienste (auch in Apps oder eingebetteten Dritttools, wo du technisch oft gar nicht alles „siehst“). Zweitens einen Prozess, der Änderungen abbildet: neue Plugins, neue Tags, neue Marketing-Tools, neue A/B-Tests. Wenn du als DSB/ISB drauf schaust, fordere diese Liste ein – von Agenturen, Dienstleistern und intern vom Marketing. Wenn du Unternehmen bist: mach diese Liste zur Pflichtlieferung in Projekten. Scanner können unterstützen, aber sie ersetzen nicht das Inventar.

Formulare wirken langweilig: ein paar Felder, ein Senden-Button. In Wirklichkeit sind sie oft der „Vorhof zur Hölle“, weil hier echte Interaktion stattfindet. Drei typische Risiken tauchen immer wieder auf.

Erstens: ungeschützte Formulare werden massenhaft befüllt. Das ist nervig – und kann je nach Autoresponder-Logik sogar dazu führen, dass du unbeabsichtigt Spam an Dritte verschickst, weil Bots fremde Mailadressen eintragen und dein System automatisiert antwortet.

Zweitens: Upload-Funktionen. Wenn Dateien hochgeladen und anschließend öffentlich aufrufbar sind – oder wenn Uploads sogar ausführbar werden – hast du ein Einfallstor, das Angreifer lieben. Das ist kein theoretisches Risiko, sondern ein Muster, das man in echten Plugin-Schwachstellen immer wieder gesehen hat.

Drittens: Formulare werden zu Datengräbern. Gerade Bewerbungsformulare sind ein gutes Beispiel: Du hast intern vielleicht ein Löschkonzept, aber parallel speichert das Webformular Anhänge und Inhalte jahrelang auf dem Server, weil nie jemand aufräumt. Kombinierst du das mit einem späteren Zugriff auf den Server, hast du sehr schnell einen großen Datenschutzvorfall, obwohl „eigentlich“ doch alles geregelt war.

Was du brauchst: Bot-Schutz (nicht nur Captcha, sondern Rate-Limits, Abuse-Detection), harte Upload-Regeln (Whitelist, Virenscan, kein direkter öffentlicher Zugriff, keine Ausführung), und ein Rotations-/Löschkonzept für Formularspeicher – automatisiert, nicht „bei Gelegenheit“.

„Bei mir kommt die Mail an“ ist kein Test. Gerade nach Serverumzügen oder Providerwechseln kippt die Zustellbarkeit, weil die DNS-Policies nicht angepasst werden. Ohne SPF/DKIM (und sinnvoll ergänzt: DMARC) riskierst du zwei Dinge: legitime Mails landen häufiger im Spam oder kommen gar nicht an – und dein Absender kann leichter missbraucht werden (Spoofing), je nachdem wie Empfänger prüfen. Das ist nicht nur nervig, sondern im Worst Case ein Einfallstor für Betrug über „deine“ Domain.

Wenn du nur pragmatisch starten willst: Lass deine IT prüfen, ob SPF und DKIM sauber gesetzt sind und ob DMARC sinnvoll ausgerollt ist (mit einem realistischen Monitoring, nicht blind auf „reject“).

Drittanbieter sind bequem. Und genau das ist das Problem: Du holst dir fremden Code in dein Herzstück – und weißt oft nicht, was er tut, wie er gepflegt wird und wie schnell Sicherheitslücken gefixt werden. Bei WordPress zeigt sich diese Realität sehr deutlich: Ein großer Teil gemeldeter Schwachstellen betrifft Plugins, nicht den Core.  

Praxisregel: Jedes Plugin ist ein Risiko-Trade-off. Du willst Nutzen, aber du übernimmst damit auch Fremdrisiko. Deshalb: nur so wenig wie möglich, nur so viel wie nötig. Und: Prüfe Reputation, Update-Frequenz, Support, Code-Qualität (soweit möglich) und ob das Plugin wirklich noch aktiv gepflegt wird. Wenn du es nicht beurteilen kannst, beurteile wenigstens die Signale: Bewertungen, Changelog, Reaktionsgeschwindigkeit bei Security-Themen.

KI-gestütztes Programmieren ist gekommen, um zu bleiben. Es spart Zeit, es kann Qualität heben – aber es produziert dir nicht automatisch sichere Software. Wenn du Code generieren lässt, musst du ihn verstehen, reviewen und testen, sonst bekommst du neben dem gewünschten Verhalten oft ungewollte Nebenwege: fehlende Input-Validierung, unsichere Defaults, „praktische“ Debug-Endpunkte, zu großzügige Berechtigungen oder unbedachte Datenflüsse.

„In der Praxis sehe ich immer wieder, dass Teams KI-Code wie ein fertiges Bauteil behandeln – dabei ist es eher wie ein Rohteil: Du musst es prüfen, nachbearbeiten und absichern, bevor es in Produktion darf.“

Wenn du Vibecoding nutzt, mach Peer-Reviews zur Regel und baue Tests für Missbrauchsszenarien ein, nicht nur für den Happy Path.

„Das Kennwort ist doch geheim“ – ja, aber oft auch kurz, wiederverwendet und mehrfach geteilt. Und Kennwörter werden schneller angreifbar, weil Rechenleistung und Tools besser werden. Selbst ohne dramatische Einzelzahlen ist die Richtung eindeutig: Was sich vor kurzem „okay“ anfühlte, ist heute oft zu schwach. Hive Systems zeigt genau diese Dynamik in den regelmäßig aktualisierten Passwort-Tabellen.  

Dazu kommt die Realität der Wiederverwendung: Du kannst das „perfekte“ Passwort haben – wenn du es an anderer Stelle nutzt und dort ein Leak passiert, ist es verbrannt. Deshalb sind Passwortmanager und einzigartige Passwörter pro Dienst kein Luxus, sondern Basis.

Und MFA ist der Hebel mit der besten Kosten-Nutzen-Quote: Gerade Admin-Accounts gehören hinter Multi-Faktor-Authentifizierung, ohne Diskussion.

Berechtigungsmanagement ist unbequem. Und genau deshalb wird es ignoriert. Wenn alle Admin sind, ist ein kompromittierter Account gleich ein kompromittiertes System. Zusätzlich hast du forensisch ein Problem: „War keiner“ ist dann oft gar nicht mal gelogen, weil niemand sauber nachvollziehen kann, wer was getan hat.

Konkrete Praxis: Rolle statt Person. Minimale Rechte. Admin nur, wenn wirklich nötig. Und: getrennte Admin-Accounts (kein Daily-Driver-Account mit Adminrechten).

Ungepatchte Systeme sind offene Türen. Und je verbreiteter eine Software ist, desto eher wird automatisiert geprüft, ob sie verwundbar ist. Genau deshalb sind regelmäßige, zeitnahe Updates so wichtig – nicht als Ritual, sondern als echte Risikosenkung. Bei WordPress kommt erschwerend hinzu, dass viele Schwachstellen in Plugins sitzen, die oft nicht im gleichen Rhythmus gepflegt werden wie der Core.  

Das Entscheidende ist weniger „Update immer sofort“, sondern „kritische Security-Updates mit Priorität, und zwar mit einem Prozess, der nicht vom Zufall lebt“. Wenn du dafür eine Staging-Pipeline brauchst: gut. Aber dann muss diese Staging-Umgebung eben auch geschützt sein – damit schließt sich der Kreis.

Backups sind kein Gefühl und keine Annahme, Backups sind eine Vereinbarung plus ein Test. Drei Fragen entscheiden, ob dein Backup im Ernstfall hilft.

Erstens: Gibt es überhaupt Backups, und was genau wird gesichert (Datenbank, Dateien, Media, Konfiguration, Mail, Keys)? 

Zweitens: Passt das Intervall zu deinem Geschäft (Monatsbackup für einen Shop ist im Zweifel ein teurer Witz). 

Drittens: Hast du Restore-Tests, also wirklich geprobte Wiederherstellung? Ohne Restore-Test hast du keine Sicherheit, sondern Hoffnung.

Häufig ist das eigentliche Problem nicht, dass Unternehmen keine Backups haben – sondern dass niemand einmal sauber getestet hat, ob man daraus in akzeptabler Zeit wirklich wieder online kommt.

Und denk an die Trennung: Wenn Backups auf derselben Infrastruktur liegen und mit denselben Zugängen erreichbar sind, kann ein Angreifer sie oft gleich mit löschen oder verschlüsseln. Das Backup muss auch organisatorisch und technisch „weg“ sein.

1. Denke wie ein Angreifer
   Der wichtigste Schritt ist, dass du beginnst wie ein Angreifer zu denken, ohne dich verrückt zu machen. Wo sind öffentlich erreichbare Nebenflächen wie Stagings, alte Subdomains, Upload-Endpunkte und Formulare, und wie sind sie abgesichert? 
2. Räume Zugänge und Berechtigungen auf
   Direkt danach kommt Ordnung bei Zugängen: MFA für Admins, keine geteilten Logins, eindeutige Verantwortlichkeiten und regelmäßiges Aufräumen von Ex-Mitarbeitenden und Dienstleistern. 
3. Prüfe, welche Daten du wirklich brauchst und speicherst
   Parallel prüfst du, welche Daten du überhaupt einsammelst, wo sie landen und wie sie automatisiert wieder verschwinden – gerade bei Formularen. 
4. Hinterfrage alles, was von außen kommt
   Dann nimmst du alles „von außen“ ernster: Plugins, Add-ons und KI-generierter Code müssen bewertet, minimiert und reviewed werden. 
5. Teste deine Backups - wirklich
   Und zuletzt machst du Backups real: geprüft, wiederherstellbar, mit passendem Intervall und klarer Zuständigkeit.

Web- und E-Commerce-Sicherheit ist keine Disziplin für „später“, weil online eben sofort exponiert ist. Die typischen zehn Fails sind keine exotischen Hackertricks, sondern Alltagsfehler: offene Staging-Umgebungen, unkontrollierte Formulare, blindes Vertrauen in Plugins, schwache Zugänge, verschleppte Updates und Backups ohne Restore-Test. Wenn du hier sauber aufräumst, reduzierst du nicht nur Datenschutzrisiken, sondern vor allem das unternehmerische Risiko durch Ausfälle, Kontoübernahmen und kompromittierte Systeme – und das sind die Schäden, die in der Praxis richtig wehtun.

Als kleiner Bonus: Drei Impulse, die dir langfristig Ärger Sparen

Erstens: Mach Mitarbeitende zur stärksten Verteidigungslinie. Security scheitert selten an fehlenden Tools, sondern an fehlender Aufmerksamkeit im Alltag. Kurzformate, regelmäßiger Austausch, konkrete Beispiele aus eurem Kontext – das wirkt mehr als ein 40-Seiten-PDF, das niemand liest.

Zweitens: DSB und ISB brauchen tatsächlich „Freunde“ – sprich: Einbindung frühzeitig, nicht am Tag vor dem Relaunch. Wenn Datenschutz und Sicherheit erst kurz vor Livegang geprüft werden sollen, bleibt nur noch Risiko-Verwaltung statt saubere Lösung. Früh eingebunden findet man fast immer pragmatische Wege, die das Geschäft nicht ausbremsen.

Drittens: Behandle deine Website wie einen lebenden Organismus. Zwischen Relaunch und Relaunch passieren Content-Änderungen, Tool-Wechsel, neue Tags, neue Plugins, neue Anforderungen. Eine regelmäßige Prüfung – in vielen Fällen mindestens jährlich, bei kritischen Shops häufiger – ist weniger Aufwand als der Incident, der sonst irgendwann garantiert kommt.

Wenn du das Thema Web- und E-Commerce-Sicherheit strukturiert angehen willst, mach daraus keinen Einmal-Workshop, sondern einen Prozess: kurze Awareness-Formate im Team, klare technische Mindeststandards (MFA, Update-Policy, Plugin-Regeln), und feste Prüfpunkte vor und nach Änderungen. Wenn du Schulungen planbar über das Jahr hinweg aufsetzen willst, kann eine Lernplattform helfen, damit nicht alles an einzelnen Personen hängt – und damit Nachweise und Zielgruppen (Geschäftsführung, IT, Marketing) sauber abbildbar sind.

Theorie allein schützt keine Website. Entscheidend ist, dass Sicherheitsmaßnahmen im Alltag konsequent umgesetzt und regelmäßig überprüft werden. Genau dabei unterstützt dich unsere Checkliste: Sie führt dich strukturiert durch die typischen Schwachstellen im Web- und E-Commerce-Bereich – von Staging-Umgebungen über Formulare und Plugins bis hin zu Zugängen, Updates und Backups.

Mit unserer Checkliste kannst du deine Website und angebundene Systeme systematisch durchgehen – gemeinsam mit IT, Agentur oder Dienstleistern. Du klärst Zuständigkeiten, hinterfragst technische Schutzmaßnahmen, prüfst Datenflüsse und sicherst organisatorische Prozesse ab. So wird IT-Sicherheit nicht nur diskutiert, sondern konkret umgesetzt – nachvollziehbar, dokumentierbar und praxisnah.