Blog für Webdesign und Webentwicklung

Website-Sicherheit: 13 Ansätze zur Verbesserung der Frontend-Sicherheit

website security

Ein Gastbeitrag von Oliver Lindberg.

Einkäufe, Bankgeschäfte, nahezu unsere gesamte Kommunikation – bei all diesen Dingen verlassen wir uns zunehmend auf digitale Geräte. Aufgrund dieser Tatsache liegt es in unserer Verantwortung als Designer und Frontend-Entwickler, Kunden vor Betrug und Sicherheitsproblemen zu schützen. Dies gilt natürlich im gleichen Maße für Backend-Entwickler.

Unabhängig davon, ob du eine E-Commerce-Webseite entwickelst (wobei sich Shopify um den Großteil des Risikos kümmert) oder eine andere Art von Online-Erfahrung aufbaust, musst du dir vieler Fallstricke bewusst sein.

Für diesen Artikel haben wir sieben Sicherheitsexperten befragt, um die häufigsten Frontend-Schwachstellen zu ermitteln und herauszufinden, was du konkret tun kannst, um Risiken zu mindern und Hacks zu vermeiden.


Schau dir den monatlichen Beitrag zu unseren Produkt Updates an

Jetzt lesen


1. Sicherheit muss Teil des Entwicklungsprozesses sein

In letzter Zeit wurde das Thema Frontend-Performance in der Community heiß diskutiert. Vor diesem Hintergrund wurde dem Softwareentwickler Benedek Gagyi klar, wie ähnlich diese der Sicherheit ist:

„Ich nicke immer wieder, wenn ich höre, das man das Thema Sicherheit so früh wie möglich in den Entwicklungsprozess integrieren sollte. Gleiches gilt für die Aussage, dass die stärkste Kraft, die Sicherheits-Bemühungen entgegensteht, die Bequemlichkeit der Entwickler ist. Beides trifft sowohl in puncto Leistung als auch Sicherheit zu“, erklärt er.

„Es ist natürlich möglich, alle sicherheitsrelevanten Fehler und Lücken später im Entwicklungslebenszyklus zu beheben. Allerdings ist das wesentlich schwieriger und teurer als die Probleme direkt anzugehen. Aus diesem Grund sind das sogenannte Threat-Modelling, also eine Bedrohungsanalyse, und regelmäßige Sicherheitsüberprüfungen für jeden größeren Entwicklungsschritt von entscheidender Bedeutung. Denn es sorgt dafür, dass die Sicherheit von vornherein ein zentraler Bestandteil der Entwicklung ist und nicht nur als Patch berücksichtigt wird.“

Benedek weist darauf hin, dass ein Bewusstsein für Sicherheitsfragen zwar wichtig ist, dass jedoch mehr über die tatsächliche Erfahrung der Entwickler gesprochen werden sollte. 

„Aus meiner Sicht wird es viel weniger Sicherheitsfehler in Software geben, wenn sie mit Bibliotheken und Frameworks geschrieben wurde, die das Kreieren sicherer Software unterstützt. Das ist ziemlich trivial, oder?

Ein gutes Beispiel in der Frontend-Welt ist, wie die großen Frameworks die Anwender wissen lassen, ob sie sich für einen Cross-Site-Scripting-Angriff (XSS) öffnen. Dies geschieht, indem sie spezifische Namen für riskante Operationen wie dangerouslySetInnerHTML in React vergeben oder auch die bypassSecurityTrust APIs in Angular.“

2. Verwendung eines modernen Frameworks, das die Sicherheit automatisch verwaltet 

JavaScript-Frameworks sind zu einem wesentlichen Bestandteil der modernen Webentwicklung geworden. Die meisten Webseiten bauen heute auf einem Framework wie React, Vue oder Angular auf. Bezüglich der Sicherheit einer Seite, bieten sie erhebliche Vorteile. 

„Die Reinkarnation des Angular-Framework ist ein perfektes Beispiel“, sagt Philippe De Ryck, Gründer und Ausbilder für sicheres Programmieren bei Pragmatic Web Security. „Angular schützt automatisch vor einer Vielzahl von XSS-Angriffsvektoren. Es bietet eine automatische Verschlüsselung für einfache Ausgaben über {{}}. Bei der Verwendung von innerHTML bereinigt Angular die Ausgabe automatisch. Kommen variable URLs oder CSS zum Einsatz, stellt Angular zudem automatisch sicher, dass die Werte in diesem Kontext sicher verwendet werden können.“ 

