Security risk in using jQuery Ajax

Even if you switch from GET to POST, it will still be very easy for anyone interested to see (and change) any parameter being passed to your server. But here's the kicker: even if you're not using AJAX at all, but plain old forms, it is still extremely easy to see and edit any parameter being passed to your server.

In critical situations, you can never rely entirely on what you receive from your clients.

For instance, if you're adding something to your shopping cart, pass only the ID of the item, and the quantity, to your server. Do not fetch price details from your client, but from your database. If some one tries to hack you and edits the item ID or quantity being sent, the worst thing that happens is that they end up buying something they didn't want; entirely their problem. (But for the very same reasons, if it's a limited offer, you would need to verify that the quantity you receive is not greater than what you allow any one customer to buy, for instance).

So at the end of the day, it's always you the developer who will have to decide which values you want the user to control, and validate at your server side that you have not recevied any requests that are outside the bounds of what the user ought to be able to do.

You can never rely on any actions or data coming from client side, not only related to jQuery.

You must handle every kind of security concerns on your server side. Always double check data coming from user (one is on client side for decreasing number of requests for performance; and the other is on server side for actual confirmation).

The request type (GET or POST) actually does not matter, it may be simulated easily. After user tries to add a $50 item for $25, you should check your DB and confirm the actual price of item.

You are quite correct, anyone who is slightly tech savvy can identify the public server endpoints for any webapp. They don't even need to look at the code. They can just use their webkit/firebug to track the request, or a program like Charles which monitors network activity.

That's why you need authentication and authorization handling in your server side code.

Authentication is typically handled by a username and password; it is the act of verifying a user is who he is.

Authorization can be handled by Roles on the server, and is the check to make sure the user can do what they are trying to do.

Which those two mechanisms in place, even if a user knows a url, they still need to "log-in" and have permission to do what they want to do.

Think about it. If you look at your bank account information online, you can easily identify the requests that load your account info. Without these mechanisms, what is to prevent you from simply changed the account-id you pass to the server to try and get someone else's account info? With authentication/authorization, the server knows that even if it gets a request to load some data, it can check the user's details to see if they have permission to get that data, and deny the request.