Web pages do their magic by loading assets such as images, videos, fonts, text, and other resources from one or more servers on the internet. Most often, data for a website is stored on the same server where the webpages themselves are stored. Sometimes, though, websites will pull in data from servers located elsewhere on the internet.
Allowing websites to include data from other servers can pose possible security risks. To protect users, web browsers enforce security policies that allow scripts in one web page to access data in a second web page only if both web pages have the same origin (i.e. server). This prevents a malicious or faulty script on one page from obtaining access to data on another page that it shouldn’t.
There are many times, however, when one might want to load assets hosted on other servers across the internet. Resources such as fonts, videos, style sheets, images, and iframes are commonly loaded from other origins. It’s great to restrict access to content that might be unauthorized or dangerous, but the web developer needs to be able to specify when it’s okay to load a resource from a different origin.
That’s where CORS comes in.
What is CORS?
To enable web pages to load content that is stored in a different origin, W3C (World Wide Web Consortium), the international community that develops open standards to ensure the long-term growth of the Web, created the Cross-Origin Resource Sharing (CORS) mechanism that allows web pages to access data with a different origin.
The web page might be located on one origin, e.g.
http://origin-a.com
And some data the web page loads might be located on a different origin, e.g.
http://origin-b.com
CORS requires that the resource server explicitly declare that it’s OK to load the asset from a different origin. The browser accomplishes this by making a “preflight” request to ask the server whether it’s OK to make the cross-origin request. By default, servers will say “no” to preflight requests. Rules must be put into place to enable the server to reply to these preflight requests saying it’s OK to serve the asset to a different origin.
B2 Supports CORS for Cross Origin Resource Sharing
B2 is Backblaze’s general purpose cloud storage that can include any type of data that can be stored in the cloud. With pricing that’s ¼ of Amazon’s S3, web developers use B2 as an origin for web data, including text, numbers, scripts, fonts, images, stylesheets, iframes, and videos.
Backblaze supports the standard CORS mechanism that allows B2 customers to share the content of their buckets with web pages hosted in origins other than B2.
In keeping with CORS practices, B2 servers will say “no” to preflight requests to protect the unauthorized sharing of assets to other origins. Adding CORS rules to your bucket tells B2 which preflight requests to approve. CORS is a security feature that is in addition to normal B2 authorization mechanisms. Requests will still need to present normal B2 authorization tokens to download content from non-public buckets.
B2 Cloud Storage Buckets dialog
B2 CORS Rules settings dialog
Learn More about B2 and CORS
You can read all about B2’s support of CORS, and how to add rules to your B2 buckets to serve web assets cross-origin, on Backblaze’s website at CORS: Cross-Origin Resource Sharing.
