Sorry for this possibly silly question, I'm just learning about JWT so please bear with me...

I read the JWT docs extensively but I don't understand what prevents a hacker from hijacking the JWT and posing as the user for which it was originally issued.

Here's the scenario I'm worried about: suppose a bad actor is somehow able to sniff traffic on my corporate network and also has a simple account on my site. If he is able to find an employee user who has admin or special permissions, can't he log in to the site, receive his SSL cookie, then hijack the employee's JWT and pose as that user now and gain those special permissions?

Since I won't be checking the bad actor's credentials again, only their JWT, it seems to me the bad actor could submit the JWT using the site SSL through his simple account...

What part of the puzzle am I missing here? Thank you!


5 Answers 5


JWT are only an encapsulation of information into a string with the ability to encrypt these information and detect tampering. JWT by themselves don't protect against cookie theft or misuse done with sniffing, XSS, CSRF, browser extensions or similar.

This means you still need to employ the usual methods to protect the token or cookie against misuse, i.e. use http-only cookies to protect against XSS, use TLS to protect against sniffing, use CSRF tokens or other techniques to protect against CSRF etc. And you might include some information in the protected token which make misuse harder, like a fingerprint of the browser, source IP of the user etc - see OWASP: Binding the Session ID to Other User Properties. Of course you need to verify these information each time the cookie is used for authorization.

  • What do you mean by browser fingerprint, how to generate it?
    – W.M.
    Feb 2, 2018 at 19:51
  • 1
    @W.M.: for example the User-Agent header of the clients browser. See also OWASP: Binding the Session ID to Other User Properties. Feb 2, 2018 at 21:32
  • I'm following along with the following JWT tutorial (<blog.angular-university.io/angular-jwt/>), which says "The only way for an attacker to impersonate a user would be to either steal both its username and personal login password, or steal the secret signing key from the Authentication server," but reading the answers in this post, it seems as though that quote above is not correct, as anyone sniffing on the network could also steal an unencrypted JWT. To clear up my confusion, I just want to double-check that the quote above is indeed not correct. Thank you! Oct 29, 2019 at 1:56
  • 1
    @Crowdpleasr: The statement you cite is made in the context of how a JWT is constructed and not how it is used. Of course, if the attacker has access to the JWT it is indistinguishable from a proper client, no matter if the JWT is in itself encrypted or not. Oct 29, 2019 at 4:46

There is a considerable risk posed by an attacker sniffing network traffic and stealing session cookies to impersonate other users. However JWTs were not designed to address this risk. You have SSL/HTTPS to take care of that problem. An SSL connection between your browser and web server provides confidentiality and data security in transit. If you are using JWTs over an HTTP connection, there is not much you can do to prevent the attacker from sniffing your traffic and misusing the token.

JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-boarding in a single sign-on system as there is minimal integration required. JWT are also HTTP friendly as they are just BASE-64 strings.

JWTs have had their share of security issues in the past. read more .

P.S. you still need to rely on third parties to get the right public keys for token validation.

  • 1
    the same threat exists for username/password combos, the nice thing about JWTs is that you can expire them. Dec 24, 2018 at 2:31
  • You can't expire JWTs on-demand unless you do blacklisting of the tokens. Which kind of defeats the purpose of them. This is one of the major drawbacks of using JWTs for authentication, no logout, no idle timeout, etc. Feb 19, 2019 at 6:00
  • 1
    @DanielSzpisjak Yes, but you can make them short-lived and require a refresh on expiry. You can then blacklist the refresh token and implement all the features you've mentioned on that instead. So the drawbacks are then confined to the longevity of the initial token. Nov 11, 2020 at 9:10

i also face this security related problem in past but i can do like that in laravel. simpley make one middleware and check Origin like that.

namespace App\Http\Middleware;
use Closure;
class CheckOrigin
    public function handle($request, Closure $next)
        if($request->header('Origin') != 'http://yourapihost.com') {
            return response()->json([
                'meta' => [
                    'message' => 'You are Unauthorize person.',
                    'status_code' => 401,
                    'status' => false,
        return $response;

so, if someone hijacked your jwt token and then try to call request from another server or localhost then middleware not allow that kind of request.

  • This only covers the case where the JWT is sent as a cookie in a CSRF attack, it does nothing for the more general case of a stolen JWT. Dec 13, 2018 at 17:00

I am jumping in to provide some context.

What protects a JWT from being hijacked and used to pose as the original user?

As others have stated, nothing. JWTs in themselves offer no protection against this.

There are authentication schemes which provide protection even if the communication channel is compromised. These are called signature schemes. They work by signing the HTTP requests, hence the name. They are complicated, without a standard and used mostly between backend communications.


You can't fully prevent JWT hijacking but you can make the JWT hijacking harder or not sufficient to break the solution.

For example, if you want to do so for mobile App API you should go one level further beyond the OpenID concept and verify that the client App that is providing the JWT for Authentication is a genuine legit App, but not a script or postman. You can address this by implementing the concept of Zero Trust to verify the client's endpoint.

One approach is to use App Attestation Service like SafetyNet. There is similar technology available also for iOS and Huawei devices.

Another possible approach is to use AppiCrypt technology AppiCrypt. This one is simpler to integrate and does not introduce a dependency on 3rd party services. The main limitation of AppiCrypt is that it is SW-based and relies on low-level obfuscated SDK code.

An AppiCrypt is a technique that ensures cryptographic evidence or proof of client App authenticity and integrity. On top of that, it provides device identity with security risk scoring for fraud prevention, enabling more sophisticated techniques like channel binding, device binding to users, step-up authentication, and others

(Disclaimer: I am a co-founder of Talsec)

  • Which SafetyNet are you referring to? A simple Google search seems to have confused me and I think a link is necessary in this situation. Jul 11 at 17:58
  • how is the introduction of 3rd party software to secure an api not introducing a dependency on a 3rd party service? (there is far too little information on the- i assume- commercial appicrypt solution presented, for this claim to stand alone)
    – brynk
    Jul 11 at 19:43
  • How does adding a mother service protect against credential reuse? Your proposed hardening will only deter a pro for a few seconds. This sounds like a poor attempt at selling your product. And I completely miss any technology like certificate pinning, mutual TLS and oAuth with PKCE. Or in other words, what is the problem you are selling a product for? Cause I don’t see it here in your anwser.
    – LvB
    Jul 11 at 22:09
  • @sir-muffington, link provided
    – Sergey Y.
    Jul 20 at 12:06
  • 1
    @LvB, I agree about GDPR. This is an incorrect statement, I will take care this is corrected.
    – Sergey Y.
    Jul 27 at 12:51

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.