Other than over your shoulder peeping, if a password is sent using GET in plaintext over an encrypted connection, are there any extra security disadvantages or is it the same as POST?
Asked
Active
Viewed 227 times
1
-
I'm not sure if this is really a duplicate. The linked question is marked as a duplicate of a question which asks if GET parameters are encrypted when using HTTPS. This question seems to be more about sending confidential data via GET. But it does seem to be a duplicate of [Using GET to submit username/password?](https://security.stackexchange.com/questions/43470/using-get-to-submit-username-password) – tim Jun 30 '16 at 20:33
1 Answers
7
No confidential data should ever be sent via GET.
The data may be leaked or stored by:
- referers if you link to a different page after a login
- your server logs which is an issue if these logs are ever available, for example via LFI, wrong server configurations, backups, etc.
- browser histories which is an issue if multiple people use the same browser - eg in companies or in public libraries -, or even by other websites if history sniffing is an option.
- proxy servers that can decrypt the requests
- users sharing links
The CWE for this issue would be CWE-598.
![](../../users/profiles/8754.webp)
tim
- 29,018
- 7
- 95
- 119
-
1Great answer! I would like to add that some frameworks don't do CSRF checks on GET requests. That would open up the webapp to login CSRF. – Anders Jun 30 '16 at 20:22
-
@Anders very good point. And frameworks have a good reason not to do CSRF checks on GET requests. If a CSRF check would be performed, the CSRF token may be leaked as well, which is why all requests that change state should be POST. – tim Jun 30 '16 at 20:26