Homework 4 Reflection

Authorization

A big part of the struggle that I had when I was setting up authorization for the backend was only in the theorizing phase. In this situation, I really should've just written code before thinking it out. I wasn't sure how I was going to have a hidden session token that was maintained by the browser and invisible to the front end, but when I read articles on how cookies work and recalled the latest activity we did in class, it all made sense.

I didn't struggle with authorization on the frontend. I just relied on a cookie ('username') being set on the front end. If this cookie wasn't set, the user would be immediately redirected to the home page. If they tried to brute force the cookie into their browser, that was ok, because the backend would immediately check if the request had a logged in session ID and reject the rest of the request if there wasn't one.

Deployment

I experienced two major issues when deploying my app to the Internet. The first one was that I couldn't get subdomain names to work. That was just me forgetting how the internet worked; it was resolved by adding A/AAAA records for the subdomain. The other one was trying to get Caddy to serve my react files. I learned about the SPA fallback that I had to add to my reverse proxy to prevent the server from attempting to send index.html files from routes that didn't have anything, given that this application is an SPA. I would say that problem alone took me about 3 hours to solve.

Security Audit

My app shouldn't be subject to XSS attacks in most cases since it leans on React components that do not parse user input in the basic way that normal HTML elements would. This inherently sanitizes input for me.

My app shouldn't be vulnerable to CSRF because destructive operations are blocked by private user tokens stored in their cookies. Every client-server interaction is protected by HTTPS. "SameSite" is set to "Lax", which means post requests can't be sent from other sites, preventing most data destructive behavior. Furthermore, I used bcrypt to generate a session ID that is hidden in an "HttpOnly: true" cookie, which prevents the frontend javascript from accessing the token. This means session IDs are hard to obtain and even harder to guess programmatically.

I added rate limiting from the application side. I used the sample rate limiting from "express-rate-limit" which allows 100 requests every 15 minutes. That seemed good enough to me.

I used Helmet to set HTTP headers. The most important header is mentioned in the assignment description, Content Security Policy (CSP), which contributes to the prevention of XSS. This prevents index.html or other browser rendering from executing JavaScript resources that did not come from the same origin as the website itself.

Other than what was instructed, I didn't do anything else to secure my app.