Sécurité du SDK Web

Rokt s'engage à garantir que nos intégrations SDK Web sont sécurisées, et nous nous efforçons d'intégrer la sécurité dans nos produits dès le départ. Nous prenons également toutes les précautions nécessaires pour garantir que les données des clients sont gérées avec les contrôles les plus stricts. C'est un effort continu, et nous visons à améliorer de manière itérative nos processus, contrôles et technologies pour une plus grande sécurité.

Objectifs

Les objectifs de sécurité de Rokt incluent :

• Les partenaires doivent avoir le contrôle sur les données disponibles pour Rokt
• Aucun code malveillant ne doit être exécuté accidentellement ou intentionnellement sur la page du partenaire
• Aucun code malveillant ne doit pouvoir accéder arbitrairement aux informations privées des clients incluses sur la page hôte

Approche

Rokt pousse la majorité des fonctionnalités dans des iframes cross-origin isolées pour maintenir une surface minimale sur la page parente. La page parente doit inclure le Rokt Integration Launcher, qui a un ensemble de dépendances très minimal. Ces dépendances gèrent ensemble l'orchestration des actifs Rokt tout en fournissant une interface propre et minimale à la page parente. Cela permet une intégration plus facile mais nécessite un certain degré de confiance dans le code Rokt qui s'exécute sur la page parente.

Pour établir cette confiance, Rokt utilise les techniques suivantes :

• Versions modernes et à jour des bibliothèques et des dépendances des frameworks
• Liste blanche des sources autorisées des scripts Rokt
• Prise en charge de paramètres de Content Security Policy (CSP) plus stricts, notamment en interdisant "unsafe-eval" et "unsafe-inline"
• Contenus d'iframe isolés avec passage de messages contrôlé par l'origine en utilisant postMessage

Fonctionnalités de sécurité

Content Security Policy (CSP)

Le SDK Web de Rokt prend en charge les paramètres CSP recommandés qui empêchent les scripts en ligne et l'utilisation de eval dans les scripts. Il s'efforce également de charger le moins de fonctionnalités possible sur la page du partenaire. Cette approche nous permet de réduire au minimum les modifications des paramètres CSP du partenaire. Les directives CSP requises impliquent d'ajouter les domaines suivants à la liste autorisée :

script-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com https://sourcemaps-wsdk.roktinternal.com;
frame-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;

La source du script est nécessaire pour charger le lanceur dans la page du partenaire. Dans le cas où les partenaires hébergent eux-mêmes le fichier, ce changement n'est pas nécessaire. La source du cadre nous permet de charger les iframes isolés de Rokt.

remarque

Si vous n'utilisez pas CSP ou n'utilisez pas les directives script-src ou frame-src, n'ajouter que ces changements peut avoir un effet négatif sur votre page. Veuillez consulter la documentation MDN sur CSP pour en savoir plus.

remarque

Les directives ci-dessus sont pour les partenaires hébergeant des placements Rokt sur leurs propres pages. Si vous êtes un annonceur intégrant le SDK Web Rokt Ads, ou si votre page est présentée à l'intérieur d'un placement Rokt sur un site partenaire, consultez plutôt la Configuration de la Content Security Policy.

Intégrité des sous-ressources (SRI)

remarque

Rokt ne prend pas en charge les intégrations SRI pour le Web SDK.

L'intégrité des sous-ressources (SRI) est une fonctionnalité de sécurité qui permet aux navigateurs de vérifier que les ressources récupérées (par exemple, à partir d'un réseau de distribution de contenu) sont livrées sans manipulation inattendue.

Pourquoi Rokt ne prend-il pas en charge les intégrations SRI pour le Web SDK ?

Avoir la dernière version de notre Web SDK est important, car nous cherchons continuellement à améliorer la sécurité, la performance et la compatibilité. Si un partenaire décide d'appliquer un SRI au script Rokt, il serait verrouillé à cette version spécifique de l'intégration. Nous devrions alors compter sur le partenaire pour mettre à jour manuellement vers la dernière version lorsque nous publions des mises à jour, ce qui peut être aussi fréquent qu'une fois toutes les deux semaines. Ne pas être à jour sur les versions signifie que l'intégration peut ne pas fonctionner comme prévu, déclenchant des alarmes et affectant des métriques internes telles que la performance et les temps d'arrêt.

