I'm trying to build a server with some security. Let's say I have a file list component and a image viewer that I don't have access to and which make constant requests to my server. I'd like to filter those somehow based on who is making the request.Is there any way to check server-side if the client that's making the request has authorization while still having the server in a RESTful state and by not modifying the requests themselves?
Related
i'm working on an electron js app & i need to connect it to an API
knowing that the source code of an electron-js app is visible it's a huge security risk to leave the API key there !
how can i solve this problem ?
Instead of having the electron app (whether from the page or from the main process) make a request to the API directly, you can have it make a request to your own server instead - then, your server can make the request to the API, so that the key is only visible to your server, and isn't exposed publicly anywhere.
This will also let you gate requests from clients - if, for example, the credentials a client sends don't match what you need, or if they make too many requests in too short a time, you can cut them off.
You can't. If API key is shared, it's probably designed to be used in the backend.
The solution for that is to create a backend API for proxying API calls. Such proxying API should utilize authentication, so each user must send individual credentials.
How about obfuscate it using a utility like js-beautify.
I have an application. My application has 3 layers.
Front-end (contains front end design and functions)
Back-end 1 (layer 2 - this is the back end server that get data form front-end layer and gives to back-end 2 that contains database operations. this layer is just a transporter)
Back-end 3 is another back-end that triggers database operations by data that gets from layer 2.
When a XHR request send from front-end, it goes to layer 2, in layer 2 in Nodejs server, it will be add an API key and forward request to back-end 2 by special address. in back-end 2 it will check the API key first then trigger the operation.
Example:
1- form submited in front end to "/api/create_user"
2- in front-end 2 -> request handled "/api/create_user" get the request and
send to "/api/create_user_dkfjhierhgeirhuggridrfjkndf/APIKEY"
3- in back-end 2 -> it check the the request address and APIKEY then trigger
the request.
The problem is somebody has sent some request by an application they made out of my application.
My question is how can I check requests in layer 2 and make sure this request has been came from our front-end not out of our application?
So... you have an API on the internet, and a web application that uses the API.
Somebody took a look at your application, figured out what your API calls are (reverse engineered), and they wrote their own front end.
If your application is a website, there are some things you can enforce. CORS is one. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
With CORS, the web browser loads the webpage and sees a javascript xhr request. The web browser first ask the web server if the web page has permission to access the web server.
This relies on the web browser enforcing the access. If your adversary is using an app like curl, there isn't much you can do.
The most common mitigation is to require user registration and users need to login. Even this can be gamed, but now the adversary needs to duplicate your login flow, and grab the login credentials.
The final mitigation I'm aware of - You can continue to make it difficult for the adversary to get your pages. You can set a random cookie and verify that cookie for each request. You can set a secret code in the HTML, and pass that with your XHR request (like set it in a header) and verify it exists. You can change your API names, even make them randomly different every day. All these take time for the adversary to figure out, and until they figure it out, they are offline. If it's offline often enough, they might give up.
I'm developing a web app with React and an GraphQL API with Node.js / Express. I would like to make the API more secure so that its harder for API requests that don't come from the web app on the browser to get data. I know how to do it with registered users. But how to make the non-registered user still be able to access some basic data needed for the app?
Is it possible to put some kind of key in the web app - so the API call can't be replicated for others through sniffing the network dev tool in browser and replicating in Postman? Does SSL/TLS also secure requests in that browser tool? Or use like a "standard" user for non-registered visitors?
Its a serverside web app with next.js
I know theres no 100% secure api but maybe its possible to make it harder for unauthorized access.
Edit:
I'm not sure if this is a problem about CSRF because Its not about accessing user data or changing data through malicious websites etc. But its about other people trying to use the website data (all GET requests to API) and can easily build there own web app on top of my api. So no one can easily query my api through simple Postman requests.
The quick answer is no you can't.
If you trying to prevent what can be describe as legit users form accessing your api you can't really do it. they can always fake the same logic and hit your webpage first before abusing the api. if this is what your trying to prevent your best bet is to add rate limiting to the api to prevent a single user from making too many request to your api (I'm the author of ralphi and
express-rate-limit is very popular).
But if you are actually trying to prevent another site form leaching of you and serving content to their users it is actually easier to solve.
Most browsers send Referrer header with the request you can check this header and see that requests are actually coming from users on your own site (this technique is called Leech Protection).
Leaching site can try and proxy request to your api but since they all going to come from the same IP they will hit your rate limiting and he can only serve a few users before being blocked.
One thing the Leecher site can do is try to cache your api so he wont have to make so many requests. if this is a possible case you are back to square one and you might need to manually block his IP once you notice such abuse. I would also check if it's legal cause he might be breaking the law.
Another option similar to Referrer is to use samesite cookies. they will only sent if the request is coming directly from your site. they are probably more reliable than the Referrer but not all browsers actually respect them.
Suppose I have an client/server application working over HTTP. The server provides a RESTy API and client calls the server over HTTP using regular HTTP GET requests.
The server requires no authentication. Anyone on the Internet can send a GET HTTP request to my server. It's Ok. I just wonder how I can distinguish between the requests from my client and other requests from the Internet.
Suppose my client sent a request X. A user recorded this request (including the agent, headers, cookies, etc.) and send it again with wget for example. I would like to distinguish between these two requests in the server-side.
There is no exact solution rather then authentication. On the other hand, you do not need to implement username & password authentication for this basic requirement. You could simply identify a random string for your "client" and send it to api over custom http header variable like ;
GET /api/ HTTP/1.1
Host: www.backend.com
My-Custom-Token-Dude: a717sfa618e89a7a7d17dgasad
...
You could distinguish the requests by this custom header variable and it's values existence and validity. But I'm saying "Security through obscurity" is not a solution.
You cannot know for sure if it is your application or not. Anything in the request can be made up.
But, you can make sure that nobody is using your application inadvertently. For example somebody may create a javascript application and point to your REST API. The browser sends the Origin header (draft) indicating in which application was the request generated. You can use this header to filter calls from applications that are not yours.
However, that somebody may use his own web server as proxy to your application, allowing him then to craft HTTP requests with more detail. In this case, at some point you would be able of pin point his IP address and block it.
But the best solution would be to put some degree of authorization. For example, the UI part can ask for authentication via login/password, or just a captcha to ensure the caller is a person, then generate a token and associate that token with the use session. From that point the calls to the API have to provide such token, otherwise you must reject them.
For my current side project, which is a modular web management system (which could contain modules for database management, cms, project management, resource management, time tracking, etc…), I want to expose the entire system as a RESTful API as I think that will make the system as more usable. The system itself is going to be coded in ASP.MET MVC3 however if I make all the data/actions available through a RESTful API, that should make the system very easy to use with PHP, Ruby, Python, etc… (they could even make there own interface to manage certain data if they wanted).
However, the one thing that seems hard to do easily (from the user's using the RESTful API point of view) with a RESTful API is security with ajax functionality. If I wanted something that was complex to setup and use, I would just create SOAP services but the whole drive for using a RESTful API is that it is very easy. The most common way of securing a RESTful API with with a key that is associated with a user. This works fine when all the calls are done on the server side however once you start doing ajax functionality, that changes. I would want the RESTful API to be able to be called directly from javascript however anyone who are firebug would easily be able to access the key the user is using allow that person access to the system. Is there a better way the secure a RESTful API where it does not make the user of the RESTful API do complex things just to set it up?
For one thing, you can't prevent the user of your API to not expose his key.
But, if you are writing a client for your API, I would suggest using your server side to do any requests to the API, while your HTML pages provide the data from the user. If you absolutely must use Javascript to make calls to the API and you still have a server side that populates the page in question, then you can obscure the actual key via a one-way digest algorithm in a timestamp-dependant way, while generating the page, and make it that your api checks that digest in a time-dependant way too.
Also, I'd suggest that you take a look into OAuth Nonces and timestamps a bit more deeply. Twitter and other API providers obviously have this problem too, so they must be doing something with the Nonce values.
It is possible to make some signature in request from javascript. But I'm hot sure, how 'RESTfull' urls would be with this extra info. And there you have the same problem: anyone who can see your making-signature-algorithm can make his own signature, witch you server will accept as well.
SSL stands for secure socket layer. It is crucial for security in REST API design. This will secure your API and make it less vulnerable to malicious attacks.
Other security measures you should take into consideration include: making the communication between server and client private and ensuring that anyone consuming the API doesn’t get more than what they request.
SSL certificates are not hard to load to a server and are available for free mostly during the first year. They are not expensive to buy in cases where they are not available for free.
The clear difference between the URL of a REST API that runs over SSL and the one which does not is the “s” in HTTP:
https :// mysite.com/posts runs on SSL.
http :// mysite.com/posts does not run on SSL.