Skip to main content

How Does The Platform Handle Spurious Submissions and Secure Forms?

Spurious submissions

The runner (deployed form) checks that the given user answers match a valid traversal through your form, ie if you form has 10 questions with multiple branching routes where only 6 will be answered, it will check that the supplied 6 answers could be a valid form. The code for this can be viewed here. This prevents real users sending incomplete forms or manually entering page urls to bypass some questions.

The submission is then sent to the submitter API, which will validate the schema - this is relatively naive in that it really validates that there are answers present, but prevents bots and web crawlers hitting the submit route from sending empty submissions.

It is possible to write scripts that fill in forms with junk data, in fact our acceptance tests programatically fill in forms and inspect submissions. There is an inherent risk in publishing a form available on the internet and each submission received should still be validated as part of the operational process.

Malicious input

All user entered values are passed through Rails sanitize to prevent injecting scripts or tags. We use ActiveRecord to handle preventing injection into our own databases and strong parameters to discard malicious form data.

User uploaded files are held in temporary quarantine and scanned with CLAMAV, virus definitions are updated daily.

DDoS

Forms are given their own cloud resources on publish as part of the cloud platform Kubernetes cloud. Forms have multiple ‘pods’ which can increase resources dynamically based on load and ensure redundancy.Each set of pods has its own network ingress which is protected using the modsec web application firewall, which includes throttling and DDoS protection. This means -

  • Individual forms can handle spikes in traffic
  • DDoS level spikes should be throttled by the firewall
  • If a given form is receiving malicious/excessive traffic, other forms on the platform should not be affected
  • We have robust alerting and monitoring, as well as office hours active support so in the event a DDoS attack was able to bring a form down, we would be able to respond.
This page was last reviewed on 20 June 2024. It needs to be reviewed again on 20 December 2024 .
This page was set to be reviewed before 20 December 2024. This might mean the content is out of date.