Insecure Data Submission: Using HTTP GET Instead of POST

  1. Home

What is the Vulnerability?

GET, POST, PUT, DELETE, and other methods have distinct functions in HTTP communication. While POST requests are meant to submit or modify data, GET requests are meant to retrieve data from a server.

Sensitive or changeable information is included in the URL's query string when it is sent via an HTTP GET request rather than a POST request. This makes the data available in:

  • History of the browser
  • Logs from servers
  • Headers for referrers
  • Save links to your bookmarks
A major vulnerability that could result in data manipulation, tampering, and even unexpected actions brought on by malicious links is introduced if the application permits users to submit forms or modify data using GET.
Example:
update_balance
An attacker could modify the URL or craft a malicious link to alter critical application data without proper authentication or validation.

Insecure Data Submission Using HTTP GET Instead of POST -img

Impact of the Vulnerability

Several functional and security problems can arise when data submission is done via GET:

  • Data Manipulation: To change backend data, attackers can directly change URL parameters.

  • Exposure of Sensitive Data: Logs or browser history may reveal personal information (passwords, tokens, and user IDs) contained in URLs.

  • Cross-Site Request Forgery (CSRF): The application is susceptible to CSRF attacks since malicious links or images can easily trigger GET requests.

  • Absence of Input Integrity: There is no defense against inadvertent or repetitive actions, like refreshing the browser and resubmitting a GET request.

Solution to fix the Vulnerability

To prevent misuse of HTTP methods and protect sensitive data, follow these secure development practices:

  • Use HTTP POST for Data Submission:
    • All forms or API calls that create, update, or delete data should use the POST method, not GET.
    • POST sends data in the HTTP request body, which is not cached, logged, or stored in browser history.

  • Restrict GET to Read-Only Operations:
    • Ensure that GET endpoints are used only for fetching data, and that they do not perform any modifications on the backend.
    • Follow RESTful design principles:
      • GET → Read
      • POST → Create
      • PUT/PATCH → Update
      • DELETE → Remove

  • Avoid Including Sensitive Data in URLs:
    • Never send passwords, tokens, personal details, or session identifiers in URLs.
    • URLs are not secure and are often logged or cached by browsers, proxies, and servers.