Andere Frameworks bieten ähnliche Schutzfunktionen, sind laut Philippe jedoch nicht so umfangreich. Dennoch verringert die Verwendung eines modernen Frameworks die Risiken, die ein Entwickler zur Abwehr von XSS-Angriffen berücksichtigen muss, erheblich.

Lesetipp: Setze auf Vertrauen: Wie Apps für Shopify-Händler sicherer werden

3. Vermeidung typischer XSS-Fehler

Obwohl es bei der Verwendung moderner JavaScript-Frameworks viel seltener vorkommt, ist es immer noch möglich, unbeabsichtigte XSS-Fehler in dein Frontend zu programmieren. 

„Nehmen wir an, wir wollen einen Benutzer mit seinem Namen ansprechen, indem wir ihn über eine Marketing-E-Mail verlinken“, schlägt James Hall, Direktor der Agentur für digitale Innovation Parallax vor. „Das Hinzufügen von ?name=James zur Abfragezeichenfolge und das anschließende Hinzufügen zum DOM wäre ein schneller Weg, dies zu tun.“

Zum Beispiel folgendermaßen:

document.querySelector('.tagline').innerHTML = nameFromQueryString

James warnt jedoch davor, dass die Verwendung von Code wie dem oben genannten bedeutet, dass jedermann Code in die entsprechende Website einschleusen und die Seite beeinflussen kann. Er weist darauf hin, dass ein Angreifer allein durch die Änderung des Namens in <script src="my.malicious.site"> eine URL erstellen könnte, die eine gefälschte Zahlungsseite so aussehen lässt, als würde sie von deiner per SSL verschlüsselten Website bereitgestellt.

4. Berücksichtigung der „Trusted Types“

website security: trusted typesW3C Trusted Types

Selbst mit Gegenmaßnahmen wie einer Ausgabekodierung oder Bereinigung sind XSS-Angriffe immer noch ein großes Problem für Web-Anwendungen. Moderne Front-End-Frameworks wie Angular oder React sind gegen diese Art von Angriff nicht völlig immun", warnt Liran Tal, Entwicklervertreter bei der Open-Source-Sicherheitsfirma Snyk und Mitglied der Node.js Security Working Group.

Liran empfiehlt Trusted Types, eine neue Browser-API, die von den Google-Sicherheitsexperten Krzysztof Kotowicz und Mike Samuel favorisiert wird. Damit sollen XSS-Probleme behoben werden, indem die Spezifikation der Content Security Policy (CSP) genutzt werden (siehe Punkt 12 unten), um Vorlagen für Datenquellen zu definieren, die mit sensiblen APIs wie innerHTML-ähnlichen Sinks verwendet werden.

Die Spezifikation von Trusted Types muss noch reifen, aber Liran animiert Entwickler, sich für die Nutzung dieser sicheren API zu beginnen: 

„Glücklicherweise sehen wir Anzeichen einer verstärkten Annahme und Akzeptanz in der Frontend-Community“, sagt er. „Beispielsweise hat das React-Framework kürzlich eine Pull-Anforderung zusammengeführt, um die Unterstützung für Trusted Types in neueren Versionen weiter auszubauen.“

Lesetipp: Ein Insider-Blick auf die Technologie hinter Shopify.

5. Erwägung der Verwendung von textContent anstelle von innerHTML

Um XSS-Angriffe zu verhindern, kannst du eine Bereinigungsbibliothek wie DOMPurify verwenden (siehe Punkt 11 unten). Frontend-Berater Zell Liew schlägt jedoch vor, dass Entwickler, sofern sie nur Text ändern textContent anstelle von innerHTML verwenden.

„Nehmen wir an, du möchtest einen Textwert aus einem Eingabefeld erhalten und diesen Textwert in das DOM ausgeben. Hier ist der Code, um den Textwert zu erhalten:

const value = input.value

Ein Nutzer mit schlechten Absichten, kann jedoch versuchen, etwas wie folgendes Snippet einzugeben:

<img src="x" onerror=alert("HACKED!")>

Wenn Sie innerHTML verwenden, legen Sie das Element <img> an und führen den onerror handler aus. Hier beginnt XSS.“

