Configuration de la Politique de Sécurité de Contenu

Une Politique de Sécurité de Contenu peut affecter votre intégration des publicités Rokt de deux manières indépendantes. La première est sortante : votre CSP détermine si vos pages peuvent charger le SDK Rokt et envoyer des événements à Rokt. La seconde est entrante : votre CSP détermine quels sites sont autorisés à charger votre page dans une iframe, ce qui s'applique lorsque votre offre fonctionne comme une expérience intégrée sur un site partenaire. Les deux utilisent des directives différentes, sont souvent gérées par des équipes différentes, et sont configurées indépendamment. Autoriser l'une n'autorise pas l'autre.

Direction	Ce qu'elle contrôle	Directive CSP	Quand vous en avez besoin
Sortante	Si votre page peut charger le SDK Rokt et envoyer des événements à Rokt	script-src, connect-src	Toute intégration Web SDK, si votre CSP restreint ces directives
Entrante	Si Rokt peut présenter votre page dans une iframe sur un site partenaire	frame-ancestors	Expériences intégrées, où le client complète votre entonnoir dans un emplacement Rokt

Cette page explique les deux.

remarque

Les modifications ci-dessous sont généralement effectuées par l'équipe qui gère la configuration de votre serveur web ou CDN plutôt que par l'équipe intégrant le SDK. Si vous avez besoin d'une assistance supplémentaire, veuillez contacter votre gestionnaire de compte Rokt.

remarque

Cette page est destinée aux annonceurs. Si vous êtes un partenaire hébergeant des emplacements Rokt sur votre propre site, consultez Sécurité Web SDK pour les directives qui s'appliquent à votre page.

Autoriser le chargement et l'envoi de données du SDK Rokt

Si votre CSP définit script-src, le navigateur refuse de charger le script SDK Rokt à moins que les domaines de Rokt ne soient sur la liste. S'il définit connect-src (ou un default-src sur lequel connect-src se replie), le SDK peut se charger mais ses appels d'événements et d'identité sont bloqués. Dans les deux cas, la console du navigateur rapporte ce qui s'est passé, avec des erreurs Refused to load ou Refused to connect qui nomment la directive responsable.

Pour résoudre cela, ajoutez les domaines Rokt aux directives que vous définissez déjà :

script-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;
connect-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;

apps.rokt-api.com est le domaine principal à partir duquel le SDK se charge et avec lequel il communique. apps.roktecommerce.com est le secours qu'il essaie lorsque le principal est inaccessible. Incluez les deux, même si vous verrez rarement le secours utilisé.

remarque

Modifiez uniquement les directives que votre politique définit déjà. Si votre CSP n'a pas de script-src, connect-src, ou default-src, rien n'est bloqué et il n'y a rien à changer ici.

Si vous utilisez un domaine de première partie

Si vous redirigez le SDK via votre propre sous-domaine en utilisant la configuration de domaine de première partie, le SDK se charge et envoie des événements à ce sous-domaine à la place. Ajoutez votre sous-domaine personnalisé à script-src et connect-src, et conservez également les domaines Rokt listés, car le SDK les utilise par défaut si votre sous-domaine cesse de répondre.

Si votre CSP ne peut pas autoriser les scripts tiers

Certaines entreprises, notamment dans les secteurs réglementés, utilisent un CSP qui bloque entièrement le JavaScript tiers mais autorise toujours les requêtes d'images. Si cela vous concerne, le Service Pixel est conçu pour cette situation.

Autoriser Rokt à intégrer votre page

Qu'est-ce qu'une expérience intégrée

Avec une expérience intégrée, votre page d'inscription, de candidature ou d'ouverture de compte est présentée directement à l'intérieur d'un emplacement Rokt sur un site partenaire, généralement à un moment de forte intention comme la page de paiement ou de confirmation de commande. Au lieu de cliquer sur votre offre et d'être redirigé vers votre site, le client complète votre processus existant directement sur place, sans quitter la page du partenaire.

Mécaniquement, l'URL de votre page est configurée dans la plateforme Rokt, et l'emplacement la rend dans un iframe cross-origin sandboxé à l'intérieur du conteneur d'emplacement sur la page du partenaire. Votre page conserve son origine propre et fonctionne sans changement. Vous gardez le contrôle total sur le formulaire, les flux ramifiés et les états de décision, exactement comme dans votre flux de redirection. Le sandbox impose une isolation dans les deux sens : la page du partenaire ne peut pas accéder à votre contenu, et votre contenu ne peut pas accéder au leur.

Votre page doit s'afficher de manière réactive dans les dimensions du conteneur d'emplacement :

• Bureau : largeur min(1024px, calc(100% - 128px)), hauteur min(900px, calc(100% - 128px))
• Mobile (largeur d'écran de 768px et moins) : largeur 99%, hauteur 90%, ancrée en bas de la fenêtre d'affichage

Le changement de CSP décrit dans cette section est l'un des quatre éléments qui font fonctionner une expérience intégrée :

#	Exigence	Résumé
1	URL rendue dans un iframe	Votre page se charge dans un iframe cross-origin et s'affiche de manière réactive dans les dimensions du conteneur ci-dessus.
2	CSP frame-ancestors	Votre page permet aux origines Rokt et partenaires de l'encadrer. C'est le sujet de cette section.
3	SDK Web Rokt	Votre page exécute l'intégration standard du SDK Web. Les vues de page et les événements de conversion que vous enregistrez déjà fournissent à l'emplacement tout ce dont il a besoin pour suivre les progrès et les états de décision, y compris la réalisation instantanée des récompenses à l'approbation lorsqu'une incitation est activée. Aucun code d'intégration supplémentaire n'est requis.
4	Suivi des conversions	Les conversions en temps réel sont suivies via l'événement de conversion du SDK Web. Les décisions différées sont signalées via votre intégration existante de boucle fermée, telle que l'API d'événements.

Votre gestionnaire de compte Rokt vous fournira la spécification complète de l'intégration pour le reste, ainsi que la liste complète et actuelle des origines pour votre directive frame-ancestors, et maintiendra cette liste à jour à mesure que des sites partenaires sont ajoutés.

Comment les navigateurs contrôlent l'encadrement

Lorsqu'une page charge une autre à l'intérieur d'une iframe, le navigateur vérifie les en-têtes de réponse de la page encadrée pour décider si l'encadrement est autorisé. Deux en-têtes peuvent porter cette autorisation :

• Content-Security-Policy: frame-ancestors ... est le mécanisme moderne. Il prend une liste d'origines autorisées à encadrer la page, ce qui permet d'autoriser des partenaires spécifiques tout en continuant à bloquer tous les autres. C'est ce que les intégrations Rokt utilisent.
• X-Frame-Options est le mécanisme hérité. Il ne prend en charge que des valeurs tout ou rien (DENY, SAMEORIGIN), il ne peut donc pas autoriser un partenaire spécifique comme Rokt. Si votre page envoie cet en-tête, il doit être remplacé par une directive frame-ancestors avant qu'une expérience intégrée puisse être rendue.

Si votre page n'envoie aucun des deux en-têtes, tout site peut l'encadrer aujourd'hui, et vous n'avez rien à changer pour lancer.

remarque

frame-ancestors n'hérite pas de default-src. Si votre CSP définit default-src mais pas frame-ancestors, l'encadrement est sans restriction. Ajouter frame-ancestors est un ajout à votre politique existante, pas un changement de toute directive que vous avez déjà.

Pourquoi chaque origine dans la chaîne est importante

Votre page ne se trouve pas directement à l'intérieur de la page du partenaire. Elle se trouve à l'intérieur du placement Rokt, qui se trouve à l'intérieur de la page du partenaire, et le navigateur vérifie votre liste frame-ancestors contre chaque origine dans cette chaîne, pas seulement le parent immédiat. Si une origine dans la chaîne manque dans la liste, le navigateur refuse de rendre votre page.

En pratique, la liste comporte trois groupes d'entrées :

1. Votre propre origine. Incluez 'self' et votre domaine d'inscription, par exemple https://*.yourdomain.com. Votre page en a besoin même sans une intégration Rokt.
2. Domaines Rokt. Ceux-ci sont stables et identiques pour chaque intégration (voir ci-dessous).
3. Sites partenaires où votre offre est diffusée. Ce sont les domaines des éditeurs qui hébergent le placement. Rokt fournit cette liste et la maintient à jour pour vous.

Domaines Rokt

La forme la plus simple utilise des jokers :

https://*.rokt.com
https://*.rokt-api.com
https://roktdemo.com

Assurez-vous que https://*.rokt-api.com est inclus. Il est utilisé par le SDK Rokt actuel, et les politiques écrites selon des directives antérieures l'omettent parfois. Sans lui, le dernier SDK est bloqué.

Si votre équipe de sécurité n'autorise pas les jokers

Certaines équipes préfèrent ne pas autoriser les sous-domaines jokers. Si cela s'applique à vous, supprimez les entrées jokers et utilisez plutôt les domaines Rokt explicites :

https://wsdk.rokt.com
https://apps.rokt.com
https://apps.rokt-api.com
https://playground.rokt.com
https://apps.stage.rokt.com
https://apps.stage.rokt-api.com
https://playground.stage.rokt.com
https://apps-demo.rokt.com
https://roktdemo.com

Les entrées partenaires sont toujours nécessaires, et votre gestionnaire de compte peut également vous les fournir sous une forme explicite, non-joker.

Domaines partenaires

Les domaines éditeurs qui hébergent votre offre sont spécifiques à votre campagne et changent au fur et à mesure que Rokt ajoute des partenaires, c'est pourquoi nous ne les publions pas ici. Votre gestionnaire de compte vous enverra la valeur complète de frame-ancestors, prête à être déployée, ainsi que les entrées mises à jour chaque fois que la liste des partenaires change.

Pour chaque partenaire, vous verrez généralement à la fois le domaine nu et une forme générique. Les deux sont inclus pour que la politique soit valable que le site donné serve ou non du trafic depuis www. Vous pouvez conserver les deux, ou demander à votre gestionnaire de compte de confirmer la forme exacte utilisée par chaque partenaire et réduire la liste.

Vérification de votre politique actuelle

Avant de modifier quoi que ce soit, regardez ce que votre page envoie réellement aujourd'hui. Vérifiez la véritable page de tunnel (l'URL d'inscription ou de candidature elle-même), pas la page d'accueil, car les politiques diffèrent souvent selon le chemin.

1. Ouvrez votre page de tunnel dans un navigateur.
2. Ouvrez le panneau des outils de développement et sélectionnez l'onglet Réseau.
3. Rechargez la page et sélectionnez la première requête (type document).
4. Sous En-têtes de réponse, recherchez x-frame-options et content-security-policy.

Pour la direction SDK, vérifiez si script-src, connect-src ou default-src apparaissent dans la politique et si les domaines Rokt y sont inclus. L'onglet Console facilite cela : si le SDK est bloqué, vous verrez des erreurs Refused to load ou Refused to connect indiquant quelle directive est responsable.

Pour le cadrage, ce que vous trouvez correspond directement à ce qu'il faut faire ensuite :

Ce que votre page envoie	Ce que cela signifie	Que faire
Pas de X-Frame-Options, pas de frame-ancestors	Le cadrage est sans restriction	Rien n'est requis pour le lancement. Vous pouvez éventuellement ajouter frame-ancestors avec les entrées Rokt et partenaires pour un contrôle plus strict.
frame-ancestors avec une liste d'autorisation	Seules les origines listées peuvent cadrer votre page	Ajoutez les entrées Rokt et partenaires à votre liste existante.
frame-ancestors 'none'	Tout cadrage est bloqué	Remplacez 'none' par la liste d'autorisation des origines de votre gestionnaire de compte.
X-Frame-Options: SAMEORIGIN ou DENY	En-tête hérité, tout ou rien	Supprimez l'en-tête et utilisez une liste d'autorisation frame-ancestors à la place. Tous les navigateurs modernes prennent en charge frame-ancestors, et cela prend le pas lorsque les deux sont présents.

remarque

Les outils en ligne de commande tels que curl renvoient parfois un défi de protection contre les bots plutôt que les véritables en-têtes de votre application, car la couche de protection répond avant que votre application ne le fasse. La méthode du navigateur ci-dessus reflète toujours ce qu'un utilisateur réel reçoit.

Déploiement du changement

L'endroit où l'en-tête est défini dépend de votre pile technologique. Cela peut être votre configuration CDN ou edge (CloudFront, Cloudflare, Akamai), votre serveur web (nginx, Apache) ou le framework de l'application lui-même. Où que ce soit, ajoutez uniquement les entrées Rokt aux directives discutées sur cette page et laissez tout le reste de votre politique inchangé.

Si votre CSP est défini dans une balise <meta http-equiv>, notez que frame-ancestors y est silencieusement ignoré. Les navigateurs ne le prennent en compte que comme un en-tête de réponse HTTP.

Liste de vérification rapide

Chargement du SDK et collecte de données (toutes les intégrations Web SDK) :

• Si votre CSP définit script-src, les domaines Rokt sont présents
• Si votre CSP définit connect-src ou default-src, les domaines Rokt sont présents
• Si vous utilisez un domaine de première partie, votre sous-domaine personnalisé est présent dans les deux
• Pas d'erreurs Refused to load ou Refused to connect dans la console du navigateur sur vos pages de tunnel

Intégration (expériences intégrées uniquement) :

• 'self' et votre propre domaine d'inscription sont présents dans frame-ancestors
• https://*.rokt.com est présent (ou les domaines Rokt explicites listés ci-dessus)
• https://*.rokt-api.com est présent (requis par le SDK actuel)
• https://roktdemo.com est présent
• Les domaines partenaires fournis par votre gestionnaire de compte sont présents
• Tout en-tête X-Frame-Options a été supprimé des pages de tunnel
• Le changement est vérifié sur l'URL du tunnel elle-même, pas seulement sur la page d'accueil