🔐 I Protect My Information! Why You Should Use Sessions Instead of URL Parameters (IDOR Vulnerability)

Hello, developers! Today, I’d like to talk about a security vulnerability that is very commonly found in web applications, but can become uncontrollable once exploited, and its solution. 👨‍💻

Imagine you recently found the following modification during a code review.

// Before 👎
// const { userId } = req.params;

// After 👍
const { userId } = req.session;

Just one line of change. But this small difference could save your service from hell. If you want a clear answer to the question, “Why is this safer?”, please pay close attention to this article until the end! 🚀

---

🤔 The Start of the Problem: Getting User ID from the URL?

First, let’s look at the problematic existing code.

// Insecure method
const {
    userId
} = req.params;

allocationsDAO.getByUserIdAndThreshold(userId, threshold, (err, allocations) => {
    // ... Query data by user ID and display results
});

This code directly retrieves and uses the userId from the value included in the URL path (req.params). For example, if a user accesses , the server recognizes the userId as ‘user123’ and queries the data for that user.

It looks like there’s no problem at first glance, right? But a very scary trap is hidden here.

Let’s assume I am a malicious user ‘hacker’ and my ID is ‘user456’. I would have accessed to view my allocation information. But then a thought suddenly occurs to me.

“Huh? If I just change the ID at the end of the URL, couldn’t I see other people’s information?”

So, I type into the address bar and press Enter. If the server doesn’t perform any authorization checks… horrifyingly, ‘user123”s information will be displayed right before my eyes! 😱

This is precisely the Insecure Direct Object Reference (IDOR) vulnerability, which frequently appears in the OWASP Top 10. It’s like being able to freely open someone else’s apartment door just by knowing their building and unit number.

---

✨ The Perfect Solution: Trustworthy Information Resides in the ‘Session’!

So, how did the provided modified code solve this problem?

// Fix for A4 Insecure DOR -  take user id from session instead of from URL param
const { userId } = req.session;

allocationsDAO.getByUserIdAndThreshold(userId, threshold, (err, allocations) => {
    // ... Query data by user ID and display results
});

The answer is to use req.session!

• req.params (URL Parameters): This is a value that users can manipulate in the browser’s address bar at any time. It is an external input that should never be trusted.
• req.session (Session): This is information stored and guaranteed by the server internally when a user successfully logs in, stating “This user is an authenticated OOO.” Users cannot directly modify this session information. It’s like a non-forgeable ID card issued by the government.

The new code doesn’t care what’s written in the URL. Instead, it retrieves the userId from the session information of the currently logged-in user, which is stored on the server.

Therefore, even if I, logged in as ‘user456’, cleverly change the URL to …/allocations/user123 and send a request, the server will operate as follows.

1. “Oh, user ‘user456’ sent a request.” (Session check via cookie)
2. “The code says to use req.session.userId, so I should assign ‘user456’ to the userId variable.”
3. “Consequently, I should query and display ‘user456”s data.”

Ultimately, I will never be able to see other people’s information, only my own. The IDOR vulnerability is perfectly defended! 🛡️

---

🎯 Conclusion: Is Your Code Secure?

The answer to the code changes we looked at today is clear.

Yes, modifying the code to retrieve the user identifier from the session (req.session) instead of URL parameters (req.params) is a very correct and crucial step that significantly enhances security. 👍

This small change is a critical step in correctly implementing authorization for user data access. Always remember: “All input from users is a potential threat.” Especially when verifying user identity and controlling permissions, never trust values that users can manipulate; instead, use reliable information (session) controlled by the server.

Check your code right now. Are you perhaps using URL values directly when querying important data? 😉

Tags: Security, Web Security, Nodejs, Express, IDOR, Insecure Direct Object Reference, Session, Authentication, Authorization, Development, Coding