Consuming external data using CORS Preflight Requests

When integrating external APIs, whether developed by Modyo, a user, or a third-party, we must take into account the cross-origin resource sharing or more commonly called CORS.

CORS

In summary, CORS is a standard for Cross-Origin Resource Exchange and is responsible for creating mechanisms to secure APIs from attacks from unsecure sources. At the same time, it enables the Response resource to the Javascript of the frontend. Here is another link with a post I wrote on this subject. 

Preflight Request

For the most part, they are automatic requests performed by the browser using the OPTIONS method. They are performed automatically when the browser detects a series of patterns and needs to validate a request using a preflight request to the server.

A web developer can also make a request that includes a preflight request. The OPTIONS method can also guide us to understand what will happen or inform us of possible integration problems by reading the response headers of this request, which are:

Access-Control-Allow-Credentials

This header returns a boolean that informs us if credentials can be sent in the actual request.

Access-Control-Allow-Methods

They are the methods accepted by the requested endpoint.

Access-Control-Allow-Headers

They are the headers accepted by the requested endpoint.

This image shows the flowchart when performing a cross-domain XHR call.

Now let's talk about important headers in the service request. When we make a request we not only send the data that we inject in the Axios or jQuery request, we also send headers that the browser adds to these requests.

Origin

Indicates the origin from where the query is being made and only contemplates the URI, that is, it does not include the path from which the call is made. More Information

Access-Control-Request-Method and Access-Control-Request-Headers

When a request is made that requires a preflight request these headers are added to the automatically requested OPTIONS method to validate that the headers can go in the method to be called Access-Control-Request-Method announces the method to be called, Access-Control-Request-Headers announces the additional headers that will go in the final request.

Now let's talk about important headers in the service response. When we receive the response from a service, the browser uses a lot of headers to give permissions to the front end what to use and what not to use. We have several important headers in this section; most of them are available in Mozilla documentation but let's focus on the important ones for integration:

Access-Control-Allow-Origin

This header defines from where the api can be consulted, that is to say, when we send the request automatically this defines an origin in the headers and if this origin is accepted by the api this must in the response return the same origin or in its defect a wildcard *, the origin is unique in the response that is to say it is not accepted to receive a list of origins, the api must be in charge to return the same one from which it was consulted or a * to inform that the API is public and can be consulted from any origin. More information

Access-Control-Expose-Headers

This header allows us to give access to custom headers, ie: the frontend Javascript could not access non-standard headers that are not defined in a list in this response header, like the previous one could have a * to say that all can be accessed but in this case, you can also define a list of headers separated by comma to say which specifically can be accessed by the frontend. More Information

Access-Control-Max-Age

This header indicates when I should request the verification or preflight request of this API again and defines in seconds this delta. More information

Conclusion

By combining all these headers and configurations, we can tailor with the highest degree of granularity our documents to unlock the potential of CORS and Preflight requests.

Photo by Alina Grubnyak on Unsplash.