Zell empfiehlt stattdessen die Verwendung von textContent, da es nur Text ausgeben kann und kein HTML generiert. 

„Wenn du kein HTML generierst, gibt es keine Möglichkeit, JavaScript einzufügen“, erklärt Zell. Im DOM wird <img src="x" onerror=alert("HACKED!")>angezeigt, das JavaScript wird jedoch nicht ausgeführt.

6. Aufteilen von Anwendungen 

Webanwendungen werden häufig als einzelne Anwendungen erstellt, die an einem einzigen Punkt im Browser bereitgestellt werden. Beispielsweise bietet eine App, die unter https://app.example.com läuft, frei zugängliche Parts, authentifizierte Parts und sogar Administratorfunktionen.

Philippe De Ryck warnt jedoch davor, dass ein erfolgreicher Angriff auf den frei zugänglichen Teil der Anwendung automatisch auch die anderen Teile betreffen und möglicherweise erheblichen Schaden anrichten kann.



„Im Backend werden monolithische Anwendungen oft in kleinere Komponenten aufgeteilt, die jeweils einzeln ausgeführt werden“, erklärt er. „Ein ähnliches Muster können wir auch für Front-End-Anwendungen benutzen. Beispielsweise könnten wir die Frontend-Anwendung in einen frei zugänglichen Part, einen authentifizierten Part und einen administrativen Part trennen.

Durch die Bereitstellung jedes Teils in einem separaten Ursprung – zum Beispiel https://public.example.com, https://users.example.com und https://admin.example.com  können wir sicherstellen, dass der Browser diese Anwendungen voneinander isoliert.“

Die Aufteilung ist der Schlüssel zur Verringerung von Schwachstellen auf der Kundenseite", glaubt Philippe. „Eine ordnungsgemäße Aufteilung würde verhindern, dass eine XSS-Schwachstelle im öffentlichen Teil der Anwendung automatisch auch die Benutzerinformationen gefährdet.“

Lesetipp: 3 einfache Schritte zur Einrichtung einer lokalen Entwicklungsumgebung für Shopify Themes.

7. Vorsicht bei der Verwendung des Google Tag Manager

website security: google tag managerWer Personen und Unternehmen Zugriff auf seinen Google Tag Manager gewährt, sollte äußerst vorsichtig sein.

Die Verwendung des Google Tag Manager macht es sehr einfach, die neuesten Tracking-Skripte, den vom Support-Team gewünschten Chatbot und Hotjar für Benutzeranalysen hinzuzufügen. 

James Hall weist jedoch darauf hin, dass es verlockend ist, jedem in einer Organisation (und manchmal auch außerhalb) Zugriff auf den Google Tag Manager zu gewähren. Dennoch solltest du unbedingt Vorsicht walten lassen und dir gut überlegen, wer auf den Manager zugreifen darf und wer nicht.

Er warnt: „Wenn ein Google-Konto gehackt wird, ist es möglich, einer Webseite jedes beliebige JavaScript hinzuzufügen. Ein raffinierter Angriff könnte die Benutzer auf eine gefälschte Zahlungsseite führen, damit sie ihre Bestellung abschließen und Geld an einen Schwindler überweisen.“

8. Selektiver Umgang mit Skripten von Drittanbietern

Selbst wenn der Zugriff auf deinen Google Tag Manager nicht gefährdet ist, könnten die Tracking-Skripte, die du hinzufügen möchtest, gehackt werden. Die Verwendung von Bibliotheken von Drittanbietern und Open-Source-Komponenten in JavaScript-basierten Webanwendungen ist eine gängige Praxis. Sie schwächt jedoch dein System und lässt sich nur bis zu einem gewissen Grad kontrollieren.

„Wenn du das Chat-Widget „flavor-of-the-week“ zu deiner Website hinzufügst, kann nun jeder, der Zugang zu deren Servern hat, deine Website verändern“, warnt James Hall. „Dies passierte British Airways und Ticketmaster, als sie eine Bibliothek für Push-Benachrichtigungen namens Feedify einfügten.

James sagt, dass eine selektive Entscheidung darüber, welche externen Parteien Zugang zu deinen Seiten haben, auch dabei helfen wird, die Anforderungen der DSGVO einzuhalten. Je weniger Informationen du an Dritte weitergibst, desto weniger musst du in deiner Datenschutzrichtlinie darauf aufmerksam machen, was mit ihren Daten geschieht. Und das bedeutet wiederum, dass die Wahrscheinlichkeit eines Verstoßes gegen die DSGVO eingeschränkt wird. 

