First, let's talk about IAM (Identity and Access Management) 🔐
It basically means signing up or logging into a platform (Authentication), maintaining the session (Session Management) for subsequent requests or activities, and doing this while keeping the user restricted to only the actions they are allowed to perform (Access Control).
🔑 Authentication
Authentication is the process where a user either signs up or logs into their account on your platform. If the user is signing up, you store their information in the database. If you are opting for password-based authentication, you store that password in the database after hashing it.
Now comes the later part—verifying the email ID, phone number, and other such necessary steps. After this, the process depends on what mode of authentication you've chosen. There are plenty of options, for instance:
- Cookie-based authentication 🍪
- Header-based authentication 📜
🕒 Session Management
After authentication, you've either got a cookie from the server or a token. One crucial aspect here is, if you chose cookie-based authentication, make sure to configure its options properly:
- Secure (Enables sending cookies only over HTTPS connections)
- HttpOnly (Prevents JavaScript from accessing cookies, a great prevention against XSS attacks)
- SameSite (Specifies whether to send cookies with cross-site requests)
- Domain (Defines which domain can access the cookie)
- Path (Specifies on which path the cookies are accessible)
So, session management ensures that for every subsequent request after authentication, you verify whether the user is logged in. You refer to the cookie or headers sent from the frontend and check if they are intact or expired. You can also use Redis to keep track of sessions efficiently. 🗄️
🚦 Access Control
Now that you've implemented a layer to verify whether a request is authenticated, the next step is to ensure that the user making the request has permission to perform the requested action.
Access control means restricting users to only those actions that they are allowed to perform.
This was a brief introduction to IAM. Of course, there's much more to explore—Access Control itself is a vast topic, but we'll save that for another time. 😉
⚠️ Horizontal Privilege Escalation
It's intuitive that a user can access their own data using their session. But what if, by some "holy magic," they manage to access another user's data? This is called Horizontal Privilege Escalation (HPE). 😱
Example 🔍
Consider a request where a user wants to access their own information:
https://api.some-random-server.com/user/123
Now, the user opens the network tab in their browser, analyzes the API request, and decides to do something sneaky 🌚. They copy their cookie or authorization header, go to Postman, and make this request:
https://api.some-random-server.com/user/124
If proper checks are missing, the user might actually fetch another user's data! That's some unholy business, but pretty cool from a hacker's perspective, right? 😆
A real-world example would be an e-commerce platform where users fetch their invoices:
https://this-is-ecommerce.com/orders/123456.pdf
If someone changes 123456 to 123457, they might fetch someone else's invoice. That's a serious security flaw. 😵💫
This is known as Insecure Direct Object Reference (IDOR), which we’ll discuss shortly.
🛡️ How to prevent HPE?
-
Use UUIDs instead of simple IDs: Using predictable IDs like
123456makes guessing easy. UUIDs add a layer of difficulty. - Perform a proper check at the code level: Ensure the user requesting the resource actually has permission.
- Securely manage sessions: Validate request origins, check user agents, and block suspicious requests (e.g., from Postman or cURL). 🚫
- There’s more, but these basics will get you started.
🔝 Vertical Privilege Escalation
Imagine an organization with roles like Admin, Manager, Employee. If an Employee gains access to another Employee's data, that's HPE. But what if the Employee accesses data meant for a Manager? That’s Vertical Privilege Escalation (VPE)! 🚀
🛡️ How to prevent VPE?
- Implement the Principle of Least Privilege (PoLP): Users should only have the permissions necessary for their tasks.
- Secure authentication channels: Ensure robust authentication to prevent unauthorized access to sensitive records.
📈 Horizontal to Vertical Privilege Escalation
Now, imagine a user (Employee) exploits an HPE vulnerability to fetch an Admin’s data, including their password. If they successfully log into the Admin account, they now have escalated their privileges both horizontally and vertically—this is Horizontal to Vertical Privilege Escalation. 😨
🔓 What is IDOR (Insecure Direct Object Reference)?
We saw an example where users could fetch another person’s invoice just by changing an ID in the URL. That’s IDOR—one of the most common web security issues. 🛑
🛡️ How to prevent IDOR?
- Implement proper authorization checks at the code level:
if (logged_in_user.id != resource.user.id) {
return null; // Or throw an "Unauthorized action" error
}
- Use UUIDs instead of predictable IDs.
- Implement granular access control: Restrict user access based on need.
- Use strong authentication measures: Verify JWT tokens, cookies, headers, or OAuth scopes before granting access.
This was just a basic guide to what a developer should keep in mind while implementing Authentication in their projects. 🚀
Thanks for reading! See you next time. 😊
Ajinkya ❤️
Top comments (5)
Share your thoughts, did you like it?
Next time we'll discuss access controls in great detail.
This is gold, Ajinkya! Developers often overlook IAM until it becomes a serious issue. The breakdown of HPE, VPE, and IDOR was really well explained very informative! Using UUIDs and proper authorization checks should be a standard practice. Security isn’t something to think about later, it needs to be built in from the start. Keep sharing such great content!
Glad you liked it, Suchit!
Great post! I was curious why NextAuth wasn't mentioned and noticed a few session security details might need more clarity. Thanks for sharing your insights!
Hey, thanks for the comment, actually this was a code/framework agnostic post. I'll be covering the remaining session security details in my upcoming posts :)