I have an API set up on my server (node.js) which potential clients can send request to. One such client would like for me to set up a structure where they would pay only for the amount of their users who would connect to my API. They are creating a mobile application. Regardless mobile or web, I'm not sure how I would be able to track their individual users, to make sure it is their users who are sending requests to my server and not the client himself. The client can make one request and send to 1000 of their users instead of 1000 of the client's users directly connecting to my server.
The only feasible solution I can think of is creating a plugin which they would insert into their app and it would connect directly to our server, bypassing the client's server. Something like a Facebook Share/Like, Google +1 button. Creating the plugin would require to create the entire request and dynamic layout in each platform language, which is outside my scope at the moment.
Is there any way to have the end-users connect directly to my server through the client's app, bypassing the client in the middle, allowing me to know how many users will be connecting?
Related
I was wondering if it is possible to secure an expressjs RESTful API that only a react native app and react website could access.
For exemple my server is running on port 8000, my react native app is on port 3000 and my website on port 5000. I want the server to listen only to requests coming from these ports.
Let's say I have a POST route to mydomain.com/signup I don't want users to make that post request using external websites or tools like Postman.
What would be the best way to ensure my mobile app and Web site are the only ones allowed to access my RESTful routes.
First off, you are a bit mistaken about how a request to your API works. When your react app on port 3000 makes a request to your server on port 8000, it's just a random incoming request. It doesn't "come" from port 3000. In fact, the incoming port number with be some randomly generated port with 5 or 6 digits. Outbound ports are dynamically generated by the TCP system and you can't tell what "app" it came from.
Second off, your RESTful API server is just a server on the internet. Anyone can make a request to it. Using cross origin protections, you can provide some limits about what can be done from browser Javascript (only allowing requests from your particular domain's web pages), but other requests (not from a browser) cannot be blocked this way.
So, any code jockey using any tool other than a browser can write code to your API. What someone like Google does is they require you to either have an APIKey that they issued to you or they require some login credentials (often a cookie from a previous end-user login) that identifies the user making the request as a permitted user using their system. Even with these tools, this just means that a permitted user is accessing the API, it does not mean that only your app is accessing the API. And, in fact, you can't really prevent that.
So, what most people do is they require a login or APIKey credential and they track the type of use of the API. If the use of the API seems appropriate (particularly the types and frequency of requests), then that use is permitted. If the use of the API does not seem appropriate (often too many requests over some period of time), then that particular credential or user may be blocked from accessing the service either temporarily or permanently.
Let's say I have a POST route to mydomain.com/signup I don't want users to make that post request using external websites or tools like Postman.
You cannot effectively do this. There are obstacles you can erect to make it more difficult like putting an expiring token in your web page and having your own use of the API include the token and then detecting if its a valid token, but a determined hacker will just scrape the token from the web page and still access your API using it from whatever programming tool they want.
What would be the best way to ensure my mobile app and Web site are the only ones allowed to access my RESTful routes.
You can't. Your API is on the web. Anyone with whatever credentials you require can access it.
I have created few API on nodejs a d want to consume in same nodejs app. Even I have ensure cross origin to my domain.
It's only preventing cross domain and not allowed API.
But when using postman it's allowed .
Please help to provide how to restrict my nodejs api to be used by my app internal in angular and should not allow cross domain and postman.
Cross domain protections are implemented only in a browser to protect end-user browser security. They do not apply to http requests made from Postman or from node.js or from any other programmatic tool, only from the browser.
There is no way to keep your API from being called by other agents besides your own web app. This is just the way of the web. For your web page to be able to use the API in the browser, that API has to be open to the public.
The usual way to provide some protections on such APIs is to require some sort of user login in order to use the API. Your own web app can have a logged in user and your server can require a certain login cookie be on the http request before your server will fulfill the request. This too can be used by 3rd party tools such as Postman, but they would have to first obtain an appropriate login cookie.
To prevent abuse even in these cases where they get a login cookie, you would need to track usage on your server and if you detect any irregular patterns or abusive patterns (often with some sort of rate limiting detection logic), then you can temporarily or permanently ban that user login.
So I want to have nginx serve up my react app that uses an API that is setup to make all the API calls for me. I want to do this so I can guard my API key and secret. So the API server is running on port 9001 and my react app is making api calls to to http://localhost:9001/api/v1/token. It works just fine. The issue I have is, how can I stop someone from doing the following to get a token?
curl -X POST --header "referer: http://localhost:8081" -i http://localhost:8081/api/v1/token
Thanks
If what you're asking is how you allow only your react app to use your API server, then the answer is you can't really.
Any request made from the browser has to be made to a server that can be reached lots of other ways (such as your Curl example). You can't allow only requests made from your React code and disallow all other attempts to talk to your API server because at the lowest level, these are all just http requests. Any determined hacker can just watch what the browser sent from your React app and make an http request that looks just like it. This is a fundamental design characteristic of how apps in a web browser work.
That said, there are some things you can do to "protect" your API server from abuse.
1. Require some form of account or authentication. This will at least require a hacker to make an account in your system and use that account to access your API server (more on this later).
2. Implement rate limiting so that an individual account (detected based on the credentials in the previous step) is only allowed certain frequency or pattern or access. At the very least this protects your API server from being overly abused by one bad actor.
3. Implement abuse control. If one particular account is regularly abusing the API server (hitting rate limit controls and generally using way more resources on your API server than any reasonable normal browser user ever would), then you can ban that account.
Services such as Google maps implement all three of the above in their efforts to protect the integrity of their API servers.
There are other techniques such as embedding an ever changing token into the web page that is then required with each subsequent call to the API server, but a determined hacker will just scrape the token from the web page and then use it until it expires so this is really just another obstacle for the hacker to get around, not an actual roadblock.
I'm planning on making an android application that sends user data to a web server and stores it temporarily in a database. Now I've never worked with databases or web servers before, but after reading a bunch of tutorials and a few days of hacking away I managed to get a node.js server with mongodb up and running on the openshift platform.
Right now anyone can interact with the database just by sending a GET request or even just pulling up the url in a browser. Is there a way to prevent that by happening or would I have to maybe encrypt the data myself before storing it?
You describe a typical web application using REST APIs. To secure it, do two things:
Deploy your REST APIs (or the entire site) using HTTPS instead of HTTP. This provides end to end encryption so your sensitive data cannot be viewed while in transit
Add an authentication and authorization mechanism, so that only authenticated endpoints can access your REST APIs.
I am creating a web application that uses the Drupal 7 Content Management System. The web pages heavily use JQuery and AJAX.
The AJAX calls hit REST services, which are actually implemented using JAVA. Apache is running Drupal 7 and is configured to pass any calls to the REST urls through to the Java EE server (Jboss AS7). Everything is over SSL.
I need to Authorise and Authenticate calls to the REST services, and access the username or ID of the person currently logged-in to Drupal from the Java app. The question is... how...
As the AJAX calls are made to the same Apache server (rather than to a separate server etc), everything happens within the same http session, so I'm hoping this will be quite easy.
Things I've thought-of:
Configure a java security interceptor that calls a custom (locally
accessed only) drupal service that somehow reads the session id and
returns the logged-in username
create a "dumb" drupal REST service to act as a gateway for all of my REST calls, which authorises/ authenticates then injects the username before passing-through to the Java backend service
The article at https://lists.wisc.edu/read/messages?id=7777296#7777296 made me wonder if I could get-away with calling a Drupal service (just at the start of each Java service session) that takes a Drupal sessionID and returns the current user and his roles. I could configure it in my Java service so it would reperform this call every x seconds or y calls to check for role changes or logouts.
How does everyone else do it? This must be a common problem to solve isn't it? If not, what do you do instead to securely access authenticated services over AJAX? I'd rather not introduce a second user control process in addition to Drupal unless it's unavoidable. DRY :)
Thank you - this has me stumped!
Looking at what you are doing and trying to keep things as simple as possible, I would go for a variation of the first option. This is basically what the current node.js module does although it does it with unique authorization tokens. The workflow is something like this:
When a logged in user loads a page, a unique token is generated and stored in the Drupal database and sent to the browser
When the browser goes to connect to the node.js server it sends the auth token along with the request
The node.js server, upon receiving the request with token for the first time, will connect to a web service on the Drupal site and verify that the token is valid and send back any info about the user, and what roles/etc they have.
The node.js server then stores this internally for future requests, so that it doesn't have to ping the Drupal site for each request.
When a user logs out of Drupal, Drupal makes a direct request to the node.js server asking it to delete the token for that user.
Sounds like basically swapping your java app for node.js this should be pretty doable, with the advantage that it can scale well if you split this to multiple servers in the future.