Check out a free preview of the full API Design in Node.js (using Express & Mongo) course:
The "Identifying Sensitive Routes" Lesson is part of the full, API Design in Node.js (using Express & Mongo) course featured in this preview video. Here's what you'd learn in this lesson:

Not all routes in an API should be publicly available. Scott goes through the post, category, and user modules to identify routes which require authentication. He also explains edge cases where a route should only be available to a single user versus all users.

Get Unlimited Access Now

Transcript from the "Identifying Sensitive Routes" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Scott Moss: So now if we go back and look at those other methods, like an auth.js, like decodeToken and verify user, or I'm sorry, decodeToken and getFreshUser, we're actually about to use these now. But we gotta think about like it's gonna go down to like what resources do we want to protect.

[00:00:25] So let's just go and look at them. Let's just go look at, let's go look at categories. Let's look at the category routes. Are there any routes in here that you think that you should be authenticated to access.
>> Speaker 2: [INAUDIBLE]
>> Scott Moss: You should definitely authenticate bit recruiter category, I agree.

[00:00:49] Anything else?
>> Speaker 2: Delete?
>> Scott Moss: Definitely should be authenticated to delete, sure.
>> Speaker 2: And probably put.
>> Scott Moss: Put a delete category? For sure.
>> Speaker 2: That's about it.
>> Scott Moss: Everybody else should be able get all the categories or get one category. Yeah, I agree. And then what about let's go to the postRoute.

[00:01:14] And then for this one. Same favor something different
>> Scott Moss: About the same, yeah it's about the same. Everybody should know that get one, and get all. But only all people should be able to update, delete, and create. And for users, there's some extra stuff going on here. So I'm gonna add it up.

[00:01:43]
>> Scott Moss: Yeah. By the way.
>> [NOISE].
>> Scott Moss: Yup, I did it. Right. And then for users, pull out this one.
>> Speaker 2: You probably don't want to get all your user.
>> Scott Moss: Probably don't want to get all the users.
>> Scott Moss: What about get one user? Like what if I want to see, what if I go to the blog, and there was a link in there that says look at all of our authors?

[00:02:13] All right, is that get all users? All right, so there may be a way, maybe you want to get all users but you don't want to show off the information User schema, like their passwords and stuff like that [LAUGH], right. Here's their password. What is this there?
>> Scott Moss: So maybe, post.

[00:02:37] So we should be able to create a user
>> Speaker 3: Anyone can create in here right?
>> Scott Moss: Yeah, in like, on a real blog no way, you'd have to be invited. Right, I have to like type in your email and be like you're invited to write on the blog, like Wordpress.

[00:02:55] But in our scenario yes, anybody can go to our website and sign up and start publishing. So yeah, anybody should be able to create. Whereas that was different with the post, only authenticator should be able to create. So that's why I wanna talk about it. What about updated user, who should be able to do that?

[00:03:14]
>> Speaker 4: Only that user?
>> Scott Moss: Only that user, so not only should you authenticate it, but you can only update yourself. All right, so that's different. But what about if I'm like, an admin and I wanna update your stuff.
>> Speaker 4: You go on to the database.
>> Scott Moss: [LAUGH] I got to hear it from the critic.

[00:03:30]
>> Speaker 4: We're not [INAUDIBLE]
>> Scott Moss: Okay. Okay. Yeah, we're not there. We don't have a role-based authentication schema anyway, so there is no admin. It's just we're both users anyway. So I don't have superpowers. But what about delete?
>> Scott Moss: Yeah. Think about that. It's deep. How do you authenticate it?

[00:03:53] Cause you'll probably do it yourself, for now. So I just want you to think about that stuff. Cause now you're gonna have to write the middleware. In the places that they need to be so this stuff works. All right. So if you go back to off.js, we have, the two middleware functions that we need are gonna be decode token and get fresh user.

[00:04:12] But I want you to remember something. The first thing, the order is very important here. There's decode token, it's simply like the first line of defense. It's job is to decode the token and it attached req.user or it'll attach whatever the object is at a decoded to that user which in this case because of sign this is an object with IDs on it.

[00:04:33] So that should be the first thing that we do. And then right after that before we get into the controller we should get the fresh user. And that's because if you go look at our controllers. Let's just take an example of user controller. It's expecting, but not get one.

[00:04:51] Because it's gonna ID from there. But let's see where is one [INAUDIBLE]. Not this one. Yeah. No, not this one. This is a bad post.
>> Scott Moss: Where? Yeah. Right here. So this one right here, because the posts has like an author feel. All right, it needs to know what author is creating it so we didn't do that on the front end, put the author's ID there we ought to do that here.

[00:05:29] And that would be fine because we know who the author is because it's req.user.autosquare.id. Cuz they're the only ones to create this post, so they create it and it's there.
>> Scott Moss: So params is a way to get the ID of the resource that's coming in. What I'm saying is GetFreshUser will just attach the user of the incoming request.

[00:05:53] It doesn't matter what we hit, if we use the GetFreshUser middleware, it will attach the decoded token, it will search the database for that user and attach the token to that user. Which can be helpful in most controller operations. Maybe you need access to the entire user to do things.

[00:06:10] It's very helpful. One place that is very helpful. Now that we're using JSON web tokens is that. Let me ask you this, how would I get myself? If all I had was JSON web token on the client how would I ask the server, hey give me my own user object.

[00:06:31] How would I do that? We know how to get one user object, and that's /api/users/id. I don't have the ID, all I have is the JSON web token. So how would I do it? Yes.
>> Speaker 4: Well if you decode the token it has an id.
>> Scott Moss: Where would you decode the token, on client?

[00:06:46]
>> Speaker 4: On the server, cuz that's where the secret is.
>> Scott Moss: Right, so like what, we don't have a request for that. Well I mean we don't have a controller for that, so that's what I'm saying. Like, what would you hit? What route would you hit to do that?

[00:07:02]
>> Scott Moss: Cuz if we do a get to that user, it will give you all the users. If I do a get/id that will give me the user with the id, but I don't have the id. So I can't do one of these.
>> Speaker 4: You would have to make a new route.

[00:07:13]
>> Scott Moss: I would have to make a new route. Exactly. What would that route do?
>> Speaker 4: Take the token.
>> Scott Moss: Right. That route would-
>> Speaker 4: Be like me, and then it take the-
>> Scott Moss: Exactly. You would make a slash me. Which is a common thing you'll see in my tokens.

[00:07:25] So they'll be like, api/user/me. And all that would do is just send rec.user back. That's all it would do, because it would already use this middleware, get fresh user, which already found the user before they went to that /me controller. So all me would just be like rec.json, rec.user.

[00:07:43] Or rec.json, rec.user.