5 Cookie Tips for Single Page Applications
5 Cookie Tips for Single Page Applications (SPA)
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)?
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
and the API/Server hosted on
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
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.
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.
dragondrop.cloud’s mission is to automate developer best practices while working with Infrastructure as Code. Our flagship product regularly scans and identifies resource changes that have occurred outside of a Terraform workflow (e.g. drift) so that dev teams can have a Cloud environment that is fully represented as code. All of our tools are self-hosted by our customers, with no data ever leaving their servers. To learn more, schedule a demo or get started today!
Learn More About Web Development
Running Remote DB Migrations via GitHub Actions
Motivation Database migrations are an essential component in the life cycle of any relational database. We needed a way to trigger database migrations in our development and production environments within our existing CI/CD pipelines running in GitHub Actions. We...
Complete Unit Testing of a Flask API
How can we create unit tests for our Flask API that test end-to-end endpoint functionality (authentication, database changes, and data formats)? We explore one possible solution.