Hans Martin's website

Cross-origin requests with beakr

(updated: ) in Code, General.

In this article, we discuss using beakr to set a CORS header and create an example beakr instance that can respond to cross-origin javascript requests.

What is CORS?

Normally, sharing resources across various domains is restricted in modern browsers by a Same-Origin Policy. Why? SOP serves as a security mechanism as it permits scripts contained in a web page to access data from a web service only if they share the same domain (aka ‘origin’). Generally speaking, the SOP mechanism is good practice as it prevents malicious javascript code from making unauthorized requests.

You may be wondering how it is you are able to share images and/or data across websites. This is where CORS comes in. CORS stands for Cross-Origin Resource Sharing. As the name suggests, it allows web pages from one domain to make resource requests from another trusted domain. The default CORS policy allows web pages to directly embed cross-origin images, stylesheets, etc. However, the default policy limits javascript requests for web resources to resources coming from the same origin as the requesting web page. For example, if you build a web page with javascript code that tries to retrieve JSON data or images from a different domain, this will be prohibited unless the web server at that different domain specifically allows cross-origin requests.

But this is precisely what we can allow with breakr!

beakr + CORS = ❤️

Websites use HTTP to negotiate the exchange between client and server and to determine access permissions. When a web page uses javascript to request a resource from a server, the browser passes along information about the web page origin. In order for javascript to be able to use the response data, the server responding to the request must tell the browser “This request-origin can access my resource“. The browser remembers that and allows cross-origin resource sharing.

A web server allows programmatic (javascript) resource requests from another origin by overriding the default, highly restrictive CORS access policy. This is done by specifying Access-Control-Allow-Origin in the HTTP response header. In a beakr web application, the HTTP header is part of the built-in Response (res) object. Changes to the response header are made with the res$setHeader() method. That’s it.

An Example

The beakr instance below demonstrates how to allow cross-origin requests. This instance serves the mtcars dataset as a JSON object at the address We explicitly set the CORS policy to allow access from any (*) external server.

# Import the beakr library

# Create JSON data from the mtcars dataset
json <- jsonlite::toJSON(mtcars)

# Create the beakr instance
newBeakr() %>%

  # Respond to GET requests at the '/json_data' route
  httpGET("/json_data", function(req, res, err) {
    # Set the CORS access policy!
    res$setHeader("Access-Control-Allow-Origin", "*")
  }) %>% 

  # Set up a server on localhost port 8888
  listen(host = "", port = 8888)

Now it will be possible for another web page not served from our local host (known as “mtcars.org” to the outside world) to access this information programmatically with the following javascript snippet:

async function mtcarsJSON() {
  let url = 'mtcars.org:8888/json_data';
  try {
    let res = await fetch(url);
    return await res.json();
  catch (error) {

If our server didn’t explicitly allow CORS requests, the web browser javascript console would display one of the many CORS error messages after making the request.

The great thing about working with beakr is that it allows us to create a web service with fine-grained control over which URL routes have restrictive CORS policies and which ones are more open.

Best of luck creating cross-origin web services with beakr!