I have my own API built in php with zend framework for CRUD functions with database.
But now I am concerned about securing my little API for a bit cause I needs to have voting function which allows user to vote once per item. The only requirement to vote is user's facebook ID, so I am afraid if someone loop the post requests to my voting api with a lot of facebook id.
So now I am thinking of passing encrypted token from my app client to voting api and check it before api do the things.
So I want to know what are the best way to generate dynamic tokens and passing it securely to the API? Or is there any easy way to recognize the API requests that made from any sources other than my app clients?
Currently I use jquery ajax to pass all json data to my api. Thanks!
The easiest way I can come up with is, that you put a hash of some sort into the API call to verify that the data comes from your app.
E.g. you could create a hash of the Facebook ID plus a salt. You just have to make sure, that the receiving end does know the salt used for that call.
For example
hash = sha256(Facebook_id+app_id)
would be a way .
Related
I need to integrate Google Fit data on a project in PHP.
The idea is that every user, if he wants, can authorize the download of his Google Fit data.
Now, I was wondering if there are bees to handle this situation. Also if they are free.
Have you ever come across something like this? Thanks
Google Fit's REST API only supports requests from a single user.
The only way you can access multiple users' data is for each of those users to have given you an OAuth token which grants access to their data; you then need to make separate requests for each user's data using that user's OAuth token.
So I'm working on a project that I'll provide information feed to specific business partner. There's no login required because the business partner's front-end have to pass an preallocated apiKey along with any request to the my REST API. The api only responds to requests that contain a valid apiKey, and its access level has already been predefined when we generate the apiKey.
Currently I'm using CakePHP, with curl, passing the REST request method, and the hardcoded apiKey as param. Security hasn't been an issue so far. But our team is thinking that, what if our business partner want their website to be done in recently trending JS front-end frame work such as AngularJS.
For the same scenario, such a simple task cannot be done in JS framework. I obviously cannot simply give them the client secret (apiKey) and let them include it in their client side code. Anyone can view the secret and have access to the our REST API.
Now we're talking about security, which my team really do not know much. What are the ways to overcome this issue? How to pass a client secret along with http request from AngularJS, securely, obscurely? Any suggestion or could anyone point out something that I can study into?
I had some ideas though, but they just sound not so right.
I'll just put the AngularJS in CakePHP's webroot. That would be a really dirty hack though... Just introduce unnecessary complexity.
Generate hash with the a combination of constraints such as Origin Domain / IP / Public Secret and timestamp, and on my API side, I compare the hash and return an access token for each request... something like that...
There are different options
JWT (see my article)
OAuth (pick one)
A proxy to your API
First two will require an initial authentication request, you'll get a token back that is passed in every future request to your site.
You can create a proxy, the site calls the proxy which then makes another call to the real API and adds your API key.
I have developed a website with my friend. For the front-end we are using AngularJS, and for the backend we're using Laravel.
Whenever data has to be fetched, an API call is made from front-end to PHP.
My concern is that this API call is clearly visible in network panel. Then some bad guy can easily abuse this API. How can I avoid this?
In most cases exposing your API is not bad thing, but you need to think about this:
1. You should design your API, so only legitimate operations can be made. In example: person shouldn't be able to delete whole database using API.
2. You could provide some authentication mechanism if needed, so the person trying to call your API will have to be logged in (authentication token should be stored in session and verified in server-side with every API call).
If you want to hide POST/GET Params form console. Try to make JSONP call in angular . JSONP calls are not real ajax requests and won't be shown in Firebug. You can also clear the console using clearconsole() after you receive the response and you can also authenticate the requesting IP in your laravel backend.
It's just like regular routing. For example: Everybody knows that they can access a user's profile on Facebook on the /:username route, but Facebook prevents unauthorized clients from viewing that data. The same concept is used for REST routes.
Just like regular page requests, AJAX calls and the data passed / received can be seen by the user. JSONP can be used to prevent the API requests from being logged by regular developer tools, but that is not a good security solution your API can still be discerned by a malicious user.
Even if you encrypt the request payload and the response, it can be intercepted by a malicious user before encryption and after decryption.
You mentioned using proper authentication on your API, which is usually good enough for most cases.
My php app is integrated with Facebook's Graph API. I recently conducted load testing and found out that I hit the 600 requests per 600 seconds limit rather easily with a low number of users(1 large single batch request per user). In order to make my app work I feel that I would need to rely on user tokens(client side) instead of my single app token(server side).
My question is: Is what I want to do even possible and does my proposed solution make sense and how could I implement it?
1) Use JS sdk to login the user to FB and obtain a user token
2) Pass the user token to the php side
3) Make the graph api call using the user token
I am reading http://developers.facebook.com/blog/post/534/.
It says "this allows you to connect the user to your site or app using the JavaScript SDK (FB.login or the Login Button) and then call Platform APIs from server-side PHP without doing additional work". Does this mean using the user token or app token?
I am not looking to be spoon fed code, but could someone please point me in the right direction and give their opinion on my proposed solution?
Thanks
I'm new to creating API's and I am making an API for my php site. Now in any case what I am currently doing is having my script do a cURL call to some php file which does all the processing. Aka im doing a POST call for example to an api file which lets say creates a forum post for that user. Now the important thing to me is how do I authenticate and retrieve which user is sending the data. So how do I know the cURL call came from my server?
What I was going to do is have my server have a secret key that is passed in the api call and verified by the api file. The api file would make sure the key is correct and then take whatever username was passed in for example to make a forum post. My only concern is if this key is ever found out im screwed. I also want to be able to have the site work lets say as an android app so I want to be able to make curl calls lets say (not sure if thats possible) and have some authentication key sent to my server but I never want the user to be able to packet inspect for the secret key.
So my question is how can I securely do curl calls, since when I do a curl call it doesn't read any of the $_SESSION values I have set (unless im missing something). Any help is much appreciated. I was also thinking of authenticating using the username and password each time the only problem is I kind of want to avoid having to verify that the username and password is correct every time an api call is done since thats going to be another query that has to be done. But if that is the recommended way or the industry way then ill do it that way. Just looking for how to handle everything the proper way.
You should look into implementing OAuth then.