There is a public query form in my web app, and architecture team asking to authenticate the web app with OAuth2 like this, but I don't believe it will be of any help.

I believe best way to protect is by reCAPTCHA.

Can we prevent DDoS or spam form submission by using client authentication?

  • 1
    DDoS is more of a traffic problem, so authentication won't address that. – schroeder Feb 4 at 12:37
  • 1
    If the authentication mechanism can be fully automated in both sign up and login, then it won't help with spam. It's the controls on the sign-up that will prevent automated spam. – schroeder Feb 4 at 12:39
  • In what way do they think that OAuth2 will help this problem? How exactly are they planning to use this? I strongly suspect that they have badly misunderstood something... – Conor Mancone Feb 4 at 14:16
  • 1
    Ah, maybe I understand. They're not entirely wrong - this may block some forms of spam form submission. It certainly won't help with DDoS. It is unlikely to be the most effective method though. – Conor Mancone Feb 4 at 14:18
  • 1
    I don't think you can prevent, you can reduce the impact, but nothing prevents to have a DDoS on your recaptcha infrastructure for example. – camp0 Feb 4 at 14:59

tl/dr: Client authentication in the browser is useless because browser-based bots will automatically authenticate themselves, and browser-less bots will get stopped by much simpler methods anyway. This isn't really a surprise, because "client authentication" isn't really effective for browsers (and is only slightly effective for other "kinds" of clients). Captcha, unfortunately, is the only real solution, although it cannot protect you from targeted attacks.


I want to clarify a detail from the comments. My understanding is that the goal here isn't to require someone to login to use your form. Rather, you want the client (in this case, the JavaScript app you build which runs in the user's browser) to authenticate with your server, so only people browsing your website can submit your form. This authentication will happen by JavaScript adding an authorization token to the request, and the server rejects any form submissions that don't contain the correct authorization token.

Before I go into details I want to emphasize one important point: it is not possible to restrict someone to only using your "app". Your JavaScript runs on their computer, in their browser. As a result an attacker can easily reverse-engineer your app (which is extremely easy when it is javascript in a browser), determine how it authenticates itself with the server, and then reproduce that in anyway necessary. To try to limit users to only using your app effectively means that you are trying to implement DRM, and it is simply not possible (especially in cases like this). You can make things harder for attackers, but you can't stop them outright. Still, let's discuss your question in more specifics.


In order to protect against spam bots, you first have to understand how they work. There are of course a ridiculous number of varieties, but I'll focus on two general "types" (keep in mind that I've chosen these categories somewhat arbitrarily):

  1. Many simple bots request pages from the website using a non-browser HTTP client (for simplicity, imagine they use curl). They then parse the HTML looking for forms. If they find one they also look at the inputs on the form, decide on how to "fill out" the inputs, build an HTTP request with their data, and then send it off to the url of the action property on the form. Pretty simple. They will also fake details in the request headers (Origin, User-Agent, etc...) to look more like a regular user.
  2. However there are "fancier" bots out there that actually use browsers. You can build your own bot using something like selenium which effectively lets you automate browsing the web using an actual browser. The bot uses Selenium to load up a page in the browser, click on input forms, send in keyboard input, and then click on the submit button.

Protecting against "simple" bots

The simple class of bots reads the HTML returned by the server to figure out what kind of request the server is looking for, builds a matching request, and sends it to the server. If your client-authentication process involves using JavaScript to attach additional credentials to the request, then that authentication process will actually stop such bots from executing successfully.

However, it isn't technically the presence of the authentication that keeps the bots out - it is simply the use of JavaScript that stops them, because the bot doesn't know anything about steps that JavaScript takes. For this class of bots, you could just as easily have JavaScript intercept the form submission, add some predetermined data to the request (imagine it adds something like not_a_bot=true to the request data), and submit it with Ajax. The server then rejects any requests that don't include that not_a_bot=true flag. This sort of incredibly simple check will stop bots that don't execute your JavaScript. In fact, I've actually used this in production systems and it dramatically cuts down on bot submissions. The only downside is that it also locks out users that don't have JavaScript enabled (which your proposed client authentication method also does).

So, will your authentication step help? Yes! However, only by accident, and there are much simpler ways to accomplish the same thing.

Protecting against "fancier" bots

However some bots work by using an actual browser, which means it runs any JavaScript passed down by the server. As a result any sort of automatic authentication step that is executed by your JavaScript will automatically happen for these kinds of bots as well. In fact, it is nearly impossible to differentiate between these bots and regular users.

This means that whether you secure your form by adding the not_a_bot=true flag in JavaScript, or whether you secure it by having JavaScript add in an authorization token to the request, these bots will take the same exact steps and the server will accept the spam submission. The attacker won't even have to reverse engineer your app - your own JavaScript will allow the spam bot to circumvent your protections.

How do you stop these bots from filling out your forms? There's only one cost-effective solution: a captcha system (although even that isn't a guarantee).


DDoS is not even worth a mention. A DDoS attack works by simply flooding the server with so much traffic that it cannot keep up. While there are some kinds of DDoS attacks that might be prevented by trying to ignore submissions from bots, the most common kind won't be. Many DDoS attacks work by simply sending so much network traffic to your infrastructure that there is not enough bandwidth to keep up. When that happens there is nothing that can be done at the server level to stop the DDoS attack. Completely different strategies (mainly at the network-level) are required there. Whoever suggested that this might help against a DDoS simply doesn't understand how such attacks work.


So after breaking things down we can see that client authentication provides absolutely no benefit. It would stop simple spam bots, but only because it requires JavaScript which simple bots don't execute. Instead there are much simpler steps which would stop these kinds of spam bots anyway. Moreover, the client authentication will provide no protection against bots that use actual browsers to do their job. Nothing will stop those, although a good captcha may at least discourage drive-by-bots that aren't specifically targeting you.

| improve this answer | |
  • While I think you are right in general, the term „authentication“ is used in a confusing way. Obviously, having a user or system authenticate against a web app will prevent spam bots. It is also, by definition, unusable for a public form. An „authentication“ token that anyone can retrieve by executing some JavaScript is not really authentication. Of course you are right in that trying to „authenticate“ the browser software itself itself is pretty much a useless operation. – averell Feb 7 at 7:10
  • You should also note that some forms of javascript (e.g. the cloudflare interstinal page) can effective against layer 7 DDOS attacks because they force the attacker to expend resources (time and computing power) and that makes the attack more expensive to them. It will not reliably prevent spam submissions, though. – averell Feb 7 at 7:15
  • @averell Authentication doesn't have to be user-to-server. It can also be server-to-server or client-to-server. The latter however is rarely done because (as I mentioned) it is easy for an attacker to extract the secrets from a client and break the authentication. I focused on client-to-server authentication here because after some discussion I decided that is what the OP is asking about. The title is a bit misleading but they aren't looking for user-to-server authentication (aka this really is a public form) – Conor Mancone Feb 7 at 11:37
  • Although even requiring registration won't stop all spam bots. Some can and will register on sites to access "private" forms, presuming that registration is free and unmoderated. – Conor Mancone Feb 7 at 11:38
  • Regarding JavaScript, it's possible that I'm thinking of something different than what you are talking about, but that "page" is actually a network-level mitigation technique. You're talking about the page that says something like "Cloudflare is protecting this site and will redirect you in 5 seconds" right? This helps simply because Cloudflare is delaying requests from reaching the server, and it works because Cloudflare is in a position to intercept the request before it reaches the destination server. – Conor Mancone Feb 7 at 11:43

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.