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:

  1. rate limiting as well, to catch some DDoS attempts etc.
  2. 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?

1 Answer 1


In general attacks on POST operations are:

  • Memory exhaustion attacks. The attacker sends a big payload on the POST for exhaust internal buffers/memory that handles the data. (For example Slowloris). Also keep TCP connections open so the internal buffers are not free.
  • SQLI, XSS, RCE, etc.... vulnerabilities that potentially could be on the data.

If you can cover that methods in your endpoint by limiting time of POST operations and also analyze your data payloads you will be in a good spot. Probably I miss some other attacks so never never stop monitoring and learn about your service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.