Pour cette raison, des services comme Facebook, Stripe, PayPal, etc. ne prennent pas en charge les versions fixes ou les intégrations SRI.

Pour garantir que le code servi par Rokt arrive sans manipulation, nous employons de nombreuses couches de sécurité, du transfert réseau aux processus d'ingénierie internes. De manière générale, obtenir des fichiers de rokt.com via https est suffisant pour garantir une protection maximale car le protocole SSL garantit que les fichiers proviennent de nos services internes.

Pour garantir que les fichiers ne sont pas altérés au sein de notre réseau interne, Rokt maintient la conformité avec les normes pertinentes régissant la sécurité des services efficaces.

Nous sommes conformes à la norme ISO/IEC 27001, qui est la principale norme internationale pour la gestion de la sécurité de l'information. Nos pratiques organisationnelles garantissent que nos services internes ne sont pas ouverts aux attaques externes. Avec d'autres pratiques, l'accès au code source nécessite une authentification multi-facteurs (MFA) et les mises à jour sont soumises à des processus de révision et d'audit robustes avant d'être déployées.

Iframes sandboxés et politique de même origine

La solution de Rokt repose fortement sur l'utilisation d'iframes cross-origin. Nos iframes sont chargées depuis le point de terminaison apps.rokt.com et appliquent automatiquement la politique de même origine. Cela garantit efficacement que le code du partenaire ne peut pas interagir avec le contenu iframé de Rokt et vice versa, en d'autres termes, l'isolation entre les deux contextes est appliquée.

De plus, nous utilisons un attribut sandbox sur nos iframes. L'attribut sandbox limite fortement les fonctionnalités autorisées dans l'iframe. Rokt applique automatiquement les attributs sandbox car il doit maintenir une liste d'exceptions pour permettre à nos iframes de fonctionner correctement. Dans le cas de l'iframe d'un placement, la liste suivante d'exceptions est utilisée :

• allows-scripts garantit que le contenu iframé peut exécuter des fichiers JavaScript et garantit que Rokt peut fournir la fonctionnalité attendue par nos partenaires.
• allow-same-origin permet à l'iframe de conserver ses informations d'origine. Cela est utilisé pour atteindre une communication sécurisée via postMessage. Si elle n'est pas fournie, l'iframe est dépouillée de ses informations d'origine et Rokt ne peut pas utiliser le paramètre targetOrigin de postMessage pour garantir la communication uniquement entre les iframes sur notre domaine, car elles seraient dépouillées de ces informations.
• allow-popups permet au contenu iframé d'ouvrir des liens (par exemple, campagnes de trafic, termes et conditions) dans un nouvel onglet.
• allow-popups-to-escape-sandbox permet aux campagnes avec des liens vers d'autres sites de fonctionner correctement—sinon elles seraient restreintes aux mêmes règles de sandboxing que notre iframe.
• allow-forms permet à la ressource de soumettre des formulaires. Cela n'est pas requis pour la solution de Rokt, cependant, certains de nos annonceurs nécessitent la soumission de formulaires sur leurs pages.

Communication postMessage

La communication requise est effectuée en utilisant postMessage et un MessageChannel qui est une construction contenant une paire de ports. Cette communication se produit entre l'intégration Rokt hébergée sur la page du partenaire et l'iframe des placements Rokt.

La communication peut être considérée comme un tuyau avec deux extrémités (les deux ports). Nous limitons l'échange de ports via postMessages aux domaines que nous contrôlons. Cela garantit que seuls les iframes Rokt peuvent recevoir des messages du Launcher et entre eux. Après que le code de placement ait reçu le port apparié, toute la communication est effectuée via ce canal établi.

Confidentialité

Support pour la suppression de données

