Authentication: Back End
The biggest challenge when adding authorization to the back end was understanding where trust boundaries should exist. It was initially tempting to rely on front-end checks, such as hiding buttons when a user was not logged in, but I quickly realized that this provides no real security. All sensitive actions needed to be validated server-side regardless of how the UI behaved.
Implementing password hashing with Argon2 was another challenge.
I needed to understand that password hashes include metadata such as the algorithm, parameters, and salt,
and that passwords must be verified using argon2.verify rather than comparing hashes directly.
Debugging an invalid hash format helped reinforce how strict and security-critical proper password handling is.
Authentication: Front End
On the front end, the main challenge was keeping the UI synchronized with authentication state. Since authentication was cookie-based, the browser automatically sent credentials, but the UI still needed a reliable way to know whether a user was logged in. Adding a/api/auth/me endpoint and checking it on page load solved this problem.
Another challenge was implementing conditional rendering without treating it as a security mechanism. Edit and delete buttons are hidden for unauthorized users to improve usability, but the backend always performs the final authorization checks. This reinforced the distinction between user experience and actual security.
Adding a login/register toggle required careful state management to avoid duplicating logic or breaking existing authentication behavior.
Deployment
Deploying the application to the public internet revealed several issues that were not present in local development. Cookie behavior was one of the most significant challenges, especially withsecure and sameSite settings behaving differently in production.
Environment differences such as ports, URLs, and configuration values also required adjustment. Debugging deployment issues without access to local debugging tools encouraged better logging and more defensive error handling.
Security Audit
Cross-Site Scripting (XSS)
The application is not vulnerable to common XSS attacks because user input is never injected directly
into the DOM as raw HTML.
React automatically escapes values rendered in JSX, and the backend does not return user-supplied HTML.
As a result, no additional XSS mitigation libraries were required.
Cross-Site Request Forgery (CSRF)
Because the application uses cookie-based authentication, CSRF was a potential concern.
This risk was mitigated by using SameSite=Lax cookies,
restricting sensitive operations to non-idempotent HTTP methods,
and validating authentication tokens server-side.
Rate limiting
No firewall-based or application-level rate limiting was added.
However, the application could be extended using middleware such as
express-rate-limit to protect against brute-force login attempts.
Rate limiting was not required for the scope of this assignment.
HTTP security headers
Several important HTTP and cookie-related security mechanisms were used.
Authentication cookies are marked as HttpOnly to prevent access from JavaScript,
Secure in production to require HTTPS,
and SameSite=Lax to reduce CSRF risk.
These settings help protect authentication tokens without adding significant complexity.
Additional security measures
Additional security measures included performing authorization checks on all protected routes,
storing session tokens server-side,
and ensuring that ownership information is never accepted from the client.
These decisions ensure that all security-critical logic is enforced by the backend.