17 Mar, 2020 | 3 min read

SameSite Attribute Support in WSO2 Products

  • Mathuriga Thavarajah
  • Software Engineer - WSO2

WSO2’s Platform Security Team constantly monitors the security landscape for the latest developments to ensure that our products are compatible.

This post discusses the SameSite attribute update in Chrome 80 (to be released in February 2020 [1]), which affects the handling of cross-site cookies. The blog further summarizes our plan to ensure that WSO2 products are compatible with these changes.

Cookies in Brief

Cookies play a vital role in persisting the state across web applications. Cookies are small pieces of data about user interaction that are stored by the browser to identify user sessions. These cookies are designed to be sent along with requests across sites.

Requests for an HTTP resource can originate either from first- or third-party sites. A request can be identified as originating from the first-party if the domain associated with the resource matches the request initiator domain, which is known as the Referrer (e.g., x.com initiates a request to get content from x.com/data.jsp).

A request can be identified as originating from a third-party if the domain associated with the resource does not match the request initiator domain. An example is when the server from x.com makes a request for y.com/data.jsp to get some data. This is also known as a cross-site request.

When sending cookies with a request originating from a third-party site, extra attention needs to be taken in securing the cookies since it is easier for the attacker to perform Cross-Site Request Forgery (CSRF) attacks in addition to other attacks that are caused by cross-site requests.

The SameSite Attribute

The Internet Engineering Task Force (IETF) standard hails SameSite as the latest exciting approach to mitigate attacks caused by cross-origin requests. Google Chrome, Mozilla Firefox, and some other browsers have been promoting using the SameSite attribute [2].

From the IETF Specification

The IETF specification mentions that “the SameSite attribute which allows servers to assert that a cookie ought not to be sent along with cross-site requests. This assertion allows user agents to mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks” [3].

Cookies can be secured via the proper setting of cookie attributes. These attributes were: Secure, Domain, Path, HTTPOnly, and Expires. Now, the SameSite attribute is also included in this list.

The SameSite attribute is a very convenient and simple method to protect a website from cross-origin request attacks compared to traditional prevention techniques. For more details, see section 5.3.7 of the specification.

This diagram illustrates how cookies that have the SameSite attribute behave with same- and cross-origin requests.

  • When a user requests for an HTTP resource from its same-origin, then, the cookies are added with the request regardless of SameSite attribute’s presence.
  • When an attacker tricks the victim to visit malicious sites, and a request for an HTTP resource originates from a malicious site, cookies that do not have the SameSite attribute are added to the request that might lead to a cross-site request attack. Cookies that have the SameSite attribute are added with the request based on the attribute value specification and request types.

SameSite Attribute Values

The SameSite attribute can be assigned one of the following three values:

  • Strict
    The cookies that are assigned this value are sent with the request if, and only if, the request originates from the first party (i.e., same site/domain) regardless of the HTTP request type.

    Set-Cookie: CookieName=CookieValue; SameSite=Strict;
  • Lax
    The cookies that are assigned this value are added to the GET request initiated by third-party domains as well. However, this is done only if the GET request being made causes a top-level navigation (i.e., the request should cause a change to the URL in the address bar). To elaborate more, iframe, img, and script tags can also be used to load resources that operate as GET requests. However, none of these requests cause top-level navigation (i.e., the URL in the address bar does not change). Therefore, cookies set as Lax are not sent along with these types of GET requests.

    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
  • None

    This value can be used in scenarios where a user intends to send cookies along with the requests initiated by third-party domains.

    Set-Cookie: CookieName=CookieValue; SameSite=None;

The following table gives an idea on how cross-origin requests obey the SameSite cookie attribute as per the IETF specification (when browsers do not enforce the SameSite attribute).

Request type:

Cookies attached with the request if:


Without SameSite, Lax

form get

Without SameSite, Lax

form post

Without SameSite


Without SameSite


Without SameSite


Without SameSite

Cross-Site Request Attack Mitigations in WSO2 Products

Proper Cross-Site Request Forgery (CSRF) mitigations are already in place for all WSO2 products. WSO2 products use “Double Submit Cookie" and "Synchronize Token Pattern” to prevent CSRF attacks. For more information, refer to WSO2 Secure Engineering Guideline [4]. Providing support for the SameSite attribute, on top of the current mitigation techniques in WSO2 products, gives an additional layer of defense for attacks caused by cross-site requests.

Google Chrome 80 update in February 2020

Google Chrome 80, which is to be released in early 2020, enforces some SameSite cookie policies by default. Chrome 80 will support three values that can be assigned to the SameSite attribute: Strict, Lax, or None. More importantly, cookies that don't have the SameSite attribute will be assigned to SameSite=Lax by default.



