Email and password passed as GET parameters, obviously

That is just a noob mistake and trivial to fix.

Some of the more severe stuff i saw in the wild:
- Checking user input client-side only.
- Not using stored procedures leading to SQL injection opportunities.
- Hardwired master passwords (not even hashes).
- Missing authorization checks leading to anyone being admin who can guess some URL parameters right.
- Not escaping persistent user input on HTML generation leading to cross-site-scripting attacks.
- Not using cross-site-request-forgery-prevention tokens or storing them in a cookie (rendering them useless).
- Not honouring the DRY principle - leading to hundreds of places that have to be fixed when bugs are found.
- Not honouring the KIS principle leading to loads of edge-case-specific code paths wich never get any test coverage (neither human nor automated).

I am not a security researcher. This is all just common stuff most of the sites out there get wrong.

fyi it was/is part of official rfc and was widely used before web browsers and/or internet become popular

not exactly how you probably think of “as parameters” but cause you didn’t precisely wrote what parameter is, this is how original internet address ( url ) protocol rfc1738 looks like

//<user>:<password>@<host>:<port>/<url-path>

It’s just browsers implemented it so ugly it got deprecated.

for me it’s pure beauty in its simplicity

Are we talking about query parameters? because sending "?username=&password=&grant_type=password" as query params is also a standard for oAuth2 authentication.

it shouldn't be an issue if its over https and once you have your token back you don't have to resend it anymore. Unless ofc you're saying someone was sending it *with each* request...

@Hazarth it's always an issue. From caching issues to logs that may end up God knows where.

Oauth is a completely different issue as no reusable parameters are ever send over GET