I’m building a React application with a Node backend. In the backend I have an API that just talks to a database and I can deploy the API and the React app at the same time.
Although this works fine, the API routes are not secure ,i.e, anyone can freely access myapp.com/api/getData. I would like only my React front end to be able to access these /API endpoints and I’m not sure what is the best way to do that.
To be clear, I don’t mean securing them so that only a logged in user can access them but basically preventing a user from going in their browser / Postman, typing in that URL and getting the data.
I know that a solution would be to have the API as a separate project, deployed separately and secure that with an API key for example but I like the convenience of having both deployed at the same time.
Is there a better way of doing this?
EDIT: I've ended up just moving the API to a separate project
Related
Like in order to connect(basically making request's) our React app to our backend server we have to use backend REST API, like logging in user, fetching data from the backend.
But wouldn't using REST API on the React components make API available to every user and any malicious mind could create chaos or make unnecessary requests to the server(like using Postman).
Is there any way to hide API keys, I've seen another answer to a similar question on 'How to hide API Keys' but there's not a clear answer, some saying to prepend API with REACT_APP_ in a dotenv file but some saying this is not safe, although I've tried prepending REACT_APP_ but still API is visible on the front end.
Is there a solution available to this problem?
Using a REST API from your react app does not expose those endpoints to the public. By virtue of that REST API existing, those endpoints are already exposed to the public and anyone in the public can use them. It's the servers job to make sure those endpoints are locked down and secure (requires authentication, etc), not the clients.
I'm trying to create an integration to OneDrive using the Microsoft Graph API. Our app is fully client-side, there's no moving parts on a server, so authentication has to be directly browser to Microsoft.
We have an existing integration with OneDrive that uses the older OneDrive API. That does permit client-flow authentication.
There is an example for AngularJS, but that turns out to require a NodeJS server and have a server-flow authentication, again. NodeJS authentication requires a secret to be passed over, which I obviously can't put in public JS.
I cannot find any examples of authenticating to the graph API without a secret, am I right in saying that client-flow authentication is not supported?
p.s. I have looked at Writing a simple microsoft graph client without using a web server, but this question seems to be asking whether it's possible to make API calls without user interaction, rather than what I'm asking.
If I understand your scenario correctly, you're looking for the implicit grant. I wrote a blog post on using this a while back that might also be helpful.
I have been learning angular 2 and have been doing research on how to protect data within my app.
How, if possible, can you obstruct data from the front end of the app? Is it possible to serve the angular app through a node server, say using Universal Angular, which would mean variable values can be hidden from the user on the front end.
I am essentially looking for the solution of hiding private keys which will give the app access to various APIs/creating auth headers/paths. I've read a solution is to have an API bridge for the app - so I would connect to that to retrieve the data/keys - but then how do I protect that from access? Since that endpoint would then be exposed and could be abused, or if getting keys the response is visible. The idea of locking down to domain I have read is unreliable due to spoofing and locking to IP wouldn't work as its front end or through an app?
I feel there is a glaringly obvious answer that I am missing something.
You must assume that everything that is held in your frontend is visible to anybody that can access your frontend.
All JS variables, storage (local, session), network requests, etc. in your front end are unsecured from users of your frontend.
You can (and should) use SSL to make hide data from anybody in between your server and the browser, but there is just no way to secure data held in your frontend from users of your frontend. (At least if your frontend is available on "regular" browser as opposed to some tightened kiosk mode installations.)
It's simple, when the server sends the data as response to a request, then the data can be accessed from the outside.
If you don't want that, then don't send the data.
You didn't mention what problem you actually try to solve. For API keys you can for example do the request to the API on the server and provide an API on your own server for your clients and then make the server forward the requests to the actual API server.
Hey everyone so I have a question, can I have an endpoint api in my Mobile application?
For example I have a server that would do stuff with data and then I would send a post request to my mobile application letting it know new data had came in. How would I go about that? Is that even possible?
My solution I came across was to use firebase api since I remember It has a watcher. So I can easily change some data inside the firebase database by using my server. The mobile application will have the firebase watcher and see that something in the FB database got changed and it will proceed to react to it.
Without using firebase. If I were to send a get request to my server from my mobile application every second(as a watcher) is that bad practice? Or is that pretty much what firebase's watcher is doing?
I know that when you deploy a web application you can have a backend inside the directory. Would mobile applications even allow that?
Is there a simpler way?
also note
I'm using Ionic framework so its a javascript framework
And I'm using nodejs/express as my server
If I were to send a get request to my server from my mobile
application every second(as a watcher) is that bad practice? Or is
that pretty much what firebase's watcher is doing?
This is a bad practice and that is not what it is doing.
I know that when you deploy a web application you can have a backend
inside the directory. Would mobile applications even allow that?
You can't have easily a backend in your mobile application. You can call it but not having one inside your application.
Using Firebase is the good practise.
If you want to create your own server, you can create also a firebase cloud messaging server.
What you are doing is called push notifications. More infos here : https://stackoverflow.com/tags/push-notification/info
I'm trying to build my first API to be consumed by a mobile application built with Ionic.
Before starting I'm looking into the architecture and I can not understand exactly how to make secure my API routes.
Let's say I have an endpoint like http://myapi/v1/get-items and my application doesn't need an user to be authenticated to view those items in the mobile app.
How should I protect that route from external queries, using Postman for example?
I wish that route to be not accessible unless is not requested by the application.
Looking on Google I can find many solution using basic authentication but all of those require an user to log in... What if my app doesn't have users to log in?
I'm a bit confused but I think there is a solution and I don't know it yet...
I hope you can help me to understand it.
EDIT:
My Question is totally different from the following: How to implement a secure REST API with node.js
I'm looking for solution that DO NOT require a User Authentication.
If you don't want to use User Auth through something like Passport then you can institute a whitelist in your Node API instead. express-ipfilter is an express middleware module that allows you to filter requests based on the request IP.
Requiring a login would be the cleanest and safest way to make sure your api remains private. However, if you want to keep external users out of your services without requiring a login, you will need to "sign" your requests. By that I mean doing something like encrypting a current timestamp on the client using a key known to both the server and the client app, adding that encrypted string as a header, receiving that header in your server, decrypting it and checking that it's not too old of a timestamp before you return a response.
It's not really safe (if someone can see the code they can see the encryption key) but it's an obstacle and it down't require logging in. See this for an example on encryption/decryption