Memory Protection: An Extra Line of Defense Against Spectre Attacks

April 8th, 2021 | By Pedro Fortuna | 3 min read

Memory protection is an extra line of defense against Spectre attacks. In this blog article, we explore why development teams need to deploy application-level mitigation measures.

Even five years after the Spectre vulnerability was discovered, it continues to pose a concern as it can still be exploited by attackers.

Google recently published a proof-of-concept exploit written in JavaScript on their Google Security blog that still works against multiple browsers, operating systems, and processors.

What are Spectre attacks?

Spectre attacks break the isolation between different applications and allow an attacker to trick error-free programs into leaking their secrets.

By taking advantage of flaws in the optimization features of CPUs (speculative execution), Spectre attacks force programs to access arbitrary portions of their memory, which are then read by a side channel.

Due to its nature, the Spectre vulnerability allows for attacks against different types of applications, including web apps. Attackers can potentially exploit them to extract sensitive information across different websites in a browser by exploiting how they interact with processors and on-chip memory.

In applications that handle critically sensitive data, such as government, healthcare, and financial apps, such an attack can have devastating results.

Attackers' motivations to exploit the app's memory may vary, but typically they intend to:

  • Reverse-engineer the code and understand its mechanics;

  • Modify the app's behavior and, for example, access new features;

  • Access and retrieve sensitive data.

However, the bottom line when it comes to Spectre attacks is that there is still no ultimate solution to mitigate them, despite browser vendors’ efforts (such as Site Isolation, out-of-process iframes, Cross-Origin Read Blocking, and others).

To fully mitigate these attacks, the changes required are at the processor architecture level (hardware), which can take years.

Application owners must take action to protect sensitive data and prevent it from being present in parts of the memory that can be read by attackers.

In their proof-of-concept exploit, Google also recommends that web developers consider isolating their sites more robustly by using new security mechanisms that actively deny access to cross-origin resources.

To facilitate their process, they have published Post-Spectre Web Development and Mitigating Side-Channel Attacks with concrete advice for developers.

Memory protection as an extra line of defense

Since the potential outcome of a successful Spectre attack on web apps may mean the leakage of millions of sensitive data records, application owners must look for additional lines of defense.

Seeing how Spectre attacks can retrieve sensitive data from the app’s memory, one such line of defense is memory protection.

In the context of web apps, Memory Protection is a defensive technique developed by Jscrambler that encrypts sensitive data in memory and only decrypts it when the application needs to access it.

Thanks to this JIT (just-in-time) memory access, the attack window is narrower. As a result, there’s a high likelihood that, if the attacker retrieves some data, it will be encrypted and therefore useless.

This defensive technique uses state-of-the-art cryptographic algorithms and can be applied to strings and numbers in complex structures like objects and arrays.

To avoid impacts on performance, do not apply memory protection to data structures accessed constantly but rather to those not accessed as often. These can include keys, authorization tokens, and others.

Note that this does not stop attackers from scraping sensitive data from memory. However, when used alongside browser defenses and other application-level mitigation measures, it significantly reduces the potential impact of a successful attack.


While Spectre attacks require hardware changes for complete mitigation, the risk they pose for web apps is too heavy for application owners to wait for a definite fix.

A combination of recent browser defenses and in-app protection such as Jscrambler’s Memory Protection contributes to reducing the effects of these attacks. It provides a much-needed line of defense when used on top of all other recommended defensive strategies.

You can get started with Jscrambler for free now!


The leader in client-side Web security. With Jscrambler, JavaScript applications become self-defensive and capable of detecting and blocking client-side attacks like Magecart.

View All Articles

Must read next

Jscrambler Tutorials

Jscrambler 101 — Memory Protection

In this 101 tutorial, we explore Memory Protection - a new feature that increases the security of sensitive data in your web and mobile apps.

November 11, 2020 | By Jscrambler | 4 min read

Web Security

Full-stack JavaScript Source Code Protection

With Node.js you can do Full-stack JavaScript Web Apps. JScrambler 3.6 introduces Node.js support and is now the first Full-stack JS Protection solution.

September 8, 2014 | By Pedro Fortuna | 4 min read

Section Divider

Subscribe to Our Newsletter