Skip to main content

Web SDK security

Rokt is committed to ensuring that our Web SDK integrations are secure, and we strive to build security into our products from the ground up. We also take every precaution to ensure that client data is managed with the tightest of controls. This is a continuous endeavor, and we aim to iteratively improve our processes, controls, and technologies for greater security.

Objectives​

Rokt's security objectives include:

  • Partners should have control over what data is available to Rokt
  • No malicious code is accidentally or intentionally run on the partner page
  • No malicious code is able to arbitrarily access private customer information included on the host page

Approach​

Rokt pushes the vast majority functionality into sandboxed cross-origin iframes to maintain a minimal surface area on the parent page. The parent page must include the Rokt Integration Launcher, which has a very minimal set of dependencies. These dependencies together manage the orchestration of the Rokt assets while providing a neat and minimal interface to the parent page. This allows for an easier integration but requires a degree of trust in the Rokt code that is running on the parent page.

In order to build this trust Rokt employs the following techniques:

  • Modern and up-to-date versions of library and framework dependencies
  • Whitelisting of authorized sources of Rokt scripts
  • Support for tighter Content Security Policy (CSP) settings, namely disallowing "unsafe-eval" and "unsafe-inline"
  • Sandboxed iframe contents with origin-controlled message passing using postMessage

Security features​

Content Security Policy (CSP)​

Rokt’s Web SDK supports recommended CSP settings that prevent inline scripts and the use of eval within scripts. It also strives to load as little functionality as possible on the partner page. This approach allows us to keep changes to partner’s CSP settings to a minimum. The required CSP directives involve adding the following domains to the allowed list:

script-src https://apps.rokt.com;
frame-src https://apps.rokt.com;

Script source is required to load the launcher into the partner page. In the case of partners hosting the file themselves, this change is not required. Frame source allows us to load Rokt’s isolated iframes.

note

If you are not using CSP or not using script-src or frame-src directives, adding only those changes may have an adverse effect on your page. Please follow MDN documentation on CSP to learn more.

Subresource Integrity (SRI)​

note

Rokt does not support SRI integrations for Web SDK.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources being fetched (for example, from a content delivery network) are delivered without unexpected manipulation.

Why doesn't Rokt support SRI integrations for Web SDK?​

Having the latest version of our Web SDK is important, since we continuously look to improve security, performance, and compatibility. Should a partner decide to apply an SRI to the Rokt script, they would become locked to that specific version of the integration. We would then rely on the partner to manually update to the latest version when we release updates, which can be as frequent as once every two weeks. Falling behind on versions means the integration may not function as intended, triggering alarms and affecting internal metrics such as performance and downtime.

For this reason, services like Facebook, Stripe, PayPal, etc. do not support fixed version or SRI integrations.

To guarantee the code served by Rokt arrives without manipulation, we employ many layers of security, from network transferral to internal engineering processes. Broadly, obtaining files from rokt.com over https is enough to ensure maximum protection as the SSL protocol guarantees that the files originate from our internal services.

To ensure the files are not tampered with from within our internal network, Rokt maintains compliance with the relevant standards governing effective service security.

We are ISO/IEC 27001 compliant, which is the leading international standard for management of information security. Our organizational practices ensure that our internal services are not open to external attacks. Along with other practices, access to source code requires multi-factor authentication (MFA) and updates are subject to robust review and audit processes before being deployed.

Sandboxed iframes and same origin policy​

Rokt's solution relies heavily on the use of cross-origin iframes. Our iframes are loaded from the endpoint apps.rokt.com and enforce same-origin policy automatically. This effectively ensures that the partner's code cannot interact with Rokt iframed content and vice versa, in other words, isolation between the two contexts is enforced.

Additionally, we use a sandbox attribute on our iframes. The sandbox attribute heavily limits allowed functionalities in the iframe. Rokt applies sandbox attributes automatically as it needs to maintain a list of exceptions to allow our iframes to function correctly. In the case of a placement's iframe, the following list of exceptions is used:

  • allows-scripts ensures iframed content can run JavaScript files and ensures Rokt can provide the functionality that our partners expect.
  • allow-same-origin allows the iframe to maintain its origin information. This is used to achieve secure communication through postMessage. If it is not provided, the iframe is stripped of its origin information and Rokt can't use the targetOrigin parameter of postMessage to ensure communication only between iframes on our domain, since they would be stripped of that information.
  • allow-popups allows iframed content to open links (e.g., traffic campaigns, terms and conditions) in a new tab.
  • allow-popups-to-escape-sandbox allows campaigns with links to other sites to function properly—otherwise they would be restricted to the same sandboxing rules as our iframe.
  • allow-forms allows the resource to submit forms. This is not required for Rokt’s solution, however, some of our advertisers require form submission on their pages.

postMessage communication​

The required communication is conducted using postMessage and a MessageChannel which is a construct containing a pair of ports. This communication occurs between the Rokt integration hosted on the partner's page and the Rokt placements iframe.

The communication can be thought of as a pipe with two ends (the two ports). We limit the exchange of ports through postMessages to domains we control. This ensures that only a Rokt iframes can receive messages from the Launcher and between each other. After the placement code receives the paired port, all communication is conducted over this established channel.

Privacy​

Rokt provides optionality you can include in your implementation which allows you to provide different customer experiences, and your customers to decide on different cookie preferences.

Functional Tracking Technologies: Allow you to provide the most relevant and optimal customer experiences on your own site, with enhanced personalization. They also help power advanced functionality within the checkout (e.g. selling Upsells).

Targeting Tracking Technologies: Extends our personalization to include consented behaviors for a customer on other sites.

To ensure that Rokt adequately meets your goals, we recommend that you only restrict as much as the customer indicates to block. For example, if the customer only indicates that they do not accept Targeting cookies, we recommend you don’t restrict Functional cookies as well.

As many of our partners are adopting Consent Management Platforms (CMPs), “Cookie Banners", or other tools to allow customers to opt out of browser tracking, we have implemented two flags (noFunctional and noTargeting) in our Web SDK which allows our partners to direct Rokt to stop using browser identifiers in certain ways for a particular session.

To make this easy to implement, Rokt has used the same terminology as common CMPs.

Implementation​

The flags, noFunctional and noTargeting, are boolean values that can be included as part of the Rokt.createLauncher call.

  • If Rokt receives one or both of these flags as : true, then we prevent device identifiers being used to enable the appropriate use cases.
  • If no browser tracking IDs are present on the browser, we don't write any of the applicable browser IDs to the customer's browser or integrate any values with Rokt's systems for this session.
  • If one or more browser tracking IDs are present, we ignore the existing IDs that are not allowed and do not integrate them with Rokt’s systems for use in identification. Rokt does not remove any IDs that are already present, we just ignore them for the session.
note

These flags only affect browser IDs. Other identifiers such as email or phone number may still be provided at the discretion of the partner and are used as normal.

If Rokt receives noFunctional or noTargeting : false, any other value, or if the flags are not included in the attribute payload, we continue to use browser IDs as normal. We recommend that the flag only be set to : true if a customer has opted out of tracking through a CMP or other opt out process.

Impacts​

Rokt’s conversion attribution technology is supported on some of the identifiers blocked by the noTargeting flag, so adding this flag impacts our ability to measure performance for offers shown on a particular transaction. If this flag is overused by a partner (e.g., applied to all transactions), the measured performance of that partner will decline and advertiser volume and bid prices may fall as a result. We strongly recommend using this flag only if the customer has specifically opted out.

Example implementation​

await window.Rokt.createLauncher({
  accountId: "account_id",
  noFunctional: false,
  noTargeting: true,
});
Was this article helpful?