I am working on an iOS app that will be sending the user's username and password for each URL request. Currently, only because for simplicity until it's ready to be launched, the username and password is being passed over HTTPS in a GET request like the below.


The HTTPS secures the parameters for transmission, but I know that the security concern with this is that the URL can be stored in browser history and any server logs.

My question is... if I get rid of passing the username and password like I currently am doing and I base64 encode them prior to being sent, include them in the header like below, is this safe? Will the username and password be stored in any history or logs?

Authorization: Basic aHR0cHdhdGNoOmY=

EDIT: I already know base64 can easily be reversed... that's not what I'm asking about. I'm just asking about the security of putting usernames and passwords in HTTPS GET parameters vs. the header.

UPDATE: I am now using basic authentication for the login endpoint and returning a JSON Web Token to be used for all requests thereafter.

  • Why not just use a POST body? It's common to only log the query part but in theory a server could also log body and headers.
    – Arminius
    Dec 28 '16 at 17:43
  • 1
    Base64 encoding will not protect the data. Why not design the application properly from the start?? Is it really that much simpler than having to go back and change code? Dec 28 '16 at 18:50
  • 1
    @user1801810 OP is not concerned about MITM attacks (which he mitigates by using HTTPS) but about credentials being sent in the URL.
    – Arminius
    Dec 28 '16 at 18:53
  • @user1801810 I know base64 will not protect anything... that's not what I'm concerned about.
    – Alec
    Dec 28 '16 at 19:07
  • 1
    Why not send the credentials within a post request? It would minimise credentials visibility
    – Miguel
    Dec 28 '16 at 21:51


Commonly authorization headers are not logged but, of course, one could configure the application or server to log these data. Thus check your setup.

As for storing in the history: In case of a browser, such credentials will not be stored in the history but might be stored similar to cookies and automatically sent when visiting the site. Yet, since you are not using a browser but your own app, it is up to you how you manage this information.


You should use a temporary token after the first exchange, to avoid transmitting the real credential with every requests. Thus your apps only have to remember the temporary token, not the full credentials.

And yes, it's better to put it in the headers than in the url:

  • For OP's benefit in doing future research, this would typically be called a "session ID". Not everything would call it that, but that's the most commonly used terminology. The typical workflow then is to login to get a session ID and then that session ID gets transmitted with all future requests for authentication. Cookies are often used for this (that's how websites remember your login).
    – Kat
    Jan 4 '17 at 1:53
  • @Kat yes, and in the https context, they are "TLS session ID", which mean some ting else.
    – Tom
    Jan 4 '17 at 10:21

I am not entirely sure whether the OP is asking outright whether the scheme is entirely safe once headers are used:


...or, if the question only relates to client-side logging, and not the overall safety:


However, assuming the question is of overall safety, I'd like to make the point that although the OP is using HTTPS, my understanding is that transferring the credentials over every request is considered bad nowadays because MITM replay attacks are still possible (even though HTTPS is employed). Therefore, even when using HTTPS, a token scheme such as JWT should be favoured over using Basic Authentication on ever request.


is this safe?

Not especially. Base64 encoding can be easily reversed.


Maybe, not really possible to tell from the information available. It is, of course, possible that the data would be recorded in a MitM attack.

This really comes down to a question of risk. Is it good practice, absolutely not. Would it be suitable for Financial/Health records, certainly not. Would it be good enough while testing a new product, almost certainly, especially if you are not recording live data and will reset the database before go-live.

  • 6
    Note that OP is comparing HTTP Basic Auth (with Base64) over HTTPS against URL GET parameters (fully in the clear) over HTTPS.
    – user
    Dec 28 '16 at 19:11
  • 2
    I understand base64 can be reversed... that's not my concern. All my concern is is the security of putting usernames and passwords in the get request vs the header. What are you saying is not good practice exactly Logging? I'm a little confused by that.
    – Alec
    Dec 28 '16 at 19:12

I think your overall approach is fundamentally flawed. While I can fully understand where you are coming form, your overall approach is misguided.

One of the big contributors to the poor level of security in many applications is due to leaving security to a later stage rather than building it in at the beginning. Too often, the approach is "lets just get the app working and we will deal with security once we have the basic functionality working.

The problem with this approach is that getting the basic functionality to work will often establish restrictions and guide design in such a way that your options when it comes to security become limited.

This is completely understandable. When you sit down to right the new killer app, you want to focus on the cool parts - the key functionality you want to see and you want to see real progress. Often, there are managers and decision makers who increase the pressure to produce something to see. All this secuirty stuff is just scaffolding which gets in the way - a sort of necessary evil.

Unfortunately, all too often, this results in a lack of emphasis on the security. Either the design makes adding in sufficient security too hard or other pressures, such as delivery deadlines, mean corners are cut.

Start witht he security model. Get that working and then start with the app functionality. It will result in a better design and something which is easier to maintain. In this specific case

  • Yep, definitely get rid of the GET parameter approach.
  • Forget about the base64 encoding. It isn't really buying you anything and is likely to create a false sense of security.
  • Look at ways to minimise the need to send the password or even the username. Consider using some sort of authentication token.
  • Make sure your tokens are encrypted.

There are many advantages to using an authentication token rather than just username and password. You can encrypt additional information into the token, such as expiration time. I have even seen tokens which include client details, such as the browser version and OS information, which can be used as a type of fingerprint.

The main advantage of using a token is that your only passing around usernames and passwords an absolute minimum number of times. The less you need to send this information the better. However, to use tokens effectively and in a secure manner, they need to be designed into your application and not tacked on afterwards.

the other advantage in building this into your app from the start is that you can more easily test the various different approaches and libraries out there. There are a number of different token based authentication and authorisation solutions out there and you need to identify which one is best suited to your architecture, language and platform. Get this right at the beginning and the rest will fall into place far more easily than trying to retro-fit it to an existing code base.



You will mitigate the GET risk at least, as typically no header logs are captured in a proxy or a web-server.

But better to use HTTPS within your application as you don't have to purchase a digital certificate if you are dealing with your own web-server. You can utilize Certificate Pinning and self-signed certificate will be secure enough: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning.

  • 2
    OP is already using HTTPS.
    – user
    Dec 28 '16 at 19:09
  • HPKP and pinning a self-signed certificate are two different things
    – Tom
    Dec 28 '16 at 22:18

Your Answer

