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​

Support for Data Deletion​

Rokt provides our partners with the ability to send data deletion requests to Rokt in order to uphold the requests and preferences of their customers.

Partners can configure their Rokt implementation to align with user consent preferences and provide different customer experiences accordingly.

Functional Tracking Technologies: These enable personalized and optimized experiences on your site, including enhanced functionality within the checkout (such as presenting Upsells).

Targeting Tracking Technologies: These extend personalization using customer behaviors collected with appropriate consent across other sites.

Partners are encouraged to respect the level of restriction indicated by the customer and configure their implementation accordingly.

To support partners using Consent Management Platforms (CMPs), cookie banners, and similar tools, the Rokt Web SDK includes a configurable flag—noFunctional—that partners can set to prevent the use of browser identifiers or tracking technologies for a given session.

This flag aligns with terminology used by common CMPs for ease of implementation.

Implementation​

Partners can include the noFunctional flag as a boolean value in the Rokt.createLauncher call.

  • When set to true, the partner instructs the SDK to disable the use of device/browser identifiers for that session.
  • If no browser tracking IDs are already present, the SDK will not write any applicable browser IDs to the customer’s browser or connect identifiers to Rokt systems for that session.
  • If one or more tracking IDs are already present, the SDK will ignore those identifiers and not associate them with Rokt systems during that session. Existing IDs are not removed from the browser, but they are not used.
note

These flags apply only to browser-based identifiers. Other identifiers—such as email addresses or phone numbers—may still be provided at the partner’s discretion and will continue to be used in accordance with the partner’s configuration.

If the partner sets noFunctional or noTargeting to false, omits the flags, or uses any other value, browser identifiers will be used as configured.

Partners should only set these flags to true when a customer has opted out of tracking via a Consent Management Platform (CMP) or other opt-out mechanism implemented by the partner.

Example implementation​

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