IBM Support

Browser changes to SameSite cookie handling and WebSphere Application Server



Cross-site requests nested within a page can fail after browser updates that change the default behavior of HTTP Cookies without the SameSite attribute.  The affected requests are sent to hostnames within separate registered domains, not just separate hostnames under the same domain.
Full technical details of the SameSite attribute are available in the following RFC:


The immediate symptom for this problem is an unexpected failure to receive an expected HTTP cookie.  The affected URLs are embedded within some other top-level document.


Google has announced that Chrome version 80 and later will change the defaults for cross-site HTTP Cookies. Other browser vendors are anticipated to make the same change in the near future.  More information is available in the announcement from the chromium project here:

Diagnosing The Problem

Given a failure to produce the expected response, validate all of the following are true:
  • The request originates from a browser, not a non-browser HTTP client
  • The enterprise application responsible for responding depends on WebSphere security, session management, affinity, or its own application-specific HTTP cookie.
  • The Cookie in question was unexpectedly not received within the HTTP request
  • The request itself is not a "top-level navigation", in other words it is not the request that shows in the browsers address bar.
    • Make note of the domain used in the top-level navigation.
    • Some indications of this are the an Origin header that doesn't match the Host header, or a Sec-Fetch-Dest header with a value of "iframe".
  • The Cookie in question was not accompanied by the SameSite attribute when it was originally transmitted with the Set-Cookie HTTP response header.
  • The "site for cookies" in the URL of the failing request is different from the "site for cookies" in the top-level navigation.
    • The algorithm for determining "site for cookies" for a request is described in detail here:
    • A simplified explanation of "site for cookies" for a request URL is the rightmost portion of the hostname that was directly registered with some public registry, or the "effective top-level domain + 1".  For example, all URLs ending in "" have the same "site for cookies".
    • In addition to traditional TLDs (like .com and .net) and eTLDs (like ""), browsers also consider "public suffixes" that users register subdomains with, that such as This means the "site for cookies" for URL is ""    

Resolving The Problem

1. Resolving the problem for new cookies
While no WebSphere Application Server functionality inherently requires cookies set with SameSite=None, resources hosted on WebSphere Application Server might be accessed cross-site.  There are several paths to resolving or mitigating the problem:
  • Re-architect applications to not require cross-site cookies
    • Keeping cookies as implicitly SameSite=Lax helps protect against Cross Site Request Forgery (CSRF).
  • Enterprise IT administrators might need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready.
  • Modify Set-Cookie headers to add SameSite=None (and the Secure flag) dynamically
  • Update applications and the Application Server to add SameSite=None (and the Secure flag) to generated cookies
    • Fixes for applications that use HTTPServletResponse.addHeader() and HTTPServletResponse.setHeader() requires APAR PH20912
    • Support for adding SameSite=None to cookies generated by the Application Server (JSESSIONID, Security) will be delivered as part of APAR PH22157.
    • Support for specifying the SameSite attribute in APIs that take "javax.servlet.http.Cookie" parameters is not yet available in enterprise applications, but the changes for PH22157 allow those attributes to be specified outside of the application.
2. Handling pre-existing cookies 
It is typical for cookie-issuing software to only set new cookies when the cookie in question was not sent by the client. This means some existing cookies set without SameSite=None may take some time to pick up the new attribute.  Cookies either last  for the duration of the browser session or a specified expiration time. 
One way to force a new cookie to be set is to change the cookie name being used. This may have repercussions in other components of the system.
An alternative way which may be suitable while the cookies are in transition is to use a proxy like IBM HTTP Server or Apache HTTP Server to replace existing cookies with a new cookie that has "SameSite=None; Secure" appended. 
A brief example follows assuming a cookie name of "Apache" as used by the Apache module mod_usertrack.  Because Cookie and Set-Cookie are not symmetrical, the generic configuration below is not aware of the original attributes on the Set-Cookie that occurred in the past.  Those need to be explicitly specified in the 2nd directive to be maintained.
SetEnvIf Cookie "(^|\s+|;\s+)Apache=([^;,]+)" had-usertrack=$2
Header always add Set-Cookie "Apache=%{had-usertrack}e; SameSite=None; Secure" env=had-usertrack

Document Location


[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTJ","label":"IBM HTTP Server"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
20 September 2021