Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Securing Express API

I'm writing a web app with a separate frontend and backend. The frontend is written in React, and the backend is a node.js server running an Express endpoint. How do I ensure that only my frontend can access the API, and not anyone else? My API URL is exposed in my frontend client side code, so anyone can see that.

I added JWT authentication to my API, but I still need to have an unprotected /login endpoint in order to generate the JWT token, and in order to login to generate the token, I must post both a username and password from my frontend, which other users can see, since it's done from the client side.

What is the proper way of securing an API that is hosted on a separate backend like this, so that only my frontend can access it, in a way where nobody can see what credentials are being used to access the endpoint?

like image 544
WhoopsBing Avatar asked Nov 15 '17 01:11

WhoopsBing


People also ask

How to secure APIs in the router using express request handler?

keycloak.protect () Express Request Handler can be used to secure APIs in the routers. Add the following line to test-controller.js to access Keycloak instance initiated in index.js This API should be accessible without any Authorization token with no restrictions. It already meets our requirements and needs no additional changes.

What happens after I issue a request to the express API?

For example, the screenshot below shows Insomnia after issuing a request to the Express API. No matter how you decide to issue the request, after receiving it, the application will delegate this request to the app.get('/', ...) endpoint. Then, as defined, the endpoint will send back to the client the following response (i.e., the ads array):

How to develop RESTful APIs with Express and nodeJS?

In this article, you learned about how easy it is to develop RESTful APIs with Express and Node.js. More specifically, you started by using npm to scaffold a brand new application. After that, you used Express to expose API endpoints to manipulate ads. Then, in the end, you learned how to secure your API with Auth0.

What are the security best practices for Express applications in production?

Security best practices for Express applications in production include: Express 2.x and 3.x are no longer maintained. Security and performance issues in these versions won’t be fixed. Do not use them!


1 Answers

You can't. Your API is on the internet. Anyone can access it. You can require an account and login credentials for the account before allowing access to the API, but once someone has an account and credentials, they can access the API from their own script rather than via your web page. This is how the web works. Not much you can do about it. And credentials being used by the client cannot be hidden. All data that is EVER on the client can be looked at by a hacker on the client. This is the way of the web.

Larger companies will typically monitor their API usage to look for inappropriate use. This includes rate limiting, detecting behaviors and sequences that are not typical of a regular human user. When they detect inappropriate use, they will often disable that action or ban the offending account, either temporarily or permanently. This is also why some pages use techniques to detect if an actual human is individually causing the operation such as reCaptcha. For example, on stack overflow, when editing comments or posts, I often run into rate limiting where it tells me that I have to wait a bit before it will accept my edit.

There is no absolutely secure way to store credentials in a client. The most common scheme for credentials is to require username and password (securely over https) and then when that is accepted on the server as legit credentials, some sort of token is issued to the client which can be used for future API calls. That token may be in a cookie or may need to be manually included with each subsequent API call (the advantage of a cookie when using APIs from a browser is that the cookie is automatically sent with each subsequent request).

If the token is a cookie, then the cookie is stored in the browser's cookie storage and an expiration can be set for it. The browser's cookie storage is protected from access by web pages from other sites, but can be accessed by someone on the local computer (it's stored in the file system).

If the token is not a cookie, just returned as a token, and the client wishes to store it, there are a few other places that Javascript provides access to in order to store it. Local storage has similar security as cookie storage. It is protected from access by other web sites, but can be accessed by a person on the local computer.

like image 142
jfriend00 Avatar answered Oct 09 '22 00:10

jfriend00