Universal Form Handler

Question

I'm building a API that gets called from web / mobile applications written using Ionic (web languages on mobile), which uses Angular.js.

We want to be able to do server side validation of forms but don't want to have to rewrite functions constantly to match each form. However, we need to make sure the forms are verified completely, containing all intended fields, and having no extra fields, Since form submissions like this are easily modified by the user.

Would having a universal handler for the form be a good idea? Something that looped through all submitted fields and using a switch to match their type to a certain formatting? And to ensure it was the right set of fields, having a form identifier that reads the list of fields it should have from a database?

Answer 1

Many discussions on this subject on StackOverflow are against your approach. I forward you, for instance, to this answer as well as to the post it linked to.

However, your approach is the right thing to do for the simple reason that it reduces the attack surface area; and I may be it is a good idea to quote you this this real world example to highlight the benefits of your approach:

The application allowed the user to specify the language to be used for the interface. The parameter specifying the language was included 3 times as part of each returned page. Each time it was validated differently, leaving one instance open to cross-site scripting attacks. Obviously, the developer for the application did not implement a centralized and consistent set of input validation functions.

Also, your approach is mentioned as a safe cooding practice in OWASP Secure Coding Practices Checklist.

If you want to go further in the perfection of your approach, you may follow this advice from OWASP Secure Coding Principles¹:

It is a fine thing when implementing data validation to include a centralized validation routine for all form input. However, it is a far finer thing to see validation at each tier for all user input, coupled with appropriate error handling and robust access control.

---

_{1. By the time I mentioned this, the OWASP page was last modified on 21 January 2016}