PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure Browser Flow Best Practices

v1.0 Best Practices
3-D Secure

EMV<sup>®</sup> 3-D Secure Browser Flow Best Practices Version 1.0 September 2021 EMV 3-D Secure Browser Flow Best Practices Legal Notice

of 12

Legal Notice

This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

Practices Contents

Practices Introduction

of 12

Introduction

This document describes the best practices for how the 3DS Requestor and the ACS provide and secure the iframes used in the 3-D Secure Browser flow and references the applicable requirements in the 3-D Secure Protocol and Core Functions Specification version 2.3.0.0 (and subsequent versions). All requirements referenced in this document are defined in version 2.3.0.0. These best practices incorporate the results of a security analysis conducted with web security experts, multiple usability studies and contains feedback from EMVCo’s Technical Associates including 3DS Server and ACS vendors with the objective being to best balance the usability and security requirements of the 3DS Requestor and the ACS. The 3-D Secure Browser flow is used to process transactions where the Cardholder has initiated interactions with the 3DS Requestor through a browser. Integral to the Browser flow are two iframes (the 3DS Method iframe and the challenge iframe). Adherence, by the 3DS Requestor and the ACS, to the iframe requirements documented in the 3-D Secure (3DS) specifications and further clarified in this document, is critical to the successful processing of the Browser Flow. In addition, this document describes iframe best practices to further enhance processing and the Cardholder experience. The iframe requirements and best practices cover how to secure the iframes and how the 3DS Requestor and the ACS can coordinate to optimise the size of the challenge iframe and the content it displays. Supporting Documentation The following documents are specific to the EMV 3-D Secure protocol and should be used in conjunction with this specification. These documents as well as EMV 3-D Secure FAQs are located on the EMVCo website.

  • EMV<sup>®</sup> 3-D Secure—Protocol and Core Functions Specification version 2.3.0.0 (and subsequent versions) Practices iframe Security of 12 iframe Security One of the key challenges that 3-D Secure was designed to address is managing the relationship between three parties that have differing degrees of trust between them. Specifically, 3-D Secure seeks to provide a secure mechanism whereby a Cardholder interacting with a 3DS Requestor (e.g., Merchant) can reliably prove their identity to a card Issuer. In this scenario, the relationship between the Cardholder, the card Issuer, and the 3DS Requestor are all distinct from one another. In the context of the Browser flow, the Cardholder may not trust to share his credentials with the 3DS Requestor web site, but they likely trust the content of the Issuer. The Issuer may not trust the 3DS Requestor application or the Cardholder data input. The 3DS Requestor may not trust the Cardholder, or the Issuer content. Managing these complex relationships is a difficult challenge. 3DS Requestors are typically concerned about increasing conversion rates–if the checkout process is confusing or seems insecure to Cardholders, they may choose to leave the site and make purchases elsewhere. 3DS Requestors are also concerned about fraudulent purchases and chargebacks. As a result, 3DS Requestors desire security guarantees that are obvious to Cardholders, and a simple user-interface that allows the Cardholder to easily complete their purchase. Additionally, 3DS Requestors need protection in the unlikely event that an Issuer site becomes compromised. 3DS Requestor Apps need a way to ensure that content sourced from the Issuer cannot be executed in the 3DS Requestor App in a way that compromises the 3DS Requestor. Issuers’ main objective is to protect their customer’s credentials. They rely on the same origin protection provided by the iframe. Issuers are also concerned about clickjacking attacks causing fraudulent activity against a Cardholder’s account. To prevent this, Issuers have often been advised to implement anti-clickjacking measures, such as setting the X-Frame-Options HTTP header to none and using "frame-buster" JavaScript to ensure that Issuer web application content is not contained inside of a framed element. However, since Issuers are often using frame-prevention techniques, 3DS Requestors are unable to accommodate this, and must instead use a process that may be more confusing for Cardholders, such as pop-up windows, or redirection to the Issuer website directly. Both alternatives can be more confusing for the Cardholder:
  • Cardholders distrust pop-up windows because of aggressive online advertising, and as a result, most browsers now default to disallowing pop-up windows.
  • Cardholders shopping at a 3DS Requestor site want consistent branding. One way they experience this is through the domain name of the website and by remaining on the 3DS Requestor’s site through completion of the checkout process. If the website redirects the Cardholder to a different domain (to authenticate themselves to the Issuer), the Cardholder may be confused, for example, by the unknown URL, and decide not to complete the process. Practices iframe Security of 12 For these reasons, the 3DS protocol requires Issuers that want to take advantage of the security assurances that the 3DS protocol provides to allow their content to be framed. Issuers need to understand how to allow their content to be framed in conformance with the 3DS specification, without compromising the security of their content and customer data. The 3DS protocol also requires the 3DS Requestor to provide a secured iframe context to the ACS by following the 3-D Secure specification Requirements 261 and 267. From the perspective of the web browser, there is no difference in how content from multiple domains is treated: whether that content is included in an iframe, a pop-up window, or a redirect to another domain, the browser treats the content in each of these scenarios the same way, enforcing its same-origin policy consistently. Modern browsers and applications have tools available that allow content to be safely embedded. Enhancements to the HTML specifications provide additional resources that give developers granular control over the privileges embedded content has. This allows applications to establish secure payment flows involving multiple parties, while providing a smooth user experience. As a result, a key focus of 3-D Secure is on providing the smoothest user-experience for the Cardholder. With current technology, the simplest process is to utilise iframes to facilitate the checkout, relying on the security guarantees that the browser’s same-origin policies provide to minimize risks to Issuers, 3DS Requestor and the Cardholders. In summary, and in line with the conclusions of EMVCo security review and the user experience study, the best approach is to have the 3DS Requestor site embed the Issuer content into their own site using an iframe. This method can allow the 3DS Requestor to present what appears to be a consistent user-experience without leaving the 3DS Requestor site and allows the Issuer to retain control over the content they provide to the Cardholder, securely receiving data entered by the Cardholder without allowing the 3DS Requestor site to access the content of that data. However, for this to be true, the following requirements and best practices need to be implemented by both Issuers and 3DS Requestors, to ensure that all parties are protected during 3DS enabled transactions. The requirements and best practices are described in the following two sections. iframe Security Requirements and Best Practices for 3DS Requestors When opening the iframes, the 3DS Requestor is required to use the methods defined in Requirements 261 and 267 in the EMV<sup>®</sup> 3-D Secure—Protocol and Core Functions Specification, to ensure the security of the 3DS Requestor site. In particular, the 3DS Requestor is required to apply the iframe and sandbox attributes defined in Section A.15 of the EMV<sup>®</sup> 3-D Secure—Protocol and Core Functions Specification. Practices iframe Security of 12 iframe Security Requirements and Best Practices for Issuers The protection of issuer content from a Merchant is ensured by the iframe used to insulate Issuer content from Merchant content. What this means in practice is that the Issuer does not need to trust any scripts or content from the Merchant site (outside of content in 3DS messages) and the Merchant does not need to trust any scripts or content from the Issuer. The Issuer must allow ACS content to be framed by the Merchant (Refer to Requirement 122 in the EMV<sup>®</sup> 3-D Secure—Protocol and Core Functions Specification). The Issuer should utilise the following best practices to ensure the security of the Cardholder data:
  • Issuers can generally continue utilising their existing anti-clickjacking headers and/or "frame-buster" scripts throughout their infrastructure. However, the specific URLs involved in the 3DS application flow should be configured to explicitly permit framing of that specific content to comply with 3DS requirements. This can be done by dynamically removing the relevant headers (such as X-Frame-Options) in 3DS application paths or by specifically trust listing the 3DS URLs to allow framing of the content only in 3DS context. For example, if the ACS checks that the incoming post is a CReq message and corresponds to an open transaction, it could unset the X-Frame-Option. Specifics of how to achieve this will vary and are dependent on the technology stacks in use within each application. An example configuration that could work for systems using Nginx to serve web content is shown below: Location /3ds/challenge { more_clear_headers 'X-Frame-Options'; }
  • Adding content to the 3DS challenge questions that requires user data entry, beyond simple actions such as single click verifications will help ensure that the challenge content is not being manipulated through automated scripting or click-jacking and is being submitted knowingly by the end user. Secure CSP Guidelines
  • Move inline JavaScript to standalone files.
  • Create a reporting endpoint able to receive and process reports of resources that are blocked by the CSP.
  • Set a CSP which adds trusted sources of JavaScript to the trust list and disables inline JavaScript.
  • While developing the policy, a tool such as Google’s CSP Evaluator can be used to check the configuration for security issues.
  • During the testing or transition period, the Content-Security-Policy-Report-Only header can be used instead of Content-Security-Policy. With this header set, browsers will not block resources, but will still send notifications to the specified report URI when a resource would have been blocked by the policy. Practices iframe Security of 12 Secure CORS Guidelines
  • There is no need for cross-domain access between Merchant and Issuer domains, they are isolated by the iframe.
  • If cross-domain communication is not needed by the Issuer content, CORS AccessControl headers should be removed entirely. In many cases, due to the same origin policy CORS may not be applicable to the environment since the framed content will be sourced from the Issuer domains.
  • Otherwise, Access-Control headers should be limited to the minimal set of permissions necessary to perform cross-domain functionality:
  • Access-Control headers should only be returned for specific, necessary resources or routes, rather than applied globally. − For each route, explicitly set the relevant Access-Control headers to allow only the specific methods, headers, or credentials which are necessary.
  • In the case of the Access-Control-Allow-Origin header, domains should be specified using a Trust List. Only domains which are necessary for cross domain communication should be included. This list will need to be generated programmatically—at the time this document was created there is not a way to use wildcard notation in this header. Practices Challenge iframe Requirements and Best Practices of 12 Challenge iframe Requirements and Best Practices The EMV 3-D Secure core specification states that the 3DS Requestor is responsible for controlling the placement and sizing of the frame used for Cardholder authentication in the Browser flow. This section identifies how this frame is communicated to the ACS and how the ACS should ensure the challenge content is properly provided so that it is rendered correctly on the Cardholder’s device. The 3-D Secure core specification states how the 3DS Requestor and the ACS provide the browser flow user interface (UI) by using the following key data elements:
  • Challenge Window Size
  • Browser Screen Width
  • Browser Screen Height The requirements and best practices for how the 3DS Requestor and ACS properly provides the 3-D Secure UI follows. Challenge iframe 3DS Requestor Requirements and Best Practices The 3DS Requestor shall adhere to the following requirements (Refer to the 3-D Secure specification Requirements 267 and 265 for the challenge window size) to ensure the challenge iframe is properly opened on the 3DS Requestor site:
  • If a frame is opened on a window, then the size needs to correspond to a valid value for the element Challenge Window Size (01-05). It is very important for the 3DS Requestor to provide accurate information to the ACS.
  • If 05 is selected, then the window size available to the ACS needs to be the screen dimensions as specified in the data elements Browser Screen Width and Browser Screen Height. The 3DS Requestor cannot open a different frame size than the ones specified in Challenge Window Size.
  • Browser Screen Width and Height should always contain the values provided by the system (refer to the browser screen property; https://developer.mozilla.org/enUS/docs/Web/API/Screen, and not be modified by the 3DS Requestor. The 3DS Requestor should utilise the following best practices to ensure the challenge iframe is properly opened on the 3DS Requestor site:
  • If a frame is opened on a mobile device, then the frame needs to be sufficiently large, as a proportion of the screen, to enable the Cardholder to view the ACS content without difficulty.
  • On a mobile phone, the recommendation is to use the full screen challenge window size (05). Practices Challenge iframe Requirements and Best Practices of 12
  • On a small screen device (tablet, small laptop), the recommendation is to use the medium challenge window sizes (03 or 04).
  • If JS is not enabled, the 3DS Requestor should set an appropriate challenge window size. Full screen (05) should be used only when appropriate, for example, for mobile device (since the ACS will not receive Browser Screen Height and Browser Screen Width).
  • The 3DS Requestor also needs to set a proper viewport so that the whole website including the challenge iframe, scales properly (example viewport tag:). Refer to https://developer.mozilla.org/en-US/docs/Web/CSS/Viewport_concepts for viewport.
  • The 3DS Requestor should avoid using CSP to limit the ACS URLs and domain, as ACS may re-direct or load resources from alternative domains (for example, re-direct to a national authentication scheme). Enforcing CSP in the challenge iframe could result in failed 3DS authentication. Example challenge iframe Example POST to render challenge iframe Note: JavaScript may be used to post the form, or a button when JavaScript is not enabled. Challenge iframe ACS Requirements and Best Practices The ACS shall adhere to the following 3DS specification Requirements;177–183 and 380–384, to ensure that the ACS content is properly provided to the challenge iframe:
  • The ACS needs to be able to provide HTML content sized appropriately for all the Challenge Window Size values (Refer to Requirement 177 in the 3-D Secure core specification). Practices Challenge iframe Requirements and Best Practices of 12
  • The ACS needs to be able to support a properly formatted user interface for mobile devices and desktops. If the Challenge Window Size is (05), the ACS needs to be able to provide appropriately sized content that is suitable for the Browser Screen Width and Browser Screen Height values provided in the AReq message. The Browser Screen Height and Width are the dimension of the window itself. Widgets such as taskbars or other special application windows may reduce the amount of space available to browser windows and other applications.
  • The ACS content needs to be responsively designed. This will ensure device orientation changes are accommodated (as well adapt to the hopefully rare situation where a misconfigured merchant provides the wrong Challenge Window Size value). Responsive design is a method of layout used to ensure content scales appropriately on a wide range of devices. It is strongly encouraged for the ACS to define breakpoints (refer to https://www.w3.org/TR/css3-mediaqueries/) for the challenge HTML content in line with the applicable height and width values of the Challenge Window. This will guarantee the Cardholder receives the optimal user experience regardless of the values provides by the 3DS Requestor or device orientation. The ACS should utilise the following best practices to ensure the ACS content is properly provided to the challenge iframe:
  • The ACS needs to set a proper tag to define the viewport, allowing the content presented within the challenge to scale appropriately to the Cardholder device. Without this set, the challenge content may appear illegible based on the resolution of the device used for the transaction. Example viewport tag:.
  • The ACS should test that their challenge UI displays correctly across device types and configurations. At a minimum, the ACS should test the various sizes specified in Challenge Window Size, and the most popular phone sizes for full screen.
  • Support all devices as documented in EMV 3-D Secure SDK—Data Version 1.4 (e.g., landscaped as well as portrait layouts for gaming platforms).
  • The ACS content should not prevent scrolling in a frame (i.e., iframe scrolling attribute). The ACS content should also not be designed to prevent scrolling. This is often an antipattern leading to increased Cardholder confusion and poor user experiences.
  • The ACS can utilise scripting techniques to determine the frame size during the challenge flow, when the ACS is interacting with the Browser.
  • If JS is not enabled, Browser Screen Height and Width is not provided. The ACS should use the provided device information, in addition to the Challenge Window Size value, to understand the device type and corresponding screen size to provide.
  • The ACS should ensure that their provided content would display properly and ‘look good’ to the Cardholder no matter what the environment is. For example, scripting/CSS can be used to ensure the UI is properly formatted. Note: The Challenge Window Size, Browser Screen Height and Browser Screen Width elements all reference CSS pixels, not hardware pixels. Practices 3DS Method 3DS Requestor Requirements and Best Practices of 12 3DS Method 3DS Requestor Requirements and Best Practices The 3DS specification requires the 3DS Requestor to open a hidden iframe for 3DS Method in the Cardholder browser (Refer to Requirement 261 in the 3-D Secure core specification). To enable the ACS to run the needed data collection scripts the following best practices should be followed:
  • For browser compatibility iframe should be made hidden with the following style setting: "visibility: hidden", and the iframe size should be set to height = 10, and width = 10. Example for 3DS Method iframe Note: JavaScript may be used to post the form. © 2021 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV<sup>®</sup> is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.