Security risk of embedding JWT in URL?



  • I have a an endpoint, it redirects to an image which is stored on a storage service, I am considering if it is safe to embed the JWT in the url endpoint as such https://host/image?token=. This is the same JWT token which the system uses to decode and authenticate the user session. It works and allows me to ensure only a user logged into the system is able to access the storage url however does this impose any additional risks by placing the token in plain view instead of embedding it in the HTTP headers?

    Thank you.



  • As designed, this makes your system significantly less secure. That's because you've turned a token which authenticates an entire session and embedded it into a URL, where it is much more likely to be exposed, such as in browser history or in logs. If that token is exposed, so is access to the entire user session.

    What would be more secure is if you you created an authentication token that was restricted to that URL (say, by taking a hash of all of the remainder of the URL and embedding that in the token). That would limit the scope of the exposure to access to that particular URL.

    In addition, you should also make sure that either the JWT does not contain any identifiable information or that it is encrypted, so that if it is exposed, you haven't revealed potentially sensitive information about the user, and also you should limit it to the shortest possible timeframe possible to minimize the consequences of exposure. These latter two options are best practices anyway, so you should consider adopting them regardless.

    With those constraints, using some sort of authenticated URL isn't intrinsically insecure. They're used with suitable constraints by many websites, including Amazon S3, and while putting the data in the header is better, using the authentication in the URL isn't bad.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2