I read a lot of reports where 'hackers' potentially exploited a 'Hidden HTTP Parameter'. There are also tons of tools which are developed for this exact purpose.

Example : https://blog.yeswehack.com/yeswerhackers/parameter-discovery-quick-guide-to-start/

But what do they mean by hidden?
I could think of 2 scenarios:

  1. The parameter is not visible in the GUI (the browser) but then can easily be viewed by using a proxy such as Burp or Zap, which makes them not so hidden.
  2. The backend developer mistakenly created a parameter 'xyz', which the hacker 'guessed' (used regex or got lucky) sent a GET or a POST request with that parameter, which then got executed in the backend. But for this to work, 'xyz' would actually have to parse that request, so that the payload gets executed. But why would a developer create a parameter like this in the first place, if it doesn't serve a real purpose.

Or is it an entirely different scenario that I can't think of?

  • parameters are used for all sorts of things. This sounds like "form stuffing" and can cause unintended consequences if the developers don't account for it. For instance, ASP.NET used to have a vulnerability where the "entity" would take a field that exists in the model, but is not passed in a form or via URL because it would normally be created or assigned later by the backend. If the unexpected paramater (which is valid to entity framework) is allowed to override, you can have an exploit. Either by being logged in as another user, or posting/updating/viewing another record. Commented Feb 14, 2023 at 20:39
  • this can be a little more hidden in frameworks that bind DB structures to code models (Plain Old Class Objects)... but this could effect any site that doesn't properly check permissions for each record update. Often you'd use the UID of the record for a GET to edit that record. (ex URL/edit.php?id=123) "id" is the parameter, "123" is the value. The form would usually store that ID in a hidden field, but you could override (or "stuff") that and if the backend fails to check permissions for that user, they could then edit another user's record. Code injections are a separate concern. Commented Feb 14, 2023 at 21:00

3 Answers 3


In the context of the linked article, it is not to be confused with HTML <input type="hidden"> elements.

Thoses elements contains name value attibutes values:

  • that move to the URI bar end after ? with their defined key=value pair with the GET method.
  • that move to in the request body with the POST method.

From my understanding, 'Hidden HTTP Parameter' are much closer to what you describe in 2. But with some differences:

The backend developer mistakenly created a parameter 'xyz', which the hacker 'guessed' (used regex or got lucky) sent a GET or a POST request with that parameter, which then got executed in the backend. But for this to work, 'xyz' would actually have to parse that request, so that the payload gets executed. But why would a developer create a parameter like this in the first place, if it doesn't serve a real purpose.

What you describe as 'xyz' is the key of the parameter. The webserver parse all the key=value pair available in the request. Then execute actions based on backend code.

In many cases, when web developpers are working with forms, it is not uncomon that they program some functionalities on the backend that are not used afterwards.

This because of project requirement changes. Or even because the goal of html form tags that they had in mind when they started conception changed. Then they just forget about the extra functionalities that are then left in backend code without any deprecated sign. More dangerously it is still possible for an attaquer to use the parameter and the actions of its backend code despite not being in the html form.

What is possible to exploit from it depends from the coresponding backend code security. But because everybody seems to have forget about the existence of that code/parameter, it is not uncomon for it to contain a vulnerability or permit the exploitation of a vulnerability.

Since the parameter has no <input> field, the attaquer has to guess its key and value. Sometimes with the help of tools that may use brute force or dictionaries to discover parameters.

If you understand correctly, you can no know that it is not impossible that some of the hidden parameters were meant to have an <input type="hidden"> field, but it is purely coincidental.

What you describe in 1. is also not impossible, it is just not what the article is refering to with the 'Hidden HTTP Parameter' name.


There is no such thing as "hidden HTTP parameters". You mean probably the HTML <input> elements of type hidden.

Basically, there are 2 ways how browser creates a request with parameters.

1. Using HTML element <form>

In this scenario a web page contains a <form>. This contains <input> elements like text fields, radio buttons, check boxes, buttons. When user clicks on an <input> element of type submit, browser collects all <input> elements in the current <form> and adds them to the target URL, which is defined in the action attribute of the <form> element (assuming we use application/x-www-form-urlencoded). As a part of URL, they are called request parameters.

