Is there a way to not expose api routes?

[visakadivines]

I noticed that in my production deployment if I navigate to an api route (for instance /api/user) I get back a JSON object with user information. I want to be able to call this route to fetch user information but I don’t want users to be able to navigate to the url directly either on accident or on purpose. Is there anyway to not expose the api routes and only allow the hook to access it?

[brianlovin]

The server should guard against unauthorized access accordingly. You could do this by sending headers or cookies from client side requests, but even with those protections you'd still want the server to validate the sender so that people can't spoof headers or cookies.

Usually this is done by encrypting specific information about the user, like an id into the cookie or header token, so that the server can determine if the request should have access to the user data.

[visakadivines]

So right now I handle authentication using passport, next-connect and express-session. Once the user is authenticated I use swr to fetch the user information, and basically change the login button text to the users first name. When the user isn’t logged in /api/user returns {user: null}. I guess I’m not understanding what’s preventing users from just typing in for example localhost:3000/api/user and accessing that user information directly. I guess how would you prevent users from accessing the route while still allowing the server to call it to fetch the logged in users information? I apologize if I’m missing something trivial here.

[brianlovin]

I think these are good questions. I'm not going to know everything here, but one idea:

• You could guard against the request type (POST, GET, etc) and, for example, return 500s or a redirect for GET requests (e.g. the user is trying to visit your api route directly in the browser)

I guess I’m not understanding what’s preventing users from just typing in for example localhost:3000/api/user and accessing that user information directly.

If the user doesn't have the correct authorization headers or cookies when visiting the route, then they wouldn't be able to access user info. Express typically handles this by adding middleware to extract / fetch user info from the request object, and decide whether or not to reject the request or let it flow through to your business logic.

[visakadivines]

Thank you for the suggestion, I’ll try it out. I think this approach will work for preventing users from typing in the /api/user route in the browser. The one problem I foresee is that I’m authenticating using providers and not implementing local strategy. According to the passport docs it looks like you have to make a GET request for the redirect, so I’m not sure if I can prevent users from typing in the auth routes into the browser using this method.

[brianlovin]

In that case, you could look for headers or a cookie to determine how to handle the GET. Good luck!