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 often leads 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, don’t allow Javascript access by an external page 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. The opener property enables attackers 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 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 shared memory, a more serious problem than URL switching.
In a nutshell, CPUs which are vulnerable to a timing flaw by virtue of Spectre allows access to a memory cache where SharedArrayBuffers store data. The timing flaw allows a malware wrought page to race to access memory and all your other pages, not only those pages opened by following a link from one to another, but any page open in your browser.
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-corpNotice 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.
The post SharedArrayBuffer warnings in Search Console: Clarifying a new cross-origin isolation security policy appeared first on Search Engine Land.
Source: IAB