browser security sucks in deployment configuration...
Source: Dev.to
Deployment Challenges
I recently worked on a personal project that was almost finished on both the frontend and backend. When I started the deployment, I discovered that the frontend and backend were hosted on different domains. The deployment process taught me a lot, especially the pain of configuring separate domain servers to communicate with each other.
CORS and Cookie Issues
I already knew a little about CORS, so it wasn’t a huge problem, but browser security introduced many new hurdles. I ran into issues with:
- Sharing cookies across domains
- Configuring the
SameSiteattribute correctly - Dealing with third‑party cookie restrictions that prevented the frontend from reading API cookies
I spent many hours trying to understand what was happening.
Cookie Security Settings
During production I learned the importance of setting the Secure flag on cookies, which ensures they are only sent over HTTPS. This is something I had never considered before, but it became essential in a live environment.
SameSite Attribute
I also explored how the SameSite attribute works:
- Lax – allows cookies to be sent with top‑level navigation GET requests.
- Strict – restricts cookies to same‑site requests only.
- None – permits cross‑site cookie usage, but requires the
Secureflag.
Understanding how subdomains interact with SameSite helped me configure cookies more effectively.
Lessons Learned
Although the process was sometimes frustrating, fixing each issue gave me a small adrenaline rush after long debugging sessions. The experience deepened my understanding of CORS, cookie security, and overall browser security in production environments.