Pass username and password in URL for HTTP Basic A

Question

When passing username and password encoded in URL, eg: https://Aladdin:[e-mail]/index.html

Is the client in fact sending this in Authorization header? What kind of processing is needed on server side for this kind of URL encoding?

Answer 1

Is the client in fact sending this in Authorization header?

It depends on what the client is. If the client is a browser, the answer is no. Here is the experiment result:

• In Chrome, no authorization header is sent.
• In Firefox, no authorization header is sent. Firefox will also prompt a confirm dialog, as proactively sending authenticate information is weird.
• In Safari, no authorization header is sent. Safari will also display a warning page first, as it suspect the URL is belong to a fishing site.
• In Opera, no authorization header is sent.
• I'm on Mac and can't run experiment on IE/Edge. But according to other browser's behaviour which is reasonable, I guess IE/Edge would act the same. Anyway, I'd appreciate if someone takes an experiment and get the result.

Generally speaking, browser will ignore authenticate information proactively sent in URL, for security reason.

However, if the client is a development tool, the authenticate information may be encoded in base64 and sent as Authorization header. Here is some experiment result:

• In curl, yes, the authorization header is sent.
• In Postman, no authorization header is sent.

Whether the authorization header is sent depends on the tool's design.

What kind of processing is needed on server side for this kind of URL encoding?

In server side, all you need to do is get the base64 encoded string from Authorization header, decode it, and check whether it is valid.

Would it be any different if HTTP protocol is used in example URL?

For security, yes, Authorization header through HTTP is very insecure. Base64 encoding/decoding will not make any security benefit, it can be decoded by everyone.

Otherwise, they are the same.