Last updated 27 sept. 2024

Sécurité du SDK Web

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 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 grande majorité des fonctionnalités dans des iframes cross-origin sandboxés 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 dépendances de bibliothèques et de frameworks
• Liste blanche des sources autorisées des scripts Rokt
• Prise en charge de paramètres de Content Security Policy (CSP) plus stricts, à savoir l'interdiction de "unsafe-eval" et "unsafe-inline"
• Contenu des iframes sandboxé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 s'efforce également de charger le moins de fonctionnalités possible sur la page du partenaire. Cette approche nous permet de minimiser les modifications des paramètres CSP du partenaire. Les directives CSP requises impliquent l'ajout des domaines suivants à la liste autorisée :

script-src https://apps.rokt.com;
frame-src https://apps.rokt.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, ajouter uniquement ces modifications peut avoir un effet négatif sur votre page. Veuillez suivre 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 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 Web SDK?

Avoir la dernière version de notre Web SDK est important, car nous cherchons continuellement à améliorer la sécurité, les performances et la compatibilité. Si un partenaire décidait 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 la dernière version lorsque nous publions des mises à jour, ce qui peut être aussi fréquent qu'une fois toutes les deux semaines. Être en 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 les performances 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é, de la transmission réseau aux processus d'ingénierie internes. En général, 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 rigoureux avant d'être déployées.

Iframes en bac à sable 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 effectivement 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 les fonctionnalités attendues par nos partenaires.
• allow-same-origin permet à l'iframe de conserver ses informations d'origine. Cela est utilisé pour obtenir une communication sécurisée via postMessage. Si cela n'est pas fourni, 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 une 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, des campagnes de trafic, des 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 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 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 seuls les iframes Rokt peuvent recevoir des messages du Launcher et entre eux. Après que le code de placement a reçu le port apparié, toute la communication est effectuée via ce canal établi.

Confidentialité

Prise en charge des désactivations de cookies

Rokt offre une option que vous pouvez inclure dans votre implémentation, ce qui vous permet de fournir différentes expériences client, et à vos clients de décider de différentes préférences de cookies.

Prise en charge de la suppression des 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.

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, la vente de 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 ne restreindre que ce que le client indique bloquer. Par exemple, si le client indique seulement qu'il n'accepte pas les cookies de ciblage, nous vous 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 du navigateur, nous avons mis en place deux indicateurs (noFunctional et noTargeting) dans notre SDK Web qui permettent à nos partenaires de demander à Rokt d'arrêter d'utiliser les identifiants de navigateur de certaines manières pour une session particulière.

Pour faciliter cette implémentation, 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 comme : true, alors nous empêchons l'utilisation des identifiants de l'appareil pour activer les cas d'utilisation appropriés.
• Si aucun ID de suivi de navigateur n'est présent sur le navigateur, nous n'écrivons aucun des ID de navigateur applicables sur le navigateur du client et n'intégrons aucune valeur 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 aux 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 toujours être fournis à la discrétion du partenaire et sont utilisés normalement.

Si Rokt reçoit 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 ne soit défini sur : true que si un client a choisi de ne pas être 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 affecte notre capacité à mesurer les performances des offres affichées lors d'une transaction particulière. Si ce drapeau est surutilisé par un partenaire (par exemple, appliqué à toutes les transactions), les performances mesurées de ce partenaire diminueront et le volume des annonceurs ainsi que les prix des enchères pourraient baisser en conséquence. Nous recommandons fortement d'utiliser ce drapeau uniquement si le client s'est spécifiquement désinscrit.

Exemple de mise en œuvre

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