-1

I am learning how to implement security in my rails 5 API. I'm developing an angular app to consume the API, to do this I'm implementing devise_token_auth gem, but in my test in postman I can sign up with email and password, then I receive a response with token (with expiry), data, content-type, client, uid, then I test this from angular and signup from my browser and in the web console I can see all the information that is necesary to access the api from another application.

The devise method authenticate_user need the parameters: content-type, access-token,client, expiry, uid, but everybody could access this information if they take a look at the response in web console, so then... I pick this information and paste in a Postman request and I can access my protected endpoint, so how would this gem be useful? Am I missing something?

Here I sign-in from angular, and check response in web console:

enter image description here

Then paste the info in a new request in postman to access protected endpoint:

enter image description here

And the access is successful, how do I prevent the header information from being displayed on the web console?

mkrieger1
  • 19,194
  • 5
  • 54
  • 65
matQ
  • 597
  • 2
  • 13
  • 27

2 Answers2

1

But everybody could access to this information if they take a look at the response in web console

Am I missing something?

Yes. "Everybody" would only be able to see their own token (excluding things like sniffing http. You will be using TLS, right?). With their token, users can do what they please and there's little you can do about it.

But they can't see other users' tokens this way.

Community
  • 1
  • 1
Sergio Tulentsev
  • 226,338
  • 43
  • 373
  • 367
  • Thank you sir for clarifying my doubts – matQ Oct 09 '18 at 15:00
  • The token is also often regenerated for each request too (DTA default) and they're only valid for a limited time (60s). This helps prevent an attacker reusing a stolen token – developius Apr 04 '20 at 02:48
1

This is how the internet works. You are logging in and sending information to the server. The server then responds with a secret token that you can use the next time instead of the username and password. With that secret token you perform subsequent request rather than with your username and password.

Regarding your concerns about 'everybody' seeing it. This is why you need SSL encryption, this ensures that someone else cannot read the username and password you sent, and also the token you received. Without SSL anyone on your network or route to the server can indeed read it.

Ig Norand
  • 23
  • 3