December 3, 2021

SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs

SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs

, SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs

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

Share This :
, SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs
, SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs

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). As pressure mounts surrounding security concerns that affect new features, webmasters have a growing list of options from browser makers, including those for “cross-origin” resources to help prevent information leaks.

Security measures

You may already be familiar with rel="noopener" , a way to make sure hypertext links and form elements with outbound actions, like links which open another site in a new browser tab, don’t allow an external page access to an internal page via the 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. Browser makers want to provide sophisticated security settings for webmasters so we can lock down and “allow-list” domains that can use, for example, the Window.opener property to prevent exactly such attacks.

You may have seen references to the Cross-Origin-Resource-Sharing (CORS) http response header field. 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 to turn off a browser feature altogether. That’s what’s happened with SharedArrayBuffers when browser makers punted it to tackle issues down the road. After a proof of concept demonstrated a “side-channel” vulnerability within 6 months of its 2017 debut, SharedArrayBuffers got sidelined in 2018 until just recently, in January 2021.

In a nutshell, a race condition attack allowed unwarranted access to a private memory cache in vulnerable CPUs (Spectre), which in turn allows theoretical access by one malware page to other pages that a user may have open in another browser (session) context. Information leaking from that sort of attack can constitute highly sensitive, personally identifying information that can expose one to identity theft, and potentially enable targeted attacks against organizations, including government systems.

Google’s Android Chrome 88 and desktop Chrome 91, plus Firefox 79+, all implement SharedArrayBuffers again after they decided a new security policy setting mitigates the danger from third-party access to private memory. Access to shared memory is blocked for all resources not specifically on an allow list following protocol as outlined in new http response directives.

Silent failures

APIs such as WebGLRenderingContext implement the feature, which was failing silently during the interim blackout period. Implementations which previously went unnoticed, where developers are unaware of and are missing the new security settings, are suddenly getting notices in Google Search Console as reports of failure are starting to pile up.

Implementing the new security policy

It has long been a best practice to establish a security policy with CORS as a perimeter around only the third-party resources that you intend to use. Without a security policy in place, third-party resources cause enough havoc already, let alone potentially leak your secrets. You want to allow-list resources that fail using a “distrust by default” security policy. Only working intentionally from failures (blocked scripts) would you want to add to your allow-list to limit risk.

The settings should be configured using your entry point page’s http response headers. When you manage your own web server, you can edit page headers using configuration settings in the framework or technology stack which powers your website. Alternatively, 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.

Cross-origin isolation

The security environment where you lock down access, while allowing the new implementation of SharedArrayBuffers, is called cross-origin isolation. To configure Cross-Origin Isolation, 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-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Google uses the open source Chrome reporting API to collect actions which take place against these security policies. When a significant number pile up, they might try and find a way to notify you such as appears to be the case when you are a Google Search Console user.

A Chrome specific Report-To page header field can be used to transmit data to your own repository, although it’s far easier 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 security policy best practice failures already trigger warnings in Lighthouse and error messages in browser consoles, and in this case the Google’s Search Console service, we need to understand the details in order to offer our advice for what to do. If we’re involved in web development, then we want to have specific information prepared so that we can guide or conduct the implementation of a fix as part of our job.

For more information like this, check out SMX’s SEO for Developers Workshop, intended to provide us a platform to discuss technical issues we face which can be unique to search engine optimization practitioners. In a live-code workshop environment, we often demonstrate what SEO savvy web developers do when facing these issues, and more. Information security is important, as evidenced by SharedArrayBuffers , cookie policy changes, and many more such matters are likely on the horizon.

About The Author

, SEO, Wordpress Support & Insurance, Mortgage, Loans, Legal, Etc Blogs
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 as a ninja for Internet Marketing Ninjas lending a strong understanding of Technical SEO and a passion for Web programming to company reports and special services.
Share This :