Attribute Specification



Set-Cookie: key=value; SameSite=Lax



Set-Cookie: key=value; SameSite=Strict


Optional, but if set, the HTTPS protocol is required. Cookies that don't adhere to HTTPS protocol will be rejected.

Set-Cookie: key=value; SameSite=None; Secure

The following table shows how cross-origin requests obey with the SameSite cookie attribute in Google Chrome 80.

Request type

Cookies attached with the request if:


None and Secure, Lax

form get

None and Secure, Lax

form post

None and Secure


None and Secure


None and Secure


None and Secure

Impact on WSO2 Products

Some WSO2 product use cases might be affected by the Chrome 80 update on SameSite.

E.g., OpenID Connect uses Iframes for session management [5]. Since WSO2 Products supports OpenID Connect, session management use cases might be affected.

WSO2’s Action Plan

WSO2 is taking the necessary steps to ensure that all our products are compatible with the change about to be made with Google Chrome 80, or other browsers that would follow the same approach. We are analyzing all the use cases of our products that might be affected due to this change. If any of the use cases break, we will make the necessary fixes prior to the Chrome 80 release. This post will be updated with future developments.

Latest Update


Following are the affected use cases that were identified during this effort:

Breaking Use Cases

Affected Products

Affected URLs

Cookie Name

SAML SSO, SLO Session Management

WSO2 Identity Server
WSO2 API Manager

POST https://<doimain>:9443/samlsso

POST https://<domain>:9443/commonauth

samlssoTokenId commonAuthId

OIDC SSO, SLO Session Management Flow

WSO2 Identity Server
WSO2 API Manager

POST https://<domain>:9443/commonauth

POST https://<domain>:9443/oauth2/authorize

commonAuthId opbs


The above-mentioned WSO2 products are compatible with the ‘SameSite Update in Chrome 80’ in the following ways:

  1. Add the SameSite attribute value as "None;Secure" for the affected samlssoTokenId, commonAuthId and opbs cookies.
  2. For other non-affected cookies that do not contain SameSite, the attribute value will be set as "Strict" by default.

This enforcement, on top of the current mitigation techniques in WSO2 products, gives an additional layer of defense for attacks caused by cross-site requests.

Fix/Patch :

  • WSO2 is issuing patches/updates to WSO2 subscription holders with the instructions through WUM updates.
  • For WSO2 community users, we highly recommend to upgrade to the latest versions of the above-mentioned products to obtain the fixes. Please refer to the following instructions to make it compatible with the chrome-80 update.

From WSO2 Identity Server 5.9.0 to 5.11.0 and WSO2 Key Manager 5.10.0 and later versions:

Add the following configuration in the <PRODUCT_HOME>/repository/conf/deployment.toml file inorder to support 'SameSite=Strict' enforcement. This is not required for WSO2 API Manager.

className = "org.wso2.carbon.tomcat.ext.valves.SameSiteCookieValve"
  • Those who are using product versions between IS 5.3.0 and 5.8.0:
  • Navigate to <IS_HOME>/repository/conf/tomcat/catalina-server.xml file and add the following configuration under the <Host > tag:

            <Valve className="org.wso2.carbon.tomcat.ext.valves.SameSiteCookieValve"/	>
  • Those who are using product versions below 5.2.0:

Configure the SameSite attribute as None in LB Level to make products compatible with Chrome-80 update. For that, add the below code into nginx.conf. This will set the SameSite attribute as None for all cookies.

location / {
        proxy_cookie_path / "/; SameSite=None";

Since proper Cross-Site Request Forgery (CSRF) mitigations are already in place for all WSO2 products, setting the SameSite attribute as None will not cause a threat to cross-site request attacks.

  • The following product versions are not affected by the SameSite attribute update in Chrome 80.

WSO2 Enterprise Integrator: 6.1.0 , 6.1.1 , 6.2.0 , 6.3.0 , 6.4.0 , 6.5.0 , 6.6.0 , 7.0.0

WSO2 API Manager Analytics : 2.6.0 , 3.0.0

WSO2 Identity Server Analytics : 5.7.0 , 5.8.0

WSO2 Identity Server: 6.0.0


WSO2 has sent the Customer Announcement for WSO2 Subscription holders.

If you have any concerns regarding this update, please feel free to reach us through [email protected] or the WSO2 customer support portal.

[1] https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

[2] https://caniuse.com/#search=samesite

[3] https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-03.html#rfc.section.5.3.7

[4] https://wso2.com/technical-reports/wso2-secure-engineering-guidelines#A3811

[5] https://openid.net/specs/openid-connect-session-1_0.html

[6] https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/

[7] https://blog.chromium.org/2019/10/developers-get-ready-for-new.html