Rokt offre à nos partenaires la possibilité de envoyer des demandes de suppression de données à Rokt afin de respecter les demandes et préférences de leurs clients.

Support pour la désactivation des cookies

Les partenaires peuvent configurer leur implémentation Rokt pour s'aligner sur les préférences de consentement des utilisateurs et offrir différentes expériences clients en conséquence.

Technologies de suivi fonctionnel : Celles-ci permettent des expériences personnalisées et optimisées sur votre site, y compris une fonctionnalité améliorée lors du paiement (comme la présentation d'Upsells).

Technologies de suivi de ciblage : Celles-ci étendent la personnalisation en utilisant les comportements des clients collectés avec le consentement approprié sur d'autres sites.

Les partenaires sont encouragés à respecter le niveau de restriction indiqué par le client et à configurer leur implémentation en conséquence.

Pour soutenir les partenaires utilisant des plateformes de gestion du consentement (CMP), des bannières de cookies et des outils similaires, le SDK Web de Rokt inclut deux indicateurs configurables que les partenaires peuvent définir pour empêcher l'utilisation d'identifiants de navigateur ou de technologies de suivi pour une session donnée.

Ces indicateurs s'alignent sur la terminologie utilisée par les CMP courants pour faciliter l'implémentation.

Implémentation

Les partenaires peuvent inclure les indicateurs suivants en tant que valeurs booléennes dans window.mParticle.config.launcherOptions lors de l'initialisation du SDK.

noFunctional

• Lorsqu'il est défini sur true, le partenaire demande au SDK de désactiver l'utilisation des identifiants de l'appareil/navigateur pour cette session. Aucun cookie ou stockage de navigateur n'est écrit.
• Si aucun identifiant de suivi de navigateur n'est déjà présent, le SDK n'écrira aucun identifiant de navigateur applicable dans le navigateur du client ou ne connectera d'identifiants aux systèmes Rokt pour cette session.
• Si un ou plusieurs identifiants de suivi sont déjà présents, le SDK ignorera ces identifiants et ne les associera pas aux systèmes Rokt pendant cette session. Les identifiants existants ne sont pas supprimés du navigateur, mais ils ne sont pas utilisés.
• L'identité de l'utilisateur n'est pas établie automatiquement. Pour activer la reconnaissance de l'utilisateur pour une session, les partenaires doivent explicitement transmettre des identifiants d'utilisateur (tels que l'email ou l'ID client) lors de l'initialisation ou appeler mParticle.Identity.identify() au moment approprié dans leur flux. Si aucun identifiant n'est fourni, la session est traitée comme anonyme pour cette visite. Notez que pour les applications monopage, cela ne devrait être fait qu'une seule fois, mais pour les applications multipages (ou chaque fois que le SDK est rechargé), vous devrez ré-identifier.

noTargeting

• Lorsqu'il est défini sur true, le partenaire demande au SDK de désactiver l'utilisation des identifiants de navigateur pour le ciblage et la personnalisation inter-sites.
• Les identifiants fonctionnels restent actifs à moins que noFunctional ne soit également défini sur true.
• Les deux indicateurs peuvent être utilisés indépendamment ou ensemble pour un contrôle de consentement granulaire.

remarque

Ces indicateurs s'appliquent uniquement aux identifiants basés sur le navigateur. D'autres identifiants—tels que les adresses email ou les numéros de téléphone—peuvent encore être fournis à la discrétion du partenaire et continueront d'être utilisés conformément à la configuration du partenaire.

Si le partenaire définit noFunctional ou noTargeting sur false, omet les indicateurs, ou utilise toute autre valeur, les identifiants de navigateur seront utilisés comme configuré.

Les partenaires ne devraient définir ces indicateurs sur true que lorsqu'un client a choisi de ne pas être suivi via une plateforme de gestion du consentement (CMP) ou un autre mécanisme de désactivation mis en œuvre par le partenaire.

Exemple d'implémentation

// Include this as part of the initialization script
window.mParticle.config.launcherOptions = {
  noFunctional: true,
  noTargeting: true,
};