• Search Engine Land
  • Sections
    • SEO
    • SEM
    • Local
    • Retail
    • Google
    • Bing
    • Social
    • Resources
    • More
    • Home
  • Search Engine Land
  • SEO
  • SEM
  • Local
  • Retail
  • Google
  • Bing
  • Social
  • Resources
  • Live
  • More
  • Events
  • SUBSCRIBE

Search Engine Land

Search Engine Land
  • SEO
  • SEM
  • Local
  • Retail
  • Google
  • Bing
  • Social
  • Resources
  • More
  • Newsletters
  • Home
SEO

SharedArrayBuffer warnings in Search Console: Clarifying a new cross-origin isolation security policy

Android Chrome 88 and desktop Chrome 91, plus Firefox 79+ now implement SharedArrayBuffers again after Spectre caused a multiyear security blackout on the feature until new security requirements were in place.

Detlef Johnson on March 16, 2021 at 12:07 pm
  • More

Web-facing pages are an information security battle zone as we fight hackers who try to steal company secrets. Modern webpages often leverage resources from more than one origin (domain). This can lead to vulnerabilities. As pressure mounts surrounding security concerns that affect new features, webmasters have a growing list of options from browser makers, including directives for handling “cross-origin” resources to help prevent information leaks.

Security measures

You may already be familiar with rel="noopener", a way to make sure a page’s hypertext links and form elements that have outbound actions, like links which open another site in a new browser tab, won’t allow Javascript on an external page to access an internal page via Window.opener property. Imagine clicking a link that opens a new tab. When you close the new tab, the original page was secretly switched to one with phishing lures. The opener property gives attackers an ability to change URLs of the original tab.

You might be thinking: “I would never link to a page that would that!” Here at SEL, we constantly link out to lots of pages and we don’t have the luxury of time to check out source code. We use rel="noopener" so that we don’t have to. Browser makers give us sophisticated security options so we can lock things down in all sorts of ways in order to prevent us getting exposed to exactly such attacks.

You may have seen reference to the Cross-Origin-Resource-Sharing (CORS) http response header. This is technically more difficult to manage when you don’t have control over your web server. CORS (Access-Control-Allow-*) values will limit access to only a set of domains that you specify as a list. When your page includes analytics, advertisements, and other third-party script resources, those not specifically on an allow list (when you use CORS) get blocked and will trigger browser console error messages to let you know.

Spectre meltdown

When things just get too heated, it’s safer for browser makers to turn off a feature altogether. That’s exactly what’s happened a few years ago with SharedArrayBuffers when it was disabled by default 6-months after its debut and until a solution was prepared and agreed on by consensus recently. The problem was that a proof of concept post was published which demonstrated a “side-channel” vulnerability accessing kernel memory, a more serious problem than URL switching.

In a nutshell, a large set of CPUs are vulnerable to Spectre side-channel attacks by virtue of performance boosting “speculative execution” of low level code with access to hardware resources. Speculative execution predicts instructions and races ahead to execute them in advance of their arrival. That would be excellent except it does so using a process in kernel mode! Executing program code in kernel mode instead of user mode is at the heart of the vulnerability.

SharedArrayBuffers API instructions can trick speculative execution to allow a malware wrought page access to normally protected kernel memory including all your other pages, not only those pages opened by following a link from one to another, but any page open in your browser. It can also be tricked to give up passwords, encryption keys, and personally identifying information to leverage for additional attacks.

Imagine pinning a personal banking page open with your account details. Then separately browsing a page that unfortunately contains the exploit. An attacker can retrieve everything the banking page contains and any other page. Information leaking from that sort of attack can constitute highly sensitive, personally identifying information which can expose one to identity theft, and potentially enable targeted attacks against organizations, including government systems.

Return of SharedArrayBuffers

Google’s Android Chrome 88 and desktop Chrome 91, plus Firefox 79+, all now implement SharedArrayBuffers again after a new security policy can mitigate danger from access to private memory. Any resource not specifically on your “allowed” list will get blocked. Since the feature was off by default, now that it is back on, JavaScript APIs that made use of it are starting to trigger blocking actions when they failed silently beforehand.

For example, WebGLRenderingContext implements the SharedArrayBuffers which failed silently during the blackout period. The security settings to accommodate it are new enough very few developers have heard of it. As reports of blocking actions pile up at google, the sudden appearance of notices in Google Search Console can catch us off guard.

Incomprehensible GSC error emails reaching new heights today:#SharedArrayBuffers #COOP #COEP pic.twitter.com/v02I6nh6iX

— Joost de Valk (@jdevalk) March 15, 2021

Implementing the new security policy

The time has never been better to undertake the work to establish a CORS policy. Without a security policy in place, third-party resources are cause for enough havoc already, let alone potentially leaking your secrets. Only list those third-party resources which you intend to utilize in a page. You want to always “distrust by default” all resources in order to limit your risk. Then, deliberately white-list as few domains as you can get away with.

When you don’t manage your own web server, some Content Delivery Networks (CDNs) offer the ability to change response headers on-the-fly. Either way, it’s a matter of adding field names and values, one directive per line. The SEO practitioner can use a dialog driven by a site review report to call into question third-party resource inclusions and thereby be in a position to create a refined list for the person who manages the web server at the host.

