I'm make a simple api so my Java Spring app communicates with my angular app.
Now I realised that I need an endpoint with the user information . @GetMapping("/user/{username}")
Is it ok to include the encoded password ? I think I will need some kind of protection so people can't just make get requests to get user information.
Any idea?
The first question you should do is: what the purpose of the endpoint?
We can list many scenarios where you can use this approach.
So what you have to do is:
Create the endpoint /user/<username> or /user/<user id> to return the user information. But be aware that only logged user can access this endpoint and you SHOULD make some security policy. All users can see all user information? Only admin can see the user information?
Why using /user/username you can handle that with a simple /user/me and return the logged user information!
Never send password in the URL!!! You SHOULD create and endpoint /login sending the username and password as post body, then you can return a JWT or choose another login strategy
I saw that you are using Spring, so look for an authentication pattern on Spring and integrate with your Angular. The best approach for Angular is using JWT.
The answer depends on how sensitive this information is. You can pass a password over HTTPS and have some degree of confidence that it is not visible; however, that can be hacked. So can just about any security approach, if the attacker has sufficient skills and resources.
First of all, if it's possible to request the info of any user, you should NOT include any information on the password.
If you limit access to only the currently logged in user, it's still a bad idea IMO.
You can hide certain fields quite simply: https://stackoverflow.com/a/40913991/4813549 shows how to do it for GSON, https://stackoverflow.com/a/14708961/4813549 has the answer for Jackson
It is kind of broad answer.
But it depends how you validate your users. If you created your own secure login you should stop now. Even if you encrypt, encode and salt your passwords there are many vulnerabilities for a novice user to cover and there are plenty libraries and software that are supported by big and active (open source /free software)comunities that patch against old, new and common security flaws.
I havent use spring so far I think it has it own libraries to validate users, I might be wrong.
Also you can use something like Keycloak. Which I recomend to everyone. It is easy to implent and the documentation is good.
You should read this https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/ and this https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
The idea is to have a way for your server to know if your user is already logged without sending a password every time.
In a really simplified way when you log in with cookies an sessions what you do is that you create a cookie on the side of the browser/client and a session on the side of the server that have variable that they use it to compare if the user is logged or not. And the server knows that a sessions belongs to a user. It is similar with tokens, after you log in you receive a token and when ever you send a request to the back you can send your token and that is how the server knows that you are logged. The server knows that a token belongs to a user.
Saying that, sending an encoded password in a post or get method is a really bad idea. If you send and encoded password in a get method for example
http://myserver.com/user/myuser?password="#4$%encodedeapassword&/%EFDASF"
Then you probably recieve that encoded password and decoded in your server.
If I see this as a hacker I can tell that i dont need your password to login I just need your url, I think if someone is just looking at your browser history might be able to login.
Ok so you dont share your computer with everyone. Well then someone with a sniffer might see this address and is able to login, or a sysadmin just looking at the proxy connections or you ISP knows your login.
If you use a Post method instead of GET method you are making it a little bit more secure but still a nosy sysadmin or someone with proxy will know your hash.
In this case knowing your hash is the same as knowing your password.
The idea about using sessions or tokens is that they expire and you can tell the server to kill sessions or tokens.
So for example I log into a computer at work I receive a token and then leave and hours later I go home and log from my own computer. Usually tokens have an expiration date, so if someone goes to my computer at work, he or she wont be able to log if they are outside the expiration date. And you could request the server to kill all tokens that are alive and force the user the log again. And only the user who knows the password can log in again.
In your case once you log in you can tell in your web.xml (there are other ways too) that the endpoint /user/* needs to be secure, so only a logged user can see it.
So now only registered users are allowed to see that endpoint. If you want only the admins to see that depending on the framework you have notations like @RolesAllowed()
And last if you want the user to be able see only his/hers info, with the given token you request the info of the user and that way you know that user123 is requesting the info of user123 if usernames dont match you send and error.
Also, in a side note you should use ssl when you log in to increment your security.
