Aller au contenu principal

Sécurité du Web SDK

Rokt s'engage à garantir que nos intégrations du Web SDK soient sécurisées, et nous nous efforçons de construire la sécurité dans nos produits dès le départ. Nous prenons également toutes les précautions pour garantir que les données des clients soient gérées avec les contrôles les plus stricts. C'est une démarche continue, 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 accessibles à Rokt
  • Aucun code malveillant ne doit être exécuté par accident ou intentionnellement sur la page du partenaire
  • Aucun code malveillant ne doit pouvoir accéder de manière arbitraire aux informations privées des clients incluses sur la page d'accueil

Approche​

Rokt déplace la grande majorité des fonctionnalités dans des iframes d'origine croisée sandboxées pour maintenir une surface minimale sur la page parent. La page parent 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 parent. Cela permet une intégration plus facile mais nécessite un certain degré de confiance dans le code Rokt exécuté sur la page parent.

Pour instaurer 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 CSP (Content Security Policy) plus stricts, à savoir interdire "unsafe-eval" et "unsafe-inline"
  • Contenus des iframes sandboxés avec passage de messages contrôlé par 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 garder les modifications apportées aux paramètres CSP du partenaire à un minimum. 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 de script est nécessaire pour charger le lanceur dans la page du partenaire. Dans le cas de partenaires hébergeant eux-mêmes le fichier, cette modification n'est pas nécessaire. La source de 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 adverse 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 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 ?​

Il est important d'avoir la dernière version de notre Web SDK, 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 verrouillé sur cette version spécifique de l'intégration. Nous devrions alors compter sur le partenaire pour mettre à jour manuellement la dernière version lors de nos mises à jour, qui peuvent être aussi fréquentes qu'une fois toutes les deux semaines. Rester en arrière sur les versions signifie que l'intégration peut ne pas fonctionner comme prévu, déclenchant des alarmes et affectant les indicateurs internes tels que les performances et le 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 fourni par Rokt arrive sans manipulation, nous employons de nombreuses couches de sécurité, de la transmission du réseau aux processus d'ingénierie internes. En général, obtenir des fichiers à partir 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 maintient sa conformité avec les normes pertinentes régissant la sécurité efficace des services.

Nous sommes conformes à l'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 à 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 en bac à sable et politique de la même origine​

La solution de Rokt repose fortement sur l'utilisation d'iframes de provenance croisée. Nos iframes sont chargées depuis le point de terminaison apps.rokt.com et appliquent automatiquement la politique de la même origine. Cela garantit effectivement que le code du partenaire ne peut pas interagir avec le contenu encadré 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 des attributs de sandboxing car il est nécessaire de 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 encadré peut exécuter des fichiers JavaScript et assure 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 de notre domaine, car elles seraient dépouillées de cette information.
  • allow-popups permet que le contenu encadré puisse 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 limitées aux mêmes règles de sandboxing que notre iframe.
  • allow-forms permet à la ressource de soumettre des formulaires. Ceci n'est pas requis pour la solution de Rokt, cependant, certains de nos annonceurs nécessitent la soumission de formulaires sur leurs pages.

postMessage communication​

La communication requise est effectuée en utilisant postMessage et un MessageChannel, qui est une construction contenant une paire de ports. Cette communication se déroule 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 des iframes Rokt peuvent recevoir des messages du Launcher et entre eux. Après que le code de placement ait reçu le port jumelé, toute la communication se fait via ce canal établi.

Confidentialité​

Rokt offre des options que vous pouvez inclure dans votre implémentation pour permettre différentes expériences client, et vos clients peuvent décider de leurs préférences en matière 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 d'offrir les expériences client les plus pertinentes et optimales sur votre propre site, avec une personnalisation améliorée. Elles contribuent également à alimenter une fonctionnalité avancée au sein du processus de paiement (par exemple, vente de produits supplémentaires).

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

Pour garantir que Rokt répond adéquatement à vos objectifs, nous recommandons de limiter uniquement autant que le client l'indique pour bloquer.

Comme de nombreux partenaires adoptent des plateformes de gestion du consentement (CMP), des “Bannières de Cookies", ou d'autres outils pour permettre aux clients de refuser le suivi par navigateur, nous avons implémenté un indicateur (noFunctional) dans notre SDK Web qui permet à nos partenaires d'indiquer à Rokt d'arrêter d'utiliser des identifiants de navigateur de certaines façons pour une session particulière.

Pour rendre cela facile à implémenter, Rokt a utilisé la même terminologie que les CMP courants.

Implémentation​

Le drapeau, noFunctional, est une valeur booléenne qui peut être incluse dans l'appel Rokt.createLauncher.

  • Si Rokt reçoit ce drapeau comme : true, alors nous empêchons l'utilisation des identifiants de l'appareil pour activer les cas d'utilisation appropriés.
  • Si aucun identifiant de suivi de navigateur n'est présent sur le navigateur, nous n'écrivons aucun des identifiants 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 identifiants de suivi de navigateur sont présents, nous ignorons les identifiants existants qui ne sont pas autorisés et ne les intégrons pas avec les systèmes de Rokt pour les utiliser dans l'identification. Rokt ne supprime aucun identifiant déjà présent, nous les ignorons simplement pour la session.
remarque

Ces drapeaux n'affectent que les IDs 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, une autre valeur, ou si les drapeaux ne sont pas inclus dans la charge utile d'attributs, nous continuons à utiliser les IDs de navigateur normalement. Nous recommandons que le drapeau ne soit défini sur : true que si un client a choisi de refuser le suivi via un CMP ou un autre processus de désactivation.

Exemple d'implémentation​

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