Last updated 5 déc. 2024

Sécurité du Web SDK

Rokt s'engage à garantir que nos intégrations Web SDK 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 le plus strict contrôle. Il s'agit d'un effort continu et nous visons à améliorer de manière itérative nos processus, contrôles et technologies pour une sécurité accrue.

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 grande majorité des fonctionnalités dans des iframes isolées et cross-origin pour maintenir une surface d'attaque minimale sur la page parente. La page parente doit inclure le Rokt Integration Launcher, qui a un ensemble très minimal de dépendances. Ces dépendances gèrent ensemble l'orchestration des actifs Rokt tout en fournissant une interface nette 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 dépendances de bibliothèque et de framework
• Liste blanche des sources autorisées pour les scripts Rokt
• Support pour des paramètres de Content Security Policy (CSP) plus stricts, notamment l'interdiction de "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é

Politique de sécurité du contenu (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 vise également à charger le moins de fonctionnalités possible sur la page partenaire. Cette approche nous permet de minimiser les changements dans les 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;
frame-src https://apps.rokt.com;

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

remarque

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

Intégrité des sous-ressources (SRI)

remarque

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

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, depuis 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 SDK Web ?

Avoir la dernière version de notre SDK Web 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 resterait alors lié à 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. Prendre du retard 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 le temps d'arrêt.

Pour cette raison, des services comme Facebook, Stripe, PayPal, etc. ne prennent pas en charge les intégrations de version fixe ou 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 suffit à garantir une protection maximale, car le protocole SSL garantit que les fichiers proviennent de nos services internes.

Pour s'assurer que les fichiers ne sont pas altérés depuis notre réseau interne, Rokt respecte les normes pertinentes régissant la sécurité efficace des services.

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 exposés à des attaques externes. Avec d'autres pratiques, l'accès au code source nécessite une authentification à plusieurs facteurs (MFA) et les mises à jour sont soumises à des processus de révision et d'audit rigoureux 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és depuis le point de terminaison apps.rokt.com et appliquent automatiquement la politique de même origine. Cela garantit effectivement que le code du partenaire ne peut pas interagir avec le contenu des iframes de Rokt et vice versa, en d'autres termes, l'isolement entre les deux contextes est imposé.

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

• allows-scripts garantit que le contenu de l'iframe peut exécuter des fichiers JavaScript et garantit que Rokt peut fournir la fonctionnalité que nos partenaires attendent.
• allow-same-origin permet à l'iframe de conserver ses informations d'origine. Cela est utilisé pour assurer une communication sécurisée via postMessage. S'il n'est pas fourni, l'iframe est dépouillé de ses informations d'origine et Rokt ne peut pas utiliser le paramètre targetOrigin de postMessage pour garantir une communication uniquement entre les iframes sur notre domaine, car elles seraient dépouillées de cette information.
• allow-popups permet au contenu de l'iframe 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 soumises aux mêmes règles de sandboxing que notre iframe.
• allow-forms permet à la ressource de soumettre des formulaires. Cela n'est pas nécessaire pour la solution de Rokt, cependant, certains de nos annonceurs exigent des soumissions de formulaires sur leurs pages.

communication postMessage

La communication requise est effectuée à l'aide de postMessage et d'un MessageChannel, qui est une structure 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 seules les iframes Rokt peuvent recevoir des messages du Launcher et entre elles. Une fois que le code de placement reçoit le port apparié, toute la communication est effectuée via ce canal établi.

Confidentialité

Support pour les exclusions de cookies

Rokt offre une option que vous pouvez inclure dans votre mise en œuvre, ce qui vous permet de fournir différentes expériences client et à vos clients de décider de différentes préférences en matière de cookies.

Support pour la suppression des données

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

Technologies de suivi fonctionnel : Vous permettent de fournir les expériences client les plus pertinentes et optimales sur votre propre site, avec une personnalisation améliorée. Elles aident également à alimenter des fonctionnalités avancées dans le processus de paiement (par exemple, vendre des Upsells).

Technologies de suivi de ciblage : Étend notre personnalisation pour inclure les comportements consentis d'un client sur d'autres sites.

Pour garantir que Rokt répond adéquatement à vos objectifs, nous recommandons de limiter seulement autant que le client indique à bloquer. Par exemple, si le client indique seulement qu'il n'accepte pas les cookies de ciblage, nous recommandons de ne pas restreindre les cookies fonctionnels également.

Comme beaucoup de nos partenaires adoptent des plateformes de gestion du consentement (CMP), des "bannières de cookies" ou d'autres outils permettant aux clients de se désinscrire du suivi dans le navigateur, nous avons mis en œuvre deux indicateurs (noFunctional et noTargeting) dans notre SDK Web qui permet à nos partenaires de diriger Rokt pour cesser d'utiliser des identifiants de navigateur de certaines manières pour une session particulière.

Pour faciliter cette mise en œuvre, Rokt a utilisé la même terminologie que les CMP courants.

Mise en œuvre

Les indicateurs, noFunctional et noTargeting, sont des valeurs booléennes qui peuvent être incluses dans l'appel Rokt.createLauncher.

• Si Rokt reçoit un ou les deux de ces indicateurs en tant que : true, nous empêchons l'utilisation des identifiants de périphérique pour activer les cas d'utilisation appropriés.
• S'il n'y a pas d'ID de suivi de navigateur présents sur le navigateur, nous n'écrivons aucun des ID de navigateur applicables dans le navigateur du client ni n'intégrons de valeurs avec les systèmes de Rokt pour cette session.
• Si un ou plusieurs ID de suivi de navigateur sont présents, nous ignorons les ID existants qui ne sont pas autorisés et ne les intégrons pas avec les systèmes de Rokt pour une utilisation dans l'identification. Rokt ne supprime aucun ID déjà présent, nous les ignorons simplement pour la session.

remarque

Ces indicateurs n'affectent que les ID de navigateur. D'autres identifiants tels que email ou numéro de téléphone peuvent encore être fournis à la discrétion du partenaire et sont utilisés normalement.

Si Rokt ne reçoit pas noFunctional ou noTargeting : false, toute autre valeur, ou si les indicateurs ne sont pas inclus dans la charge utile des attributs, nous continuons à utiliser les ID de navigateur normalement. Nous recommandons que l'indicateur soit uniquement réglé sur : true si un client s'est désabonné du suivi via un CMP ou un autre processus de désinscription.

Impacts

La technologie d'attribution de conversion de Rokt est prise en charge sur certains des identifiants bloqués par le drapeau noTargeting, donc l'ajout de ce drapeau a un impact sur notre capacité à mesurer les performances des offres présentées lors d'une transaction particulière. Si ce drapeau est utilisé de manière excessive par un partenaire (par exemple, appliqué à toutes les transactions), la performance mesurée de ce partenaire diminuera et le volume d'annonceurs ainsi que les prix des enchères peuvent en pâtir. Nous recommandons fortement d'utiliser ce drapeau uniquement si le client a spécifiquement choisi de se désinscrire.

Exemple d'implémentation

await window.Rokt.createLauncher({
  accountId: "rokt-account-id",
  noFunctional: false,
  noTargeting: true,
});