Avoid having to decipher CORS errors and head off Cookie-related security vulnerabilities with these 5 steps.

Why Cookies for Single Page Applications?

Cookies are an essential component of the user experience of any modern web application. This goes far beyond having to click “Accept” or “Reject All” cookies when visiting a new website. Without cookies, nearly every day-to-day action taken on a modern web action would be much more painful, if not infuriating.

• Want to refresh your browser without re-authenticating? Cookies make it possible.
• Want to allow users to open a new tab for your application without re-authenticating? Cookies make it possible.
• Want to have a user add something to their shopping cart and continue shopping for other items? Cookies make it possible.

Needless to say, cookies are an essential tool for delivering the type of experience your users have come to expect. Due to the de-coupled nature of Single Page Applications, there are a few tricky must-haves when implementing Cookies, which we discuss in this article.

What are cookies?

Cookies (and specifically, browser cookies) are pieces of data created and sent by a web server to a current user’s browser to be stored. They are used to maintain application states and store data necessary for smooth web experiences.

What is a Single Page Application (SPA)?

The textbook definition is that SPAs are web applications where web pages are rewritten dynamically with new data from the web server after one initial page is loaded from the server — hence where “Single Page” comes from. A more practical definition is an application with client-side Javascript running in a user’s browser that receives new data from an API server as needed.

Nearly all modern Javascript web development frameworks can be used to build single page web applications. Due to the fluid user experience that they deliver as well as their decoupling of frontend display code and backend server code, they are very popular and are found across countless super popular products (Gmail, Paypal, AirBnb, etc.).

5 Tips for using Cookies within Your SPA

Now that we have a shared foundational knowledge base, these are the essential tips for securing and successfully using Cookies within your SPA.

1. Client Side Code and API Server should share the same root domain

To prevent CORS errors from occurring when sending a request with cookies to and from your API from and to your client-side code, make sure that your client side address shares the same root domain as your API. A common paradigm is to have your web application hosted on

https://app.MYWEBAPP.com

and the API/Server hosted on

https://api.MYWEBAPP.com

2. Allow Cross Origin Resource Sharing (CORS) between the Client and API Server

Update your API’s CORS policy to allow requests from the web application. For good security reasons, the default is for web server frameworks to not allow requests from other domains (even CNAMEs of the same root domain). In order for your client to communicate with the server, however, the clients full URL must be allowed via the API’s CORS policy.

3. Prevent Man-in-the-Middle Attacks with secure = True

Not all cookies are baked the same. And there are ways to set our cookies up to make them more secure. By setting the “secure” parameter to True for our cookies, it means that the cookie can only be sent across HTTPS connections. This means the cookie is only sent and received in an encrypted manner, heading off man-in-the-middle attacks. Thankfully, the one exception is for when running on “http://localhost”, so local development environments are not affected by this specification.

4. Prevent Cross Site Scripting (XSS) with HttpOnly = True

Cross Site Scripting is when a malicious actor attempts to execute Javascript on your application. If information can be extracted from your cookies by Javascript in the browser, then authentication secrets are vulnerable to successful XSS attacks. By setting “HttpOnly = True” on a cookie, we prevent Javascript from accessing the cookie; it can now only be accessed through HTTP requests (e.g. http requests between your frontend code and the backend server.

5. Block Cross Site Request Forgery (CSRF) with SameSite = lax | strict

Cross Site Request Forgery is when a malicious actor forges a request, pretending to originate from your web application. “SameSite = lax” prevents a cookie from being attached to a request that does not originate from the site itself, or that is triggered from navigating to the site. When “SameSite = strict”, the request must originate from the site itself to include cookie information.

Conclusion

With these tips in mind, you should be able to have secure cookies that can be sent effectively between your web application client and the API server. Hopefully these suggestions help you avoid the inconvenience of deciphering CORS errors, and the business-critical pain of cookie information leakage.