Unable to use Msal localStorage option on Azure Frontdoor (with WAF) hosted website

Core Library

MSAL.js (@azure/msal-browser)

Core Library Version

4.0.2

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

4.0.2

Public or Confidential Client?

Public

Description

When upgrading to MSAL v4 and using localStorage as the backend for caching, MSAL creates a session cookie msal.cache.encryption as described in docs. This cookie stores a JSON string with the following format: {"id":"...uuid...","key":"qQfZ7...oWmXE"}.The contents of this cookie triggers web application firewall rules for sql-injections.

Error Message

No response

MSAL Logs

No response

Network Trace (Preferrably Fiddler)

• [ ] Sent
• [ ] Pending

MSAL Configuration

{
  auth: {
    clientId: msal.clientId,
    authority: `https://login.microsoftonline.com/${msal.tenantId}`,
    redirectUri: '/account/login',
    navigateToLoginRequestUrl: true,
  },
  cache: {
    cacheLocation: BrowserCacheLocation.LocalStorage,
  }
}

Relevant Code Snippets

private tryMsalLogin(allowRedirect: boolean = true, background: boolean = false) {
  if (this.msal.instance.getAllAccounts().length === 0) {
    if (!allowRedirect) return;
    return this.loginRedirect();
  }
  this.msal
    .acquireTokenSilent({
      scopes: this.env.appScope,
      account: this.msal.instance.getAllAccounts()[0],
    })
    .subscribe({
      next: (value) => this.setToken(value.accessToken, background),
      error: (_) => {
        if (!allowRedirect) return;
        this.loginRedirect();
      },
    });
}

private loginRedirect(): void {
  this.msal.loginRedirect({
    scopes: ['openid', 'email', 'offline_access', ...this.env.appScope],
  });
}

Reproduction Steps

1. Create an application with MSAL v4
2. Deploy behind Azure Front Door with web application firewall rules turned on
3. Login in application
4. After login is finish and local storage / cookies are set all following requests on the domain are blocked (Detects MySQL comment-/space-obfuscated injections and backtick termination / Detects basic SQL authentication bypass attempts / Detects classic SQL injection probings)

Expected Behavior

Similar as MSAL v3

Identity Provider

Entra ID (formerly Azure AD) / MSA

Browsers Affected (Select all that apply)

Chrome, Firefox, Edge, Safari, Other

Regression

@azure/msal-browser ^3

Hello, I can confirm that the issue also occurs on our end. Our SPA applications are hosted behind Azure Front Door, and SQL rules 942370, 942200, and 942000 are being triggered, causing the site to stop serving content.

We temporarily disabled the prevention mode in our WAF policies to better understand how to create a proper exclusion rule. Ideally, this should be addressed within the library itself to prevent these false positives from occurring.

We appreciate your support in resolving this. Can maybe @tnorling help us out?

@yurnih: Have you already implemented a workaround for this?

Best regards, Patrick

I'm getting blocked too if I use LocalStorage, any news on this?

Yep, we are facing the same problem too :(

Also happening here with SessionStorage.

Create WAF exclusion rule for msal.cache.encryption cookie name.

Hopefully library will be updated in the future to handle this. I'm guessing since there's a workaround it won't be as high of a priority.

We can also confirm that this is an issue when using LocalStorage and MSAL 4.x Switching to SessionStorage fixes the issue

Can confirm this issue using Azure Application Gateway. A bit sad two microsoft products are fighting eachother like this.

We are facing the same problem too, any proper fix for this?

Same problem, the issue is quite serious. Creating a WAF exclusion rule is a no go given the amount of apps/environments affected. At the moment we rolled back to MSAL 3.x

An idea for a simple fix in the library: if the value of msal.cache.encryption would be internally base64 encoded before being url encoded, the default WAF rules would have no issue with it.

This issue is affecting a huge number of enterprise apps that I am supporting. All of them are using this library and now we see them failing one by one on a daily basis after the update is done.

@tnorling @jo-arroyo any plans to look into it? I can imagine this will affect many enterprise customers very soon!

I understand the frustration with this WAF conflict between two Microsoft products.

I recommend you switch to sessionStorage as your primary fix. This resolves the WAF conflicts and actually improves your security posture by not persisting tokens across browser sessions. The trade-off is users need to re-authenticate when opening new tabs or after browser restart.

Why this approach works best:

• More secure than localStorage
• No WAF policy changes required initially
• Demonstrates security awareness to your security team

Parallel track: Use this as an opportunity to start conversations with your security team about a controlled WAF exclusion for the msal.cache.encryption cookie. Coming to them with sessionStorage already implemented shows you prioritize security, making future negotiations much easier. If they are against broad cookie exclusion explore separate WAF policy route. It’s a win-win: better security posture plus stronger cross-team relationships for future issues.​​​​​​​​​​​​​​​

This bug also occurs with React applications

And in response to @alexkolt. Switching to sessionStorage does not improve security posture. There is absolutely no difference in vulnerability between sessionStorage and localStorage, since neither changes the expiry time of the auth token. Whether an attacker obtains the token from sessionStorage or localStorage makes no difference.

+1 for a fix that doesn't need WAF exclusions