Anstatt dein JavaScript-Framework von Drittanbietern hosten zu lassen, empfiehlt James, Shopify mit dem Hosting zu beauftragen: 

Shopify kann dich besser vor potenziellen Gefahren schützen, als automatisch die neueste Version einer Open-Source-Abhängigkeit per Hotlink zu verknüpfen.

Lesetipp: Aus dem Ladengeschäft in den Onlineshop: 12 Tipps für die Zusammenarbeit mit E-Commerce-Einsteigern.

9. Überprüfen bestehender Abhängigkeiten

Wahrscheinlich verwendest du viele lokale Build-Tools zur Erstellung deines Frontends, zum Beispiel SCSS-Plugins. James Hall rät, regelmäßig npm audit durchzuführen, um eine Liste der anfälligen Pakete anzeigen zu lassen und diese zu aktualisieren. So kann vermieden werden, dass Sicherheitsprobleme versehentlich in die von dir erstellten JavaScript-Dateien aufgenommen werden.

Wenn du GitHub verwendest, wird es anfällige Abhängigkeiten kennzeichnen. Zudem gibt es alternative Dienste wie Snyk, die deinen Quellcode automatisch überprüfen und Pull-Anfragen für Bump-Versionen öffnen können.

Falls du ein Theme für einen Kunden ohne Zugriff auf den Google Tag Manager erstellst, empfiehlt James die Durchführung einer Schnellprüfung mit einem Tool wie BuiltWith.

website security: builtwithMit BuiltWith lässt sich exakt herausfinden, mit welcher Art von Tools und Technologie eine Website erstellt wurde.

10. Verwendung von Subresource Integrity für CDN-Hosting von Drittanbietern

Manchmal kommt man dennoch nicht um den Einsatz von Drittanbietern herum. Liran Tal von Snyk weist deshalb darauf hin, dass wir häufig extern gehostete Bibliotheken für Schriften und CSS verwenden und diese in Webanwendungen mit einem Content-Delivery-Network (CDN) importieren. 

„Was würde passieren, wenn sich jemand Zugang zum Code dieser Bibliotheken verschaffen und ihn durch seine eigene Version ersetzen würde“, fragt er. „Was würde passieren, wenn das Netzwerkmedium angegriffen oder als unsicher eingestuft würde? Sogar unser eigener Quellcode könnte durch Angreifer kompromittiert werden, die sich Zugang zu einem Build-Server, zum Cache oder Speicher unseres eigenen Codes, der von einem CDN ausgeliefert wird, verschaffen.“

Um dieses Problem zu lösen, schlägt Liran Subresource Integrity vor. Hierbei handelt es sich um eine Spezifikation, die die Integrität der in einer Webseite verwendeten Ressource nachweist und belegt, dass ihr Inhalt nicht manipuliert wurde. Ressourcen werden unter Verwendung eines Integritätsattributs deklariert, das einen kryptographischen Hash verwendet, den der Browser vor einer funktionalen Nutzung der Ressource validiert.

James Hall stimmt dem zu und sagt, dass Subresource Integrity hervorragend geeignet ist, um sicherzustellen, dass das Asset mit jenem identisch ist, das tatsächlich einbezogen werden soll. Dies ist eine Prüfsumme, die sicherstellt, dass dein Skript unverändert ist:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jspdf/1.5.3/jspdf.debug.js"integrity="sha384-NaWTHo/8YCBYJ59830LTz/P4aQZK1sS0SneOgAvhsIl3zBu8r9RevNg5lHCHAuQ/" crossorigin="anonymous"></script>

11. HTML-Verschlüsselung reicht nicht aus

Ilya Verbitskiy, Gründer von WebStoating, einer Agentur, die Unternehmen beim Aufbau eines erfolgreichen Online-Business unterstützt, empfiehlt, der HTML-Verschlüsselung besondere Aufmerksamkeit zu schenken. 

„Es funktioniert gut, wenn die Eingabe eines Benutzers in einem HTML-Tag platziert wird, zum Beispiel mit den Tags <div> oder <p>. Dies funktioniert auch für die Daten, die in HTML-Attributen verwendet werden. Die HTML-Verschlüsselung wird jedoch nicht helfen, wenn du die Eingabe eines Benutzers innerhalb eines <script>-Tags, in einer URL oder innerhalb eines event handlers wie onclick oder onerror wiedergibst.“

