I quite often see opportunities to optimise server-side code if HTML form names are exactly the same as the database field names they eventually update.

The drawback obviously is that this is exposing information about the database structure in plain sight.

Of course this information is only useful if other weakness exist but it does seem like handing information on a plate.

I'd be interested to know if people think this is low risk and if they do expose field names like this without worrying.


It is very common to do this. As you've noticed, there is a significant benefit for keeping code simple.

If you do have an SQL injection vulnerability, an attacker can figure out your database structure using INFORMATION_SCHEMA. So hiding your database structure doesn't help you a great deal.

Another concern in this area is Mass assignment vulnerabilities. Perhaps a user is allowed to update their user details - name, email, password, etc. But they are not supposed to be able to update the field "is_admin". With code that automatically routes form fields to SQL statements, sometimes vulnerabilities like this can appear.

  • For the attacker to be able to exploit INFORMATION_SCHEMA, this particular injection must be able to return ample amount of data back to the attacker, which is not always the case. – Dmitry Grigoryev Jan 7 '16 at 14:17
  • 1
    @DmitryGrigoryev - you can use INFORMATION_SCHEMA in a blind injection. sqlmap does it well – paj28 Jan 7 '16 at 14:18
  • Could you elaborate, or give a link on this? My experience tells me that with a blind injection you often have to guess table and field names char by char, as in this example. If you don't call your table "users", it may take a while. – Dmitry Grigoryev Jan 7 '16 at 14:29
  • 1
    @DmitryGrigoryev - You could look in the sqlmap manual. If you try sqlmap against a blind injection, it can enumerate tables, columns, data, etc. – paj28 Jan 7 '16 at 14:35
  • 1
    I have learned something today! (c) Updating my answer to make it look less lame. – Dmitry Grigoryev Jan 7 '16 at 14:51

One common scenario where disclosing DB field names to the attacker ruins the security is SQL injection. In this case, the attacker may not be able to execute show tables, select * from INFORMATION_SCHEMA.TABLES and the like, to get the whole database structure. He may have very limited read access (e.g. blind SQL injection). Figuring out the DB structure in such cases may require some time and knowledge.

If you give the attacker hints about DB tables and fields, he may just try out several injections using the names you provide him. The attack will be much faster, require less qualification from the attacker, and much more difficult to detect in the logs.


I think exposing database fields names is not a good practice but it is not that high risk for the fields themselves, because in order to access those fields, one has to hack your database credentials , and once the credentials are stolen , then it doesn't matter they know the fields already or not , they will explore it themselves what they want.

Having said this , the exposed database fields may be used for some other kind of security attack. (at Information gathering step)

The conclusion is : Never expose the fields names if you don't have to.

  • I agree, though if you ever find an unescaped input and you know the field names....GG – TheHidden Jan 7 '16 at 13:41
  • I don't understand what the low risk is. If you (the defender) and I (the attacker) both know, understand, and follow best practices and I understand your problem domain pretty well, then I can probably come up with a schema (including field names) that is very similar to yours. – emory Jan 7 '16 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.