Sécurité du SDK Web

Rokt s'engage à garantir que nos intégrations du SDK Web soient 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 soient 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 déplace la grande majorité des fonctionnalités dans des iframes cross-origin sandboxé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 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 :

• Versions modernes et à jour des bibliothèques et des dépendances de frameworks
• Liste blanche des sources autorisées des scripts Rokt
• Support pour des paramètres de Content Security Policy (CSP) plus stricts, notamment en interdisant "unsafe-eval" et "unsafe-inline"
• Contenu des iframes sandboxées 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 limiter au maximum 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;
frame-src https://apps.rokt.com;

La source des scripts 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 des cadres 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égatif 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, à 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 SDK Web ?

Avoir la dernière version de notre SDK Web 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 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 lors de nos mises à jour, qui peuvent être aussi fréquentes qu'une fois toutes les deux semaines. Ne pas suivre les versions signifie que l'intégration peut ne pas fonctionner comme prévu, déclenchant des alertes et affectant des indicateurs internes tels 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é, depuis le transfert réseau jusqu'aux processus d'ingénierie internes. De manière générale, obtenir des fichiers de 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 au sein de notre réseau interne, Rokt maintient la conformité avec les normes pertinentes régissant la sécurité efficace des services.

Nous sommes conformes à la norme 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 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 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 emplacement, la liste suivante d'exceptions est utilisée :

• allows-scripts garantit que le contenu iframé peut exécuter des fichiers JavaScript et assure 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 réaliser une communication sécurisée via postMessage. S'il 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 cette information.
• 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 soumises 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 structure contenant une paire de ports. Cette communication a lieu 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 jumelé, 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 le refus 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 client en conséquence.

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

Technologies de suivi ciblé : 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 (CMPs), des bannières de cookies et des outils similaires, le Rokt Web SDK inclut un indicateur configurable—noFunctional—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.

Cet indicateur s'aligne avec la terminologie utilisée par les CMPs courants pour faciliter l'implémentation.

Implémentation

Les partenaires peuvent inclure le drapeau noFunctional comme valeur booléenne dans l'appel Rokt.createLauncher.

• 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.
• 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.

remarque

Ces drapeaux s'appliquent uniquement aux identifiants basés sur le navigateur. D'autres identifiants—tels que les adresses e-mail ou les numéros de téléphone—peuvent toujours ê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 drapeaux, ou utilise toute autre valeur, les identifiants de navigateur seront utilisés comme configuré.

Les partenaires ne devraient définir ces drapeaux 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ésinscription mis en œuvre par le partenaire.

Exemple d'implémentation

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