Aller au contenu principal

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 les contrôles les plus stricts. Il s'agit d'un effort continu, et nous visons à améliorer de manière itérative nos processus, nos contrôles et nos technologies pour une plus grande sécurité.

Objectifs​

Les objectifs de sécurité de Rokt comprennent :

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

Approche {#approche}

Rokt délègue la grande majorité des fonctionnalités dans des iframes sandboxées et cross-origin afin de maintenir une surface minimale sur la page parente. La page parente doit inclure le lanceur d'intégration Rokt, qui a un ensemble très minimal de dépendances. Ces dépendances gèrent ensemble l'orchestration des ressources 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 :

  • Utilisation de versions modernes et à jour des dépendances de bibliothèques et de frameworks
  • Autorisation des sources autorisées des scripts Rokt
  • Prise en charge de paramètres de politique de sécurité du contenu (CSP) plus stricts, notamment en interdisant "unsafe-eval" et "unsafe-inline"
  • Contenu sandboxé des iframes avec passage de messages contrôlé par l'origine à l'aide de 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 l'utilisation de scripts intégrés et de l'opérateur 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 limiter au minimum les modifications des paramètres CSP du partenaire. Les directives CSP requises consistent à ajouter les 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 des partenaires hébergeant le fichier eux-mêmes, cette modification 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 si vous n'utilisez pas les directives script-src ou frame-src, ajouter uniquement ces modifications 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 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 diffusion 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é, les performances et la compatibilité. Si un partenaire décide d'appliquer un SRI au script Rokt, il serait alors lié à cette version spécifique de l'intégration. Nous devrions ensuite compter sur le partenaire pour mettre à jour manuellement vers la dernière version lorsque nous publions des mises à jour, ce qui peut se produire aussi fréquemment 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 les performances et les temps d'arrêt.

Pour cette raison, des services tels que Facebook, Stripe, PayPal, etc. ne prennent pas en charge les intégrations de version fixe ou SRI.

Pour garantir que le code fourni par Rokt arrive sans manipulation, nous utilisons de nombreuses couches de sécurité, de la transmission réseau aux processus d'ingénierie internes. En général, obtenir des fichiers depuis rokt.com via https est suffisant pour assurer 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 depuis notre réseau interne, Rokt respecte les normes pertinentes régissant la sécurité efficace des services.

Nous sommes conformes à la norme internationale ISO/IEC 27001, qui est la norme internationale de référence 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. En plus d'autres pratiques, l'accès au code source nécessite une authentification multi-facteurs (MFA) et les mises à jour sont soumises à des processus d'examen et d'audit rigoureux avant d'être déployées.

Iframes sandboxés et politique de même origine​

La solution de Rokt repose largement sur l'utilisation d'iframes de différentes origines. Nos iframes sont chargés à partir de l'adresse 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 en iframe de Rokt et vice versa, en d'autres termes, une isolation entre les deux contextes est imposé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 d'un iframe de placement, la liste d'exceptions suivante est utilisée :

  • allows-scripts permet à du contenu en iframe d'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 assurer une communication sécurisée via postMessage. Si cette autorisation n'est pas fournie, 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 de notre domaine, car elles seraient dépouillées de ces informations.
  • allow-popups permet au contenu en iframe d'ouvrir des liens (par exemple, des campagnes de trafic, des conditions générales) 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 par postMessage​

La communication requise est effectuée à l'aide de postMessage et d'un MessageChannel qui est une construction contenant une paire de ports. Cette communication se fait entre l'intégration Rokt hébergée sur la page du partenaire et l'iframe des emplacements 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 des 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 reçoit le port apparié, toute la communication se fait via ce canal établi.

Confidentialité​

Rokt offre une optionnalité que vous pouvez inclure dans votre implémentation, ce qui vous permet de proposer différentes expériences client et à vos clients de choisir leurs préférences en matière de cookies.

Technologies de suivi fonctionnelles : vous permettent de fournir les expériences client les plus pertinentes et optimales sur votre propre site, avec une personnalisation améliorée. Elles contribuent également à alimenter les fonctionnalités avancées dans le processus de paiement (par exemple, la vente incitative).

Technologies de suivi ciblées : étendent notre personnalisation pour inclure les comportements consentis d'un client sur d'autres sites.

Pour vous assurer que Rokt répond adéquatement à vos objectifs, nous vous recommandons de restreindre uniquement ce que le client indique bloquer. Par exemple, si le client indique seulement qu'il n'accepte pas les cookies ciblés, nous vous recommandons de ne pas restreindre également les cookies fonctionnels.

Étant donné que de nombreux partenaires adoptent des plateformes de gestion du consentement (CMP), des "bannières de cookies" ou d'autres outils permettant aux clients de refuser le suivi du navigateur, nous avons mis en place deux indicateurs (noFunctional et noTargeting) dans notre SDK Web, qui permettent à nos partenaires de demander à Rokt de cesser d'utiliser les identifiants de navigateur de certaines manières pour une session particulière.

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

Implémentation​

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 avec la valeur : true, alors nous empêchons l'utilisation des identifiants de périphérique pour activer les cas d'utilisation appropriés.
  • Si aucun identifiant de suivi du navigateur n'est présent sur le navigateur, nous n'écrivons aucun des identifiants de navigateur applicables dans le navigateur du client et n'intégrons aucune valeur aux systèmes de Rokt pour cette session.
  • Si un ou plusieurs identifiants de suivi du navigateur sont présents, nous ignorons les identifiants 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 pas les identifiants déjà présents, nous les ignorons simplement pour la session.
remarque

Ces indicateurs n'affectent que les identifiants 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 avec la valeur : false, toute autre valeur, ou si les indicateurs ne sont pas inclus dans la charge d'attributs, nous continuons à utiliser les identifiants de navigateur normalement. Nous recommandons que l'indicateur soit défini sur : true uniquement 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 a un impact sur notre capacité à mesurer les performances des offres affichées lors d'une transaction particulière. Si ce drapeau est trop utilisé 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 vivement d'utiliser ce drapeau uniquement si le client a expressément choisi de ne pas participer.

Exemple d'implémentation​

await window.Rokt.createLauncher({
  accountId: "account_id",
  noFunctional: false,
  noTargeting: true,
});
Cet article vous a-t-il été utile ?