How to mitigate risk of exploiting open POST endpoints?

I'd like to ask for advice reg. protecting the state-altering HTTP API endpoints of the API that I'm owning (POST etc.). I'm owning a web application that exposes some HTTP endpoints to the world. Architecture-wise it's very similar to Google Analytics: there's a JS snippet that our clients integrate into their websites, and this JS snippet contains logic to communicate with its backend API through HTTP requests. Similarly to GA, there's no authentication required - the snippet logic is able to construct the requests to the backend API. Some of the backend API endpoints are read-only, but not all of them (e.g. one of the endpoints sends an email whenever it receives the request). While protecting the GET endpoints is fairly easy (via some rate limiting; there's nothing secret in the responses as well), I'm afraid that we're doing too little in terms of POST endpoints protection. What we're doing to protect POST endpoints is: * rate limiting as well, to catch some DDoS attempts etc. * some custom frontend logic with "secret" token. The POST endpoints require the token to be sent as one of the params. This token is available to the JS snippet through a bit of obfuscated logic (some part of it comes within some earlier response to a GET request, some part of it is calculated in the frontend by some a bit obscure code). Only if the token matches the backend logic, will the request get processed. That's obviously security by obscurity rather than any real protection - any relatively smart attacker could figure out how this works by analyzing our JS code and building their own logic to retrieve data from this frontend endpoint of ours, to calculate whatever's needed. I was always assuming that this is the best we can get in such circumstances, but maybe I'm wrong/missing something - maybe there are some smart approaches that I've never thought of, to at least further mitigate the risk? The likes of GA or Tealium must have the same problem - maybe they came up with something better? Suggestions?
http://dlvr.it/SjNBTb

No comments:

Post a Comment