CS 478 HW 4: Reflection

The main challenge was ensuring that the "Edit" and "Delete" actions were restricted to the owner of the data. While simple authentication checks if a user is logged in, authorization requires checking the user_id on the specific book record against the session.user.id. Implementing this logic across all CRUD endpoints required careful attention to detail to ensure no data leaks occurred.

On the front end, the struggle was managing the UI state based on the user's permissions. I had to ensure that buttons for editing or deleting only appeared for the correct user when they were signed in. Additionally, handling protected routes by redirecting unauthenticated users back to the login page without creating an infinite redirect loop, took some trial and error with React Router.

The biggest hurdle when deploying to the internet was the Reverse Proxy configuration. Connecting a subdomain via Caddy to a Node.js server running on a local port required specific DNS "A Records" and a precise Caddyfile syntax. I also encountered a "Proxy Trust" error where the application couldn't verify the user's real IP address because Caddy was sitting in the middle.

My app is inherently resistant to many XSS attacks because I used React for the front end. React automatically escapes strings as it treats data as plain text rather than executable HTML/Script. On the back end, I implemented Helmet.js, which sets a Content-Security-Policy (CSP) header to restrict where scripts can be loaded from which further reduces risks.

To mitigate CSRF, I configured my session cookies with the SameSite: 'Lax' attribute. This ensures that the browser only sends the authentication cookie for requests originating from my own domain, preventing malicious third-party sites from forged requests on behalf of the user.

I added rate limiting directly to the application code using the express-rate-limit package. I applied this middleware specifically to the /login and /register routes to prevent brute-force attacks.

I implemented the Helmet middleware to automatically configure several essential security headers. These include Strict-Transport-Security (HSTS), which protects users by forcing the browser to communicate exclusively over HTTPS; X-Content-Type-Options, which prevents the browser from "sniffing" the MIME type and helps block certain types of file upload attacks; and X-Frame-Options, which prevents the site from being embedded in an iframe, providing a critical defense against clickjacking. These headers harden the application's security posture by enforcing browser-level protections.

I implemented app.set('trust proxy', 1); in Express. This was necessary because Caddy passes the user's real IP address in the X-Forwarded-For header. Telling Express to trust this proxy ensured that my rate limiter correctly identified individual users rather than blocking the entire server's local traffic.