How to mitigate risk of exploiting open POST endpoints?

Question

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?

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.

Answer 2

In general, any request that takes an expensive or state-changing action (such as sending an email) should require authorization (usually via user authentication, but sometimes via e.g. source IP filtering). Anything else is asking for trouble; there's no way to avoid the risk of malicious abuse of an open endpoint except to prevent there from being anything it can be used for maliciously. Does sending email really need to be something that anybody on the internet can trigger?

Also, an attacker doesn't really need to look at your JS at all, unless the secret is used cryptographically (e.g. to sign requests with a nonce). They can simply use the Network tab of the browser's developer tools (or use an intercepting proxy, but that's more work). In other words, anybody can figure out how to send any of these requests with nothing more than the browser that comes with their OS, and no need to read scripts at all.