Let's consider the scenario, where we have a nefarious (and clever) user who knows how to short circuit our client-side validation logic. It's JavaScript after all, and it's running in the web browser. There's really nothing to stop a malicious user from throwing our client-side validation logic to the wind. To simulate such a tampering event, we simply need to assign the Boolean value of true to the clientSideValidationResult variable in the contact.go source file like so:

func handleContactButtonClickEvent(env *common.Env, event dom.Event, contactForm *forms.ContactForm) {

  event.PreventDefault()
  clientSideValidationResult := contactForm.Validate()

  clientSideValidationResult = true

  if clientSideValidationResult == true {

    contactFormErrorsChannel := make(chan map[string]string)
    go ContactFormSubmissionRequest(contactFormErrorsChannel, contactForm)

    go func() {

      serverContactFormErrors := <-contactFormErrorsChannel
      serverSideValidationResult := len(serverContactFormErrors) == 0

      if serverSideValidationResult == true {
        env.TemplateSet.Render("contact_confirmation_content", &isokit.RenderParams{Data: nil, Disposition: isokit.PlacementReplaceInnerContents, Element: env.PrimaryContent})
      } else {
        contactForm.SetErrors(serverContactFormErrors)
        contactForm.DisplayErrors()
      }

    }()

  } else {
    contactForm.DisplayErrors()
  }
}

At this point, we have bypassed the real result of the client-side validation, and we are forcing the client-side web application to always green light the contact form validation performed on the client-side. If we were solely performing form validation on the client-side, this would put us in a very bad situation. This is exactly the reason why, we need the second round of validation on the server-side.

Let's open up the web browser and partially fill out the form again, as shown in Figure 7.24:

Note that this time, when the Contact button is clicked, the XHR call is initiated to the Rest API endpoint on the server-side, which returns map of errors in the contact form, as shown in Figure 7.25:

The second round of validation, performed on the server-side, has kicked in, and it prevented the malicious user from being able to reach home plate and score a run. If the client-side validation is unable to properly function, that incomplete or incorrectly formatted form field will be caught by the server-side validation. This is a major reason, why you should always implement server-side form validation for your web forms.