Dementsprechend weist Ilya darauf hin, dass beispielsweise das folgende Snippet gefährlich ist:

<a href="https://example.com" onmouseover="@Model.UserInput">Sample Link</a>

Es ist gefährlich, weil Model.UserInput  möglicherweise alert(document.location) sein kann oder auch: 

eval(String.fromCharCode(105,102,40,33,119,105,110,100,111,119,46,120,41,123,97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,108,111,99,97,116,105,111,110,41,59,119,105,110,100,111,119,46,120,61,49,59,125))

Ein anderer gefährlicher Code könnte folgendermaßen aussehen:

<a href="@Model.UserLink">Sample Link</a>

In diesem Fall könnte  Model.UserLink Folgendes sein: 

javascript:eval(String.fromCharCode(105,102,40,33,119,105,110,100,111,119,46,120,41,123,97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,108,111,99,97,116,105,111,110,41,59,119,105,110,100,111,119,46,120,61,49,59,125))

Dies führt zu Problemen für die Benutzer, da das Skript ausgeführt wird, sobald der Benutzer darauf klickt.

„Es ist keine leichte Aufgabe, alle Verschlüsselungen zu schreiben, um XSS zu verhindern“, gibt Ilya zu. „Erstens sollte die Bibliothek verschiedene Ausführungskontexte unterstützen. Zweitens muss sie unterschiedliche von Browsern unterstützte Verschlüsselungen verstehen und sich potenziell gefährlicher HTML-Attribute bewusst sein, die herausgefiltert werden müssen.“

Ilya empfiehlt die Verwendung von Bibliotheken, die bereits empfohlene XSS-Schutztechniken implementiert haben und frei verfügbar sind. Zum Beispiel: 

  • DOMPurify ist einfach zu bedienen, da es nur eine Methode zur Bereinigung der Benutzereingaben gibt. Die Standardrichtlinie wurde von mehreren Benutzern erprobt, bietet die Möglichkeit zur Anpassung von Regeln und unterstützt HTML5, SVG und MathML.
  • secure-filters: Diese Bibliothek von Salesforce bietet Methoden zur Bereinigung von HTML, JavaScript, Inline-CSS-Stilen und anderen Inhalten. Sie ist besonders nützlich, wenn Benutzereingaben an anderen Stellen genutzt werden sollen, z. B. bei der Generierung von CSS oder JavaScript.

12. Implementieren von Content Security Policy (CSP)

website security: content security policyDie Content Security Policy (CSP).

„Layered Security“ oder „Layered Defence“ sind bekannte Ansätze im Bereich der Cybersicherheit und beschreiben die Kombination mehrerer Sicherheitskontrollen zum Schutz von Daten. Ilya Verbitskiy erklärt, dass sich dieses Prinzip auch auf die Frontend-Sicherheit anwenden lässt.

„Selbst wenn die Website über eine XSS-Schwachstelle angegriffen wird, müssen wir den Schaden für die Benutzer minimieren. Das typische Ergebnis eines XSS-Angriffs ist, dass Skripte in eine anfällige Webseite eingeschleust werden“, erklärt Ilya. „Das Skript stiehlt entweder die Cookies und Daten eines Benutzers aus lokalen und Sitzungsspeichern, schleust einen Keylogger ein oder betreibt sogar das Mining von Cryptowährungen.

Die meisten Angriffe erfordern einen Kanal zur Kommunikation zwischen dem Server des Hackers und dem Opfer. Dieser Kommunikationskanal kann ein AJAX-Aufruf, ein <img>-Tag, ein iframe oder ein Web-Socket sein. Ziel sollte es sein, den Kommunikationskanal zu unterbrechen.“

Alle modernen Browser haben bereits eine Lösung hierfür implementiert: Content Security Policy (CSP), eine zusätzliche Sicherheitsebene, die dazu beiträgt, bestimmte Arten von Angriffen, einschließlich XSS und Data-Injection, zu erkennen und abzuwehren. Um CSP zu aktivieren, musst du deinen Webserver so konfigurieren, dass er den HTTP-Header Content-Security-Policy zurückgibt. Er hilft, XSS-Risiken zu verringern, indem er angibt, welche Ressourcen geladen werden dürfen. Zum Beispiel: 

Content-Security-Policy: default-src 'self'; child-src child-src 'none'; img-src https://cdn.example.com 'self'; object-src 'none'

Wenn deine Website-URL https://example.com lautet, blockiert CSP die Verwendung der Tags <embed>, <object> und <applet> sowie von Frames und Web-Workern. Somit wird der Browser nur Bilder von https://example.com und https://cdn.example.com laden. Alle anderen Ressourcen, wie Skripte und Stylesheets, müssen auf https://example.com gehostet werden.

Alternativ lässt sich eine Richtlinie auch mithilfe des <meta>-Tags innerhalb deiner HTML-Seite definieren:

<meta http-equiv="Content-Security-Policy" content=" default-src 'self'; child-src child-src 'none'; img-src https://cdn.example.com 'self'; object-src 'none' ">

Content Security Policy bietet eine Vielzahl von Leitlinien, die dir dabei helfen, die für dein Projekt am besten geeignete Richtlinie zu definieren. Einige der am weitesten verbreiteten Richtlinien sind default-src, child-src, script-src, style-src, img-src und connect-src. Ilya empfiehlt, default-src immer als Fallback zu definieren, falls du einmal eine Leitlinie vergessen solltest.

13. Mehr Bewusstsein über exponierte Elemente

Zu guter Letzt solltest du unbedingt auf die Daten achten, die über das Frontend bloßgelegt werden. 

„Die Verwendung von JSON auf der Produktseite kann in einigen Fällen vorteilhaft sein. Es kann aber auch bedeuten, dass private Händlerdaten im Frontend angezeigt werden“, warnt Kelly Vaughn, Gründerin von The Taproom Agency. „Eine gute Praxis ist es, diese Art von Daten in einem Metafeld zu speichern, da jedem eindeutigen Metafeld manuell die Berechtigung erteilt werden muss, über die API ausgelesen zu werden.“

Und wenn eine Quellcodekontrolle für die Theme-Entwicklung wie GitHub verwendet wird, sollten API-Schlüssel stets verborgen gehalten werden, so Kelly. Wenn du deine Datei config.yml oder .env auf GitHub zur Verfügung stellst, hat jeder Zugriff auf das Theme deines Shops (und auf alle zusätzlichen Berechtigungen, die du über die private App zugelassen hast).

Außerdem solltest du nur den Zugriff auf die Funktionen erlauben, die du wirklich für eine App benötigst. Wenn du eine private App zum Erstellen oder Ändern eines Themes verwendest, solltest du jeglichen Zugriff mit Ausnahme von Themes mit Lese- und Schreibzugriff verbieten.

Sicherheit fördert das Vertrauen

Das Thema Sicherheit ist wichtiger als je zuvor. Verstöße können jeden treffen, ob es sich nun um ein großes Unternehmen oder eine kleine Website handelt. Deswegen müssen Entwickler aufpassen, dass keine Kundendaten preisgegeben werden und sich der vielen möglichen Angriffe und der Fehler bewusst sein, die bei der Bereitstellung einer Website oder einer App auftreten können. Moderne JavaScript-Frameworks übernehmen einen Großteil des Risikos, dennoch sollte sich kein IT-Spezialist ganz auf sie verlassen.

Endverbraucher erwarten, dass ihre Online-Erfahrung sicher ist und dass die von ihnen bereitgestellten Informationen nicht gestohlen oder auf unerwartete Art und Weise verwendet werden. Deine Kunden wiederum erwarten, dass du ihre Websites, ihre Daten und ihre Käufer schützt.

Wenn du den verschiedenen Ansätzen zum Schutz von Websites und der Beseitigung von Schwachstellen, die wir in diesem Artikel untersucht haben, folgst, wirst du zeigen, dass du das Thema Sicherheit ernst nimmst und das Vertrauen deiner Kunden gewinnen.

Dieser Beitrag von Oliver Lindberg erschien zuerst im englischen Shopify Blog und wurde übersetzt.

Wie gehst du in Sachen Sicherheit vor? Hast du vielleicht deine ganz eigenen Best Practices? Lass es uns in den Kommentaren unten wissen.


Bring dein Geschäft mit dem Shopify-Partnerprogramm voran

Mehr Informationen