Cross-origin isolation

Implementation of SharedArrayBuffers requires a security environment where you lock down access using one or more response header directives. The specific policy called for is entitled cross-origin isolation. To configure Cross-Origin Isolation, you will add two new page headers, COOP and COEP (as depicted below), which work in tandem with one or more other security headers, namely CORS and or CORP, which individually or in combination provide your white-listed cross-origin domains.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Notice the Opener policy? The same-origin value requires identical domains in order for one page to access the Window.opener property of another. You can safely write external “tab-opening” _blank target links without rel="noopener" because the http response header policy will block external access to Window.opener.

Using reports for debugging

To collect statistics, you can use the Chrome reporting API for actions which take place against these security policies. It’s the same one Google uses. When a significant number of blocking events pile up triggered by your webpages, Google may notify you, as is the case when you are a Google Search Console user. Additionally, a Chrome specific Report-To page header field can be used to separately transmit data to your own repository.

It’s far easier, however, to simply check the boolean state of the crossOriginIsolated property of the experimental WindowWorkerGlobalScope API during development. That way, you get to handle these issues directly from within your development workflow.

if(crossOriginIsolated) {
  // Post SharedArrayBuffer
  console.log("CrossOriginIsolation: true")
} else {
  // Do something else
  console.log("CrossOriginIsolation: false")
}

Why we care

Given that failing security policies already trigger warnings for you in Lighthouse, Search Console, and with error messages in browser consoles, we need to understand details in order to offer our advice for what to do. When we’re involved in web development ourselves, then we want to have specific information prepared so that we can guide or conduct the implementation of a fix as part of our work.

For further technical information dives, check out SMX’s SEO for Developers Workshop, intended to provide a platform to discuss issues which can be unique to search engine optimization practitioners. In a live-code workshop environment, we demonstrate what SEO savvy web developers do in circumstances such as these. Information security plays an important role, as evidenced by SharedArrayBuffers, cookie policy changes, and many more such matters which are likely just out on the horizon.

Postscript. Google issued a clarification about this message on Friday, March 19th.



About The Author

Detlef Johnson
Detlef Johnson is the SEO for Developers Expert for Search Engine Land and SMX. He is also a member of the programming team for SMX events and writes the SEO for Developers series on Search Engine Land. Detlef is one of the original group of pioneering webmasters who established the professional SEO field more than 20 years ago. Since then he has worked for major search engine technology providers, managed programming and marketing teams for Chicago Tribune, and consulted for numerous entities including Fortune 500 companies. Detlef now works for Internet Marketing Ninjas lending a strong understanding of Technical SEO and a passion for Web programming to company reports and special services.

Related Topics

Channel: SEOGoogle: SecuritySEO for Developers

We're listening.

Have something to say about this article? Share it with us on Facebook, Twitter or our LinkedIn Group.

Get the daily newsletter search marketers rely on.

Processing...Please wait.

See terms.

ATTEND OUR EVENTS

Lorem ipsum doler this is promo text about SMX events.

Available On-Demand: SMX Create

May 18-19, 2021: SMX London

June 8-9, 2021: SMX Paris

June 15-16, 2021: SMX Advanced

June 21-22, 2021: SMX Advanced Europe

August 17, 2021: SMX Convert

November 9-10, 2021: SMX Next

December 14, 2021: SMX Code

Available On-Demand: SMX

Available On-Demand: SMX Report

×


Learn More About Our SMX Events

Discover actionable tactics that can help you overcome crucial marketing challenges. Our next conference will be held:

Next Event: Sept. 14-15, 2021

Available On-Demand: March 2021

Available On-Demand: October 2020

×

Attend MarTech - Click Here


Learn More About Our MarTech Events

White Papers

  • Gartner Magic Quadrant for Digital Experience Platforms
  • Selecting a Customer Data Platform For Your Organization: The 2020 Gartner Market Guide
  • The Complete Guide to Web Core Vitals
  • The New Era of Automation in SEO
  • Nielsen Annual Marketing Report: Era of Adaptation
See More Whitepapers

Webinars

  • Drive Customer Engagement with the Power of Personalization
  • 7 Use Cases That Prove Why You Should Implement DAM
  • Accelerate Your SEO & Content Marketing Program with 4 Key Milestones
See More Webinars

Research Reports

  • Local Marketing Solutions for Multi-Location Businesses
  • Enterprise Digital Asset Management Platforms
  • Identity Resolution Platforms
  • Customer Data Platforms
  • B2B Marketing Automation Platforms
  • Call Analytics Platforms
See More Research

Attend SMX For Only $199

h
Receive daily search news and analysis.

Channels

  • SEO
  • SEM
  • Local
  • Retail
  • Google
  • Bing
  • Social

Our Events

  • SMX
  • MarTech

Resources

  • White Papers
  • Research
  • Webinars

About

  • About Us
  • Contact
  • Privacy
  • Marketing Opportunities
  • Staff

Follow Us

  • Facebook
  • Twitter
  • LinkedIn
  • Newsletters
  • RSS
  • Youtube

© 2021 Third Door Media, Inc. All rights reserved.

Your privacy means the world to us. We share your personal information only when you give us explicit permission to do so, and confirm we have your permission each time. Learn more by viewing our privacy policy.Ok