How secure is HTTP GET when URL encoded data?

Question

If the data is Url Encoded, is it safe enough to send credentials via HTTP GET?

Answer 1

Not at all. URL encoding is easily reversible. You must encrypt the transport layer (i.e. use HTTPS)

Answer 2

No. The URL encoding is intended to make sure that all the characters you are trying to send with a GET request can actually come to the other end.

It is actually designed for easy encoding and decoding to prepare data for transport, and not for security.

Answer 3

URL encoding is not a type of encryption, it just prepares a string for sending over the network.

If your data is sensitive, GET should be completely excluded. The reasons for this?

• Obvious, anyone who looks at the URL bar will see the data
• Data will be left in each proxy protocol that will pass through
• If the user leaves the site, the next site will display the URL recorded in it by the logs / web statistics (REFERER).

Answer 4

Read URL Encoding Purpose

The URL specification (RFC 1738, December '94) poses a problem because it restricts the use of permitted characters in URLs to only a limited subset of the US-ASCII character set.

HTML, on the other hand, allows the use of the entire ISO-8859-1 (ISO-Latin) character set in documents - and HTML4 extends the range to include the entire Unicode character set, In the case of characters other than ISO-8859-1 (characters above FF hex / 255 decimal in Unicode), they simply cannot be used in URLs, as there is no safe way to specify character set information in the contents of the URL but [RFC2396.]

URLs must be encoded throughout the HTML document referenced by the URL to import the object (A, APPLET, AREA, BASE, BGSOUND, BODY, EMBED, FORM, FRAME, IFRAME, ILAYER, IMG, ISINDEX, INPUT, LAYER , LINK, OBJECT, SCRIPT, SOUND, TABLE, TD, TH and TR.)

Security is not the point. As already noted, HTTPS should be used when necessary.

Answer 5

URLEncoding is for coding / transmission, not security.

Answer 6

Not at all safe.