Whoa This Is Crazy

[kevinzweerink]

Dang man this is real nice. What's to stop someone from just grabbing the private key from any of your url's client-side, and then un-privating your api by making requests with that key?

[brannondorsey]

Thanks brother! Essentially nothing if you make an $.ajax request with GET. The private key will remain private if you make all requests via POST though I believe. The idea of the private key is my attempt to put a layer of separation between the owner and anyone else who is trying to access the data. I don't think its fool proof but it should stop most people who just stumble on to your api.php endpoint. Also, unless your backend page is set to save data to the database using a method like Database::execute_from_assoc() unwanted users have read-only to your database results.

Also what exactly do you mean by "grabbing the private key from any of your url's client-side"? If you are using the private api only you should be accessing your api.

[bakercp]

Any request -- including POST, GET, etc are easily "sniffable" on unswitched networks (including public wifi) using tools like Wireshark. The only way to "secure" the contents of a transmission like this would be to use an https connection. This is still potentially hackable using mitm attacks, etc. If security is a high priority other authentication methods such as source IP filtering via the host firewall or multi-factor authentication such as OAuth should be considered. Of course, the more complicated your security scheme becomes, the less "easy" this library will be to use.

[brannondorsey]

I think that at this state the "security" that I have set up for this little lib is very vulnerable. That said, I know too little about security (which I feel like is an incredibly uphill battle) to confidently make the adequate changes to account for attacks. If security is a huge issue and someone "getting in" would be a detriment to a project I would suggest they use something better than what I have made here. That said, as long as the api.php page that a user sets up on their server doesn't insert into/update the database the only harm of an attack would be access to viewing the data that is returned.

[bakercp]

In my opinion, you should simply make note of the limitations of your "security" key, its ability to be compromised and remind users of some best practices (i.e. read only database access, etc). Past that users requiring highly secure db interfaces are likely going to have other requirements that will require them to use other software anyway. The benefit of this project is that the code is simple and easy to deploy -- perfect for rapid prototyping and light production. Usually security is less of a concern in those scenarios.

[mhmd1983]

umm, client can create a php file that makes the call with the key defined , it doesn't really require to directly call the api through ajax.