For instance, if there is a text <input> element with ID "name" and user entered text "John", the browser will append following to the target URL: ...?name=John or, if there are already other elements: ...&name=John

Some of <input> elements can be hidden. See details here. They behave similar to text fields, i.e. similar to <input> elements of type text, but browser does not display them as fields. That's why they are called hidden. Nevertheless, when user clicks on an <input> element of type submit, not only visible fields, but also hidden fields will be added to the target URL.

2. Using AJAX

In this case the web page may or may not contain <form> element. Usually, there is no <input> element of type submit. Instead, there are JavaScript functions that handle particular events, like clicking on a button that should submit the request. In such case, when user clicked e.g. on OK button, it can trigger a function that programmatically adds parameters to the target URL. These parameters can be be provided by different sources, not only by HTML <input> elements of type hidden, but also by JavaScript variables and JavaScript functions. In such case we usually call parameters hidden, if user cannot change them via interaction with the web page, e.g. via entering text or via clicking on some buttons.

Both cases have similarity: Hidden parameter is a parameter that user cannot change via interaction with the web page.

  • just an added note that most form submissions (since they can change or add data) are POST requests, not GET. So they are not added to the URL. (they are sent in the body of the request) Using GETs for any request that changes data is a very bad practice. Same goes for AJAX calls. Commented Feb 15, 2023 at 18:21
  • @pcalkins: What method for what purpose to use is off-topic on Security SE. But since you mentioned it: Some of your statements are wrong. 1) The most functionality in web applications is related to retrieving data, e.g. searching, filtering, aggregating, requesting some graphical data, etc. Just look how often you search something on Google Maps and compare to how often you add there any data. That's why the most of the requests are GET requests. 2) POST is normally used only to create data. To change data other methods are used, PUT and PATCH. For deletion is usually DELETE used.
    – mentallurg
    Commented Feb 15, 2023 at 20:14
  • if you're going to allow all those verbs also be aware of verb stuffing (or verb tampering) which can be another sneaky way to introduce "hidden parameters". Commented Feb 16, 2023 at 17:45
  • @pcalkins: 1) There is no such thing as "hidden parameters". See details above in the answer. 2) Verb stuffing has nothing to do with HTML <input> elements of type hidden.
    – mentallurg
    Commented Feb 18, 2023 at 20:17

It looks like they are using a pre-determined list of words such as to look for a response.

Arjun can find query parameters for URL endpoints. If you don't get what that means, it's okay, read along.

Web applications use parameters (or queries) to accept user input, take the following example into consideration


This URL seems to load user information for a specific user id, but what if there exists a parameter named admin which when set to True makes the endpoint provide more information about the user?

You can change this word list.

If you are worried about it for your websites, there are more comprehensive tools for that. I use OWASP.

Preventative measures

  • Don't use parameters unless necessary and for trivial things.
  • Use made-up words for params.
  • Instead, use the session and encrypt sensitive variables.
  • For admin mode, for instance, I have used a temporary random token on the session and also saved it in a local table. And I check it on every page/refresh. And it expires after a few minutes.

You are Questioning why a developer would create such a parameter. Only the developer would know this. This is asking for opinions. The issue isn't why these were created but that they may exist.

  • Yes they do, but what I want clarity on is, do any of those pre-determined list of words necessarily need to be used in the backend? Because if yes, that would be another scenario to consider. For example if 'uid' is one of those words in the list. Is it necessary that in the backend, some variable should 'call' or 'fetch' the parameter 'uid' from the HTTP Request in order for the payload to be executed? Commented Feb 14, 2023 at 16:54
  • Edited my answer for it Commented Feb 14, 2023 at 17:06
  • That helps but, the case in my previous comment, is that valid? Commented Feb 14, 2023 at 17:23
  • Your code does not have to call it, the tool is calling your pages with different params to find vulnerabilities using commonly used words. Commented Feb 14, 2023 at 17:38
  • If the backend code isn't calling it, then how is the payload even executing? Take OS command injection for example, for that to be successful, the backend is supposed to call that parameter? (I'm assuming that the parameter is valid and vulnerable) Commented Feb 14, 2023 at 18:14

You must log in to answer this question.

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