Security and data format for a Survey Solutions registration system

In a recent conversation with a colleague, we have discussed security requirements for a multi-step interviewing system built around Survey Solutions. The schematics of it is roughly as follows:

Here User1 can access a custom-written registration web form and submit some data, including contact information of another person. This information is then processed by the back-end, which is custom-written for this project and uses API calls to generate web-assignments on a Survey Solutions data server based on the information submitted by User1. The server then invites User2 to take an interview by sending an email with a web-link and password to it.

My colleague has a concern that the Survey Solutions data server doesn’t validate the data submitted in the assignment-creation calls to match specific business rules, and there is no place to specify this desired behavior in Survey Solutions.

Indeed, this is the case, but in a system setup shown, the assignments are created based on calls received from the back-end, which are conducted using a secured channel and authenticated using the API user credentials (login+password or access token). Thus the burden of validation should be placed on the back-end processing part, that should inspect the data received in step #2 from the web-form filled out by the user and refuse to generate a new web-assignment (step #3) in case of any critical inconsistency.

The checks performed in the registration web-form itself may be used as convenience to provide immediate reactions while editing the form, but not replace the check by the back-end, in case a malicious user attacks the back-end directly, bypassing the web-form.

NB that the validations you include in the questionnaire carried by the web-server are typically soft validations (with a handful of exceptions) and thus they are not going to block creation of assignments, but will simply raise a red flag/error in an interview.

1 Like