I have recently seen a web application that, while using Authorization header, accepted multiple Bearer keywords followed by a valid JWT token. For example, all of the following headers would result in correct authentication:

  • Authorization: Bearer jwttokenhere...
  • Authorization: Bearer Bearer jwttokenhere...
  • Authorization: Bearer Bearer Bearer Bearer Bearer Bearer Bearer jwttokenhere...

and so on. My question is - if the backend accepts such headers, is there any security risk involved here or is it only a matter of how backend handles it? None of other combinations I tried worked (like using "test" as one on the Bearers, placing token inbetween etc.), but I may have missed something. The backend is Java+Spring and it is probably using org.springframework.security.oauth2 to handle JWT tokens.

1 Answer 1


Just because an application accepts multiple Bearer strings or maybe will work without any Bearer string does not make the application vulnerable. The Bearer string by itself neither adds nor reduces security, the relevant information are all contained in the JWT itself.

Sure, it might be that this behavior is connected to a specific implementation which then results in a vulnerability in another place, but acceptance of multiple or none Bearer by itself does not result in a problem.

  • So I guess I'd have to dive into the code to verify if it (for example) bypasses JWT checks when some specific combination of Bearers or other stuff is submitted, but this does not have anything to do with a standard. Thanks.
    – adamczi
    Nov 9, 2020 at 15:54
  • 1
    It might be also just a bug! I've seen the exact same thing twice, which was caused by a buggy implementation of a WebClient (which was declared as a singleton) so headers were added one it top of the other until the internal app reached the maximum header allowed. Nov 9, 2020 at 16:08

You must log in to answer this question.

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