DEPEND ON! Just to complete the cake recipe, we have not only GET, but also POST.
The GET and POST methods have different purposes. According to HTTP, GET serves to take resources from a server securely (without changing anything there) and POST to send information to it.
But why do we use GET to send parameters? In search cases, such as Google, profiles and photos on Facebook, etc., it is common to see the parameters in the URL, so that we can copy and pass on to other people, without them having to follow all the steps you've done until reach the desired resource. Look closely (!), They are situations where PARAMETERS are not critical (security), there is no need to hide. In case of LOGIN, PASSWORD, CREDIT CARD NUMBER, among other information, it is not legal to keep running with it back and forth in URLs, anyone can come and see! For this type of personal / private information, POST is used, which sends the parameters in the body of the HTTP request.
So, just to conclude: the GET method is safe, provided it is used correctly, within its scope of use.
Note: According to the documentation, $_GET is not obsolete , what is actually obsolete is $HTTP_GET_VARS .
Using parameters by URL is required in a number of cases and it eases the user experience by favoring a given URL with a parameter for example.
The issue in question is the security of using directly $_GET . Because it is the input easier to manipulate by the user, many security holes are exploited through it.
To prevent this from happening, we should always validate the external contents of our application, this includes the variables passed by GET , POST , etc.
In PHP we can use filter_input() to validate this entry:
<?php
$search_url = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_ENCODED);
The list of filters supported by PHP can be found here in .
GET / POST are methods to receive information, the GET method never ceased to be safe, but a lot of people use it to do #, just that the SQL injection employee with any method of receiving parameters and who should care is the developer.
GET / POST are ways to send information , so there is no difference in security between them, except that the user can more easily manipulate the parameter passed to his script.
On the sites you say, I believe they do not use GET because they should be using friendly URLs (they still get the parameters by GET, and they only change the way they are sent.) They go without the "parametro1 = value1 & parametro2 = value2", generally go like this "/ parametro1 / valor1 / parametro2 / valor2") , this helps to maintain the semantics and it is best to Index content for Web Crawlers .
NOTE: $ _GET is not deprecated.
About $ _ GET it is not deprecated in php.net a>, which is obsolete is $ HTTP_GET_VARS . It contains the same information initially, but it is not a superglobal. (Note that $ HTTP_GET_VARS and $ _GET are different variables and that PHP handles them differently.)
The purpose of this answer is to clarify and put things on the axis.
Regarding data processing to make a request or data transmission secure, the 4 existing responses up to the date of publication of this answer are enough to understand the basics about sanitizing, filtering and validating data, so , let's begin to unravel the subject:
$_GET
This global variable is used to retrieve data received by the GET method.
Simple like that, there is not much to say.
Manual: link
This is a subject that has nothing to do with PHP.
HTTP is a protocol used to transfer "hypertext" (Hypertext Transfer Protocol). General information on Wikipedia: link
So the HTTP protocol is one thing and $ _GET is a PHP resource.
A request by the GET method does not necessarily have parameters. An example, when entering the following address in a browser: link , will already be sending a request by the GET method. This is the default method of sending data.
We recommend sending only non-sensitive data . Private information such as passwords, credit card, login, etc. is considered as sensitive data.
The reason for not sending sensitive data by the GET method is that it is visibly easy for anyone to get such data, even offline, because URLs are usually cached on the user's device.
However, even the POST method should not send sensitive data without encryption.
In summary, there is generally no problem sending data by GET or POST or other REST methods .
Part of the problem is the sloppy way people pass information, in order to summarize a subject, they end up teaching in an inappropriate way. For example, the question that made does not make the slightest sense. But I believe it is due to a subject that was addressed in the other answers, which is the treatment and validation of the data received.
Validation of data, both by GET and POST, if not done correctly can lead to serious security problems.
Sending the data itself has no problem because this is the HTTP protocol. What will affect the security or correct functioning of the receiving system, ie the responsibility of what will be done with the data received is entirely the system that receives the data. It is also valid to point out that depending on the type of data being received, who sends also has responsibility, see what I mentioned above about sensitive data.
The HTTP protocol itself is just a road through which the data travels.
In my opinion, it depends on the type of information you are going to display there. If it's just setup, or a code that does not get you anywhere, I see no problem. Probably this kind of parameter is what you still see on Facebook, for example. But the ideal, and more elegant, would be to expose nothing and pass everything internally. Why is this type of code still there? Probably because it's legacy code, and it works.