Meltdown and Spectre Web Application Risk Management

The recently disclosed groundbreaking vulnerabilities have set a precedent for how massive a security vulnerability can be. In the recent years, we have witnessed vulnerabilities that affect major frameworks like Java, PHP, OpenSSL and CGI. We haven’t seen a vulnerability affecting such a fundamental hardware piece in our computers – the CPU – until this day.

These vulnerabilities shuffle the cards on all the conventional protection mechanisms that exist in the web today – Same Origin Policy, Cross-Origin Source Sharing, Content Security Policy, et al.

The system memory, and IPC (Inter-Process Communication) were considered safe until today, so we could rely on sensitive data residing in memory not leaking outside.

Now that the picture has changed, it forces us to think about new attack surfaces. For example, an attacker may host a malicious website that scans the browser memory for data from other websites. If a victim website is still open in another tab, the data on that page may be compromised.

Reducing the Attack Surface with “SameSite” Cookie Attribute

In order to mitigate some specific attempts of extracting private data, we could consider using the following method.

“SameSite” cookie attribute – This attribute, which is already supported by the major browsers, will prevent the browser from sending the cookie in any request which didn’t originate from the same domain. An attacker that would like to “spray” the memory with private data of the victim site could simply create an website that invokes requests or includes iframes pointing to that site. Regardless of the “SameSite” cookie attribute, the attacker would not be able to read the response contents thanks to the SOP (“Same Origin Policy”) mechanism. However, in light of the new vulnerabilities, this trick could result in sensitive data being stored in memory which then could be read by the attacker’s malicious JavaScript.

Enabling the “SameSite” cookie attribute will prevent the attacker from controlling authenticated/sensitive data being saved in the memory (no cookie = no session).

SameSite attribute is controlled in: Security  ››  Application Security : Headers : Cookies List  ››  Edit Cookie  ››  Insert SameSite Attribute

Updated Jun 23, 2022
Version 2.0

Was this article helpful?


  • I am running 11.4.0 (Build 2464.0) and do not have this option. What version is this available in?


  • Thank you for your interest. This is a new feature available in version 13.1.0 and up.


  • Is there a way to set SameSite=Lax using the HTTP::Cookie command in an iRule?


  • Unfortunately the HTTP::Cookie command doesn't support the SameSite flag. If support was to be added, it would be included in versions past 13.1.0 - which would make it obsolete for the issue at hand (since this feature is included in ASM since 13.1.0).


    The best way to have this enabled using an iRule would be to rewrite the Cookie header using string search and replace.


    You would have to capture responses from the web server, search for the following header: "Set-Cookie: my_cookie=abcd;" and rewrite it as: "Set-Cookie: my_cookie=abcd; SameSite=Lax"


  • Hoolio's avatar
    Ret. Employee

    In BIG-IP v12.0, we added the ability to use "HTTP::cookie attribute" to read/set/delete arbitrary cookie attributes. Here is an example for how to use this command to set the SameSite attribute on BIG-IP and web application cookies:



    In v11, you can use Avalanchee's suggestion of appending ; samesite=VALUE to Set-Cookie response headers. There's an example of this in the Devcentral iRule toolbox: