I'm currently in the process of writing a connector to an API. It's for an automated shipping system and I'm required to listen to events from that given API, sent via Webhooks.

The API owner does not add Authentication headers to the request they send to my webhook, instead they use a field within the body to mimic some sort of authentication. That means I have to parse the body of every incoming request, which makes it easy for attackers to DDOS my server (amongst other attacks). I've asked them to change that, but they refused.

   "token": "myToken",
   "otherData": ...

I'm very concerned about publishing such an endpoint unauthenticated to the www.

1) Is my concern legitimate?

2) What can I do to force them to use authentication?

  • Why do you think that having it in the body means it is no longer authentication? Sep 21, 2018 at 10:51
  • Parsing a body takes much more time than parsing headers. @ConorMancone It's way easier to attack and kill an endpoint that parses every incoming request's body than an authenticated request.
    – baao
    Sep 21, 2018 at 10:54
  • 1
    That is a separate issue (I also addressed that in my answer). However, you make a few comments about this being "unauthenticated". That's not correct. The API is authenticating themselves. They are just doing it in the post body instead of the header. Imagine someone on their technical team that received a complaint about their "unauthenticated" endpoint, even though the request clearly includes authentication credentials. They might dismiss the person without further consideration. Using proper terminology can be important. Sep 21, 2018 at 11:04
  • @ConorMancone English isn't my first language, I might have used wrong english terminology here. I did make that more clear (and correct) in my complaint to them in my local language.
    – baao
    Sep 21, 2018 at 11:14
  • 1
    Sure, if you have a proxy server that can handle the authentication from the header, then that will stop an invalid request much easier. However, it still doesn't change the main idea of my answer (which I will edit for clarification) which is that your concern only matters for threat models that are unrealistic and will probably never happen. For the kind of DDOS attacks that happen in the wild, these things just don't matter. Most of the time DDOS attacks just try to saturate your network bandwidth with meaningless requests. Sep 21, 2018 at 12:04

2 Answers 2


To answer your first question: No, I don't believe you have much to worry about. In particular, they are authenticating themselves, and I think you have some confusion in terminology going on here. The fact that the auth token is in the request body doesn't change anything about authentication. Many API calls work this way (although passing the auth token in the header may be more common). If you contacted them and tried to address the lack of authentication (like you are here) I'm sure they would have dismissed your concerns, because they are in fact authenticating themselves.

Regarding your concerns over DDOS, the difference between getting an auth token out of a header (which is probably the only other place it can live) and parsing it out of a JSON body is very minimal from the perspective of CPU usage. I don't expect it to make any practical difference in helping an attacker succeed in a DDOS attack. In all likelihood you have much more CPU intensive pages than this anyway, so if someone were to perform a targeted attack against your system and take the time to try to find the weakest endpoint, there are probably many much more tempting pages to be found.

However, even that isn't a real concern. Most DDOS attacks these days work by simply throwing as many requests at the target as possible to saturate their network bandwidth. As a result, the actual endpoint doesn't even matter, and the requests the attackers send are very rarely valid requests anyway. I doubt many attackers would bother doing more than looking up the IP address of your server(s), and there are probably very few circumstances in which they would first spend time looking around your website trying to find the most vulnerable page.

If you are concerned about DDOS get a DDOS mitigation partner like cloud flare. As Josef mentions, you can also try IP address limits on the page. However, there are much more effective ways to spend your time to protect your site against DDOS then trying to change the API structure of a third party service when your application has plenty more endpoints for an attacker to hit anyway.

Additional Clarifications

In the security world no answers are especially helpful without good threat modeling. As a result, it's worth breaking down the "threat model" you are concerned about. Having a request that passes the auth token in the body is important if:

  1. Someone is targeting your system for DDOS attack
  2. They don't have enough bandwidth at their disposal to simply overrun your network resources (DDOS of network resources via amplifications attacks alone accounts for ~half of all DDOS attacks)
  3. They therefore decide to target particular endpoints in your system that are resource-intensive
  4. They happen to stumble upon this unpublished endpoint and are able to figure out how the API call works
  5. They don't find another endpoint in your system that is more resource intensive

If all of those conditions are met, then indeed, someone might use this endpoint to DDOS your system, and the difference between authentication in the header and in the body may in fact matter. However, in case it isn't clear, these conditions are never going to be met. If someone wants to DDOS your systems they will probably just go off and rent a DDOS that will flood your systems with meaningless network traffic. It is both easier and more effective then trying to identify an actual weak point in your system. This is the primary reason why this doesn't matter from the perspective of a DDOS: the DDOS attack you are worried about is never going to happen because there are easier and faster ways to DDOS a website than this. The only way to protect against realistic kinds of DDOS attacks is with a DDOS mitigation provider.

This is why threat modeling and understanding real world threats is so important. You can spend weeks working with a third party provider to change their API in a way that minimizes CPU time on your end, only to then have your systems knocked out by a DDOS that blindly sends invalid requests into your network and overwhelms your network capacity. If you spend your time protecting against the wrong kinds of threats, you can end up wasting a lot of time and (more importantly) implementing the wrong kinds of safe guards.

  • I think you have some valid points. My biggest concern is, the third party API is very bad programmed. 3 weeks ago, they've sent an email to every customer, asking them to resend all the inventory data, because they've lost all the data. (Zero backup, ...) It would be amazingly easy to hack them, (I don't think they've implemented great security on their end), then an attacker doesn't have to search for weak endpoints, the attacker gets a database full of weak endpoints to target. Not only for DDOS. However, your answer makes sense...
    – baao
    Sep 21, 2018 at 15:29
  • @baao I can understand that causing concerns, but those are also separate questions. However, knowing all of that the answer is simple - make sure your webhook is not a weak endpoint. For the reasons outlined above, you don't have to worry about DDOS on this endpoint. However, you should make sure that you don't have any other security weaknesses, and you should make sure that you are treating all input through this API as potentially malicious data (which you would normally do anyway, so that's nothing new). Sep 21, 2018 at 15:56
  • @baao If an attacker did compromise their systems, I doubt they would look at this database of webhooks as weak targets. Since each is a separate system, they have the same "probability" of having security weaknesses as any other website on the internet. Now if the attackers happen to find a security vulnerability in the design of the webhook/API process itself that somehow gives them easy access through it, then you would have a problem, but you should be able to figure that out on your end (and having the auth token in the body isn't such a weakness). Sep 21, 2018 at 15:59
  • Yeah. You have some valid points and I will consider these in my planning. The other option would be to poll their API instead, not using the webhooks at all...
    – baao
    Sep 21, 2018 at 16:02

To answer your exact questions:

  1. Is my concern legitimate?
    • I do think so
  2. What can I do to force them to use authentication?
    • this depends entirely on the contract with them. If you want to go this direction, law.stackexchange.com might be better suited for your question.

If you search for a technical solution, you might ask them if the requests come from a specific set of IP addresses and only allow traffic from that addresses to your system.

  • The question about "What can I do to force them to use authentication" wasn't meant legally, but more in the terms of "is there a google initiative that punishes insecure behavior on the internet" to where I can report them. Do you know of one?
    – baao
    Sep 21, 2018 at 10:32
  • If they have actual security problems in their software, maybe. But if the problem is that it's harder for you to prevent DoS attacks, nobody else except you cares much.
    – Josef
    Sep 21, 2018 at 10:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .