I am wondering if using the HTTP GET method over HTTPS to pass a username and password to a middle tier application would be safe.

Essentially I am considering using a PHP include statement to communicate the information between the front end and application server and I am thinking that this information will not be logged into a user's browser history as it is an include statement.

The alternative that I am using is curl and POST, but it is more complex than a simple include.

Any help on this would be greatly appreciated.



2 Answers 2


The HTTP GET method should be never be used to transmit sensitive information such as credentials.

I do not see why the HTTP GET method is easier than using the HTTP POST method, see the difference in code below.

I suggest to create an API that handles the authentication and communication to the back-end server.

Since you mentioned you're going to use PHP, have a look at this API framework: http://www.slimframework.com/

Theoretically the parameters in the URL will not show up in log files since you're using HTTPS. However, there are for example, corporate proxies that perform man in the middle attacks to inspect all traffic.

In these cases, the credentials will show up in the proxy logs and this is considered a bad practice.

Here's some PHP code (which requires sanitation):


  $username = $_GET['username'];
  $password = $_GET['password'];


This example is wrong because:

  1. Sensitive Information is transmitted in the URL
  2. No input validation has been done

This example is a little better, but still requires you to perform input validation:


  $username = $_POST['username'];
  $password = $_POST['password'];


That's the different usage between the HTTP GET and HTTP POST method using PHP (and of course your form method should be set to POST in stead of GET as well).

  • Its best to consider the entire URL (request and query strings) as being logged regardless of whether SSL is used as this is best practice. Jan 3, 2016 at 1:01

I am thinking that this information will not be logged into a user's browser history as it is an include statement

If the password originates on the browser as a GET parameter then it will be available in the browser history. If the PHP is acting as a proxy and adding the username and password, then it won't be in the browser history. However passwordless access is now granted to anyone who can point a browser at the site (in the absence of additional security constraints).

If the "application server" is on a separate host from the PHP code, then yes, you can pass a href to the include function to present the content to the browser, however:

1) it opens a big security hole in your system - if someone can trick your code into reading content from a website and the content contains PHP code, it will be executed

2) you can only do GET operations and on a single content type - all the headers from the backend system will be lost.

If you're happy to just add the username and password then a better solution would be to do this with Squid and a URL redirector.

It would help to know what you are trying to achieve - why you don't change the code in the "application server" to handle authentication in a different way (e.g. using SSO)

Not the answer you're looking for? Browse other questions tagged .