I'm making a REST backend for private use of our frontend, they will both be in the same server.
The problem is that I'm worried about security issues, I don't want a attacker to use the API directly, either by JS or by using other REST client.
Lets take this service as an example
http://myserver:8080/something/webresources/film
That's a service that allows to GET, PUT, POST, DELETE I want that only the frontend be able to use it, otherwise since anyone can see client-code it would be easy to get the endpoint and start putting or getting data. I do have BASIC AUTH so they would have to register and if they did something wrong I would be able to see who did it, but that doesn't solve the problem.
I could implement access control so that a user only could get/update/delete their own movies, but I would have to do that for every REST service(I have over 100 by now), plus I might need to actually get others movies
This is my first public project, I am really lost.
You can do it through your web server. I'm using Nginx. I have an if statement that checks the $http_referer. If it returns nothing, or the value returned is not my application/frontend page (meaning someone is trying to hit the api directly), it'll return a 403 forbidden page.
If your application doesn't send out emails to your users don't worry about the following: I added a block to allow access to my static images as the only exception, as my application sends out emails with images and I don't want them to break.
That's it. Problem solved. No one has access to my api except my frontend page/application, unless they can forge the $http_referer to match my domain which if they can do that then they deserve to break in.
Your only option to call the REST API from server side. You cannot hide from the users what's going on in their browser... You can have a layered application, so the frontend layer can call the backend layer on the server while the client can see only the frontend. (Check the layered system constraint.)
Related
I want to refactor some back-end code. This code communicates with a front-end app, where the front-end app calls a bunch of APIs. I wish to trim the responses provided by the back-end. For this purpose, I want to know what properties does the front-end actually require. So, I want to know where an API endpoint is called on the front-end. Is there any tool which can solve this problem? A tool, to which I give the input my front-end application, it outputs me on what webpage it is calling a particular endpoint. Please note that this is the reverse of doing Ctrl+Shift+I, where I would want to know what endpoint is being called on a particular webpage. What this question is asking instead is, that I do not know the webpage which calls a particular endpoint, can you tell me how to find the webpage, given that I know everything about the API endpoint?
So i am making a social media like site where i use react for frontend and expressjs for backend...
I was using public api till now but now i need private api to control some login info. So, i cannot understand how to do it. Because the link where it will request can be viewed by doing Ctrl+Shift+I and can be used by anyone
I still have methods to do but just wondering, if any way to know where does the request comming from
Let assume that the api site is api.some.site and the main site is some.site, so the request should only come from some.site else send 404 response and i need to do it with expressjs...
I don't know how to do it but I wanted to give you some information to think about. If you want people to be able to log in, on your site. That api end point has to be unprotected, because a logged out person does not have any credentials yet. When logged in the user would be able to access protected end points right? End points like password change of viewing specific pages. So all the data an user should or should not have access to should be handled by the server. You website is only a mechanism to make your data look pretty and easy to handle. So in a way you shouldn't care about people using your open end points from another location because their open anyways.
Authentication should never be handled client side. It should always be handled by a server.
This is my opinion, hope it helps. Sorry if it's not what you are looking for
I'm still new to AWS and just following the documentation and asking questions here when I get stuck. Please excuse me if this question sounds really noobish.
So far, I've deployed the following:
EB to deploy my REST API
RDS to deploy my psql database
Lambda functions to handle things like authentication & sending JWTs, uploading images to S3, etc.
I have got my basic back end (no caching (just started learning about redis), etc. set up yet, just the bare bones so far) deployed.
I'm still developing my front end, and have not even thought about how I will be deploying it yet (probably another deployment on EB, since I am using universal react). I am just developing it locally but using my production env variables now so I am hitting my deployed API, etc.
One of the MAJOR things I have no idea on how to do is detecting incoming requests from client side to get the client's location by IP address. This is so that I can return the INITIAL results in your general location just like yelp, foursquare, etc. do when you go to to their sites.
For now, I am just building a web app on desktop so I just want to worry about getting the IP address to get the general area of the user. My use case is something similar to other sites you might have used which provides an INITIAL result set for things in your area (think foursquare or yelp).
Here are my questions:
What would be a good way to do this? I'm thinking of handling this in my front end react universal deployment since it will be a node server with rendered page caching. Is this a terrible idea? It would work something like
(1) request from client comes in
(2) get IP from request and lookup the IP location using some service (still not sure what I'm going to use, have found a few plus a nodejs library called node-geoip). Preferably, I can get the zip code since I am trying to save having to do so many queries by unique locations in my database, and instead return results in the zip code and the front end will show an initial map with the initial results in that zip code.
(3) return to client the rendered page with those location params if it exists, otherwise create it, send it, and cache it.
Is the above a really dumb idea? Maybe you have already done something like this, and could share your wisdom :)
Is there an AWS service which can already handle something like this for me? Perhaps there's some functionality which can already do this.
Thanks.
AGAIN - I apologize if this is long winded. I don't know anyone in real life who can help me and I feel alone :(. I appreciate the help you guys can provide.
There are two parts to this:
Getting the user's IP address. You mentioned you're using 'EB' - I presume you mean AWS ELB (Elastic Load Balancer)? If so, then you need to read the X-Forwarded-For HTTP header in your app code, since otherwise what you'll really detect is the ELB's IP address. X-Forwarded-For contains the user's real IP - or rather, the IP of the end-connection being made (there's no telling if this is really a VPN, Proxy or something else-- but it's as far as you can get with an IP.)
Querying an IP DB that can turn the addr into a location object. There are tons of libraries for you. Assuming you're using Node, you can use node-geoip as you mentioned. Or you can just search 'geoip service' on Google and find managed services, like Telize on Mashape. If you don't want to manage the DB lookup yourself or keep the thing up to date, then a managed service would help.
In either case, it's likely that you'll be doing asynchronous look-ups. In that case, you might want to use async/await to get the user's full object before injecting that into your React props and ultimately rendering it as a HTML string that's sent down to the client.
You could also use a library like redial to decorate your components with data requirements, and return a Promise you can await on to know when you're okay to render.
Since you probably want to enable client routing too (i.e. where the user can click on a route in their browser, and the server isn't touched at all), then you will probably need some way to retrieve the IP address/results based on that IP even when the server isn't involved in the initial render.
For that, you could write a REST service that retrieves the results. Or write a GraphQL back-end that gets the data. It doesn't matter how you write it, since the server will have access to the X-Forwarded-For header and can use that to retrieve the results and send back location-aware data.
FYI, I'm writing a React starter kit (called ReactNow) that uses rxjs for handling async streams. It's not ready yet, but it might help you figure out the code layout that would offer a balanced mix between rendering on the server, and writing universal code that requires some heavy lifting from the server.
I am totally new to Action HeroJS and I was wondering how can I restricted users to access my action herojs rest API, url from the browser?
I have even put the route as POST, but it is still accessible by get method?
Just like in java when we specify a rest api as post, it will not be accessible by get or browser url?
How can I accomplish this?
Edit:
Contacted the Action Hero, on github, they were pretty helpful, the solution was:
in web.js, put simpleRouting : false, and it should resolve the Issue.
Before you could access a post routed action, from the URL but after doing this you cannot!!
accessing a POST using get will return you a 404.
Thanks #Evan
Regardless of your language/framework, all routes are able to be hit by anyone, unless you block them at load-balancer or similar level.
Rather than thinking about the problem as "how to block" access, you should be thinking about the problem like "how can I ensure that this user is authenticated to use this route". Using things like cookies or tokens is the way to go.
You can use actionhero's middleware to apply access rules to specific actions, and return errors to the use if they aren't allowed.
Here's an example project that does these types of things:
Actions for dealing with the session: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/session.js
Middleware which uses that session data for access: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/initializers/session.js
and finally another action (route/url) which requires the logged-in-session middleware: https://github.com/evantahler/actionhero-angular-bootstrap-cors-csrf/blob/master/actions/showDocumentation.js
I have developed a front-end interface using Aja(AngularJS) and HTML5. Right now, I send an HTTP get request to my backend server which returns some data based on the GET parameters.
Since the URL is exposed in the Javascript file, I believe anyone could just use the URL to create there own API to fetch the data. How can I prevent such things ?
One way I could think of is that now instead of directly sending the request to the backend server, an application server could be used (hosting the HTML as well). The Ajax request would then be sent to this server (PHP script ?) which would in turn forward the request to the backend server and return the result to the UI. To prevent 3rd party services, I can disable cross origin requests on my application server.
Is this the correct way to solve my problem or are there better ways to do this? I am concerned that this would unnecessarily create another hop (internal though) for requests.
Note: The backend is running Apache Tomcat
In APIs that are not open to the world the user has to authenticate first in order to use it, see for example https://stripe.com/docs/api#authentication or http://dev.maxmind.com/geoip/geoip2/web-services/ -> Authorization