I have a confusion and it is killing be inside. When we work with website that uses react in frontend and Django in backend, what we do is create APIs in django, and then calls the APIs endpoints in our react app to get data. Then populate our frontend with the response data.
But my question is, the API can be used by anybody, if he inspects the source code using dev tool. Because, the APIs are accessible by our react app without any authentication. And it should be so. Because, when someone first enters our web site without any authentication credentials, we need to render our first web page (homepage) and API should also be accessible there.
But the same way, a hacker can make a lots of request on that server endpoint and thus effect our server, maybe make our server down.
The First page of our site is authentication free. Homepage. Homepage is basically not logged in required. So New people try to access it. Its normal. The thing that is not normal is, if someone tries to access that endpoint outside of the browser. We should make sure the request is coming from client browser.
Please help me clear my confusions.
I tried reading many articles. They are telling about jwt, but it is about authentication, and first request gives token, only based of username and password!
This is a broad topic, and the problem you outline is very common, every public server has to consider this, I'll give a very brief summary of what I believe are good ways to approach this.
You can check user agent to see if the request came from a browser or not but it's likely a waste of time, user agent is set by the client and can be set as they want. I don't really recommend this, anything you do with user agent should generally be seen as optional and probably in an attempt to make the user experience better, in collaboration, so to speak, with the user. Someone trying to spam a service will most likely change their user agent if they want. So the return on time spent is probably quite low. But if you want to have a look, here's a list of user agents https://gist.github.com/pzb/b4b6f57144aea7827ae4.
What you most likely want to do is set up rate limiting. Cloudflare is a popular choice, I don't know that much about different services, but seems a common one people like https://www.cloudflare.com/learning/bots/what-is-rate-limiting/.
The important thing is, it does not matter whether the request comes from a browser or not, most the time rate limiting works on ip address so it does a good job at blocking excessive requests from one ip. Then of course, someone committed to exploiting a service can have access to multiple ips and circumvent basic rate limiting, and then begins the usual arms race between strategies to exploit services, and those to protect, you have distributed denial of service, and protection against it https://www.cloudflare.com/ddos/.
So it's a complex area, you don't have to either go to far into, just whatever you need for your situation, I think that' the most important, it's always good to know a bit more so if you ever need to take more important precautions you know what to do, so can read up on rate limiting. There's also other strategies but rate limiting seems a good start, you should easily be able to find information on protecting the server from various things you don't want here's another link from cloudflare https://www.cloudflare.com/learning/ddos/how-to-prevent-ddos-attacks/#:~:text=DDoS%20prevention%20methods&text=Several%20methods%20for%20reducing%20this,ports%2C%20protocols%2C%20and%20applications. And generally you can look up protecting public facing web services.
As to whether or not you should implement some form of protection, and what you implement, it depends entirely on the situation. I would look at; is your service likely to be specifically targeted, in which case you might want to look into rate limiting etc. Is it maybe just going to have some bots making requests casually as they find the service, maybe a few requests, doesn't really matter.
Then its important to consider what the consequences of any event are, what service are you running, what impact and on who, is it a personal service you can restart, like hobby stuff, a startup, a company with a lot of users and eventually contractual uptimes.. etc. Also hosting, if its self hosted on fixed resources, then you may have to restart. Is it hosted on some service, is the pricing fixed, could you have unexpected bills for massive amounts because your service is getting called so much.
If the consequences of the service getting spammed/attacked are important, then its important to take more precautions. As for the rate limiting leaving the service accessible, yes it does, but you need the service accessible, you limit the potential of misuse. Another option is a captcha if you want to have more likely requests from just users.