Is it possible to determine, from the client-side, all the valid fields for a given backend form processor, even if they are excluded from the webpage containing the form?

For example:

Assume a form processor that has multiple HTML forms which submit to it. One form only has 5 fields, a more 'privileged' form might have 10. Nothing prevents the client from submitting all 10 fields by editing the 5-field form, except that they don't know the fields without having seen both forms.

So in this case, the web app developer is attempting to control access to certain functions by excluding specific form fields from a page. Can a user identify which fields are available, but not shown, if they only have access to the limited version of the form?

If the answer is "only through guessing" then is this "security" model considered security through obscurity?

OP Edit - Hopefully adding some clarity.

One application I work with is segmented into multiple modules available to admins for various functions. Admins can be granted access to modules on an individual basis (eg adminA can be given access to module1 and module3 and not given rights to module2). The application then allows admin rights to be managed on a more granular level by adjusting view/edit rights by individual items within the module. However, I have realized that the read only permission is controlled (on client-side only) by disabled form fields and the exclusion of form fields. By knowing the ID of a missing field, I can submit and change values even if the field is not in the page’s source. I can exploit this because I know the name of the missing fields, but how vulnerable is the application to exploitation by individuals who are unaware of the missing field names?

  • 1
    I don't know what you mean by _excluded from the page _. Could you explain more?
    – ThoriumBR
    Commented Oct 17, 2018 at 1:29
  • 1
    As @ThoriumBR said, this is unclear. Please provide some specific examples. The set of generically "excluded" inputs is boundless. Do you have a specific implementation in mind?
    – Xander
    Commented Oct 17, 2018 at 1:31
  • I just made a larger edit than I'm usually comfortable with to try and clarify in terms people will understand more easily. OP and privileged users, please don't hesitate to roll it back if you think I overstepped.
    – gowenfawr
    Commented Oct 17, 2018 at 2:12
  • 1
    Additional field names may be revealed by the framework's error messages or may appear in CSS/JS files. But often, you're left with guessing. However, guessing things like form field names, query parameters or path names is something pentesters regularly do, so don't expect that to be safe. Whether it's SBO depends on your viewpoint. You certainly shouldn't misappropriate undocumented form fields as a security measure.
    – Arminius
    Commented Oct 17, 2018 at 4:04
  • 1
    @gowenfawr good idea on the edit, by and large. I found the changes to the first sentence a little confusing, but I've gone with "let's clarify it further" rather than rolling back :).
    – Soron
    Commented Oct 17, 2018 at 4:05

3 Answers 3


This is not secure! It's security through obscurity, and not nearly enough to protect anything of value. There are many ways an attacker could guess the field names:

  • Guessing. If you write good software your names are descriptive and easy to guess. If I want to delete something, why not try setting delete to 1 and see what happends?
  • Brute force.
  • Having a look at the source code if it's available.
  • If a user has had access to admin level, but get it revoked, she may have saved the names of the fields.
  • Check your collegues browser cache.

Before taking any action, the server must check that the current user has sufficient priveligies to take that action.


You've got some HTML, which omits certain sensitive form fields, right?

There's no real connection between how the backend logic works and how the frontend displays, so in theory it's impossible for a user to know omitted field names just based on the HTML.

That being said, the correct approach is to validate security on the backend, and you shouldn't secure things by merely hiding them from the client application.

By hiding form fields, and using that as the sole form of security, those field names effectively become secrets - similar to passwords or private keys. Some common recommendations for secret information:

  • Randomly generate secrets - it should be effectively meaningless. Do your field names look like "correct horse battery staple" or "gbKtDAABylCGSg"?
  • Secrets need to be closely guarded against disclosure to unauthorized parties. Have you vetted the JavaScript code, backend error messages, etc., to make sure that they don't disclose your field names?
  • Secrets shouldn't go into source control, because that significantly raises the risk in case of a source leak (which does happen at times). (and really, this applies to any situation where you've got security by obscurity)

I'm guessing at least 2 of these measures, or maybe all of them, haven't been done. While it's true that a user can't just magically divine what the missing field names are (so this may not be a "the sky is falling, fix this yesterday" situation), users CAN guess common names, and backend authentication should definitely be used as the actual security mechanism.


In general: if an attacker could break your system just by looking at the source code, then yes, it is "security through obscurity" and you should not rely on it. You need to validate on the server that the user has access to use the fields they are submitting. You have no control over what form an attacker will use to attack your server.

You must log in to answer this question.

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