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)#

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.

While it is possible to implement SRI for the Rokt Integration Launcher script we do not recommend this approach for the reasons outlined below.

Rokt works to continually optimize and improve the performance of the Web SDK to provide a better and more secure experience to our customers. We release updates to the Web SDK using the continuous integration release model. This means that updates are small, frequent, and unscheduled, making it challenging for partners to track new versions and update to the latest version in a timely manner.

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. In these circumstances, partners would be required to update the integration before issues can be resolved.

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.

Should you wish to use SRI with the Rokt script, reach out to data-setups@rokt.com. We'll be happy to discuss the options and potential alternatives to ensure your integration is as secure as possible.

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#

Support for cookie opt-outs#

Rokt uses a few different types of browser identifiers to recognize repeat customers. These identifiers include:

  • 1st-party cookie
  • 3rd-party cookie
  • 1st-party local storage
  • 3rd-party local storage
  • Etag

In a normal session, Rokt checks for these identifiers, uses them for recognition, and writes new ones if the existing IDs are unavailable.

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 a flag in our Web SDK which allows our partners to direct Rokt to stop using browser identifiers for a particular session.

Implementation#

The flag is called noDeviceID, which is a boolean value that can be included as a rokt.init parameter.

If Rokt receives the flag noDeviceId: true, then we prevent all forms of browser tracking for that session. Specifically this means the following:

  • If no browser tracking IDs are present on the browser, we don't write any 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 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

This flag only affects 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 the flag noDeviceId: false, any other value, or if the flag is 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 relies on the identifiers blocked by the noDeviceID 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. As such, we strongly recommend using this flag only if the customer has specifically opted out.

Example implementation#
await launcher.selectPlacements({  identifier: "",  attributes: {},  noDeviceId: true,});
Was this article helpful?