Home > OS >  why validate both the post request and the database schema in the backend?
why validate both the post request and the database schema in the backend?

Time:01-10

Abstract: should I use express-validator if I can validate data using mongoose schema?

I'm a front end developer, and I usually do some validation on the form before submitting. Now, I've started studying express.

One of the first things I did was receive a form and validate it using a library called express-validator, then the database operations were done. very simple, no big deal. However, after doing a project by myself I realized that mongoose itself could handle the errors, not only that, but it was quite easy to return these errors on the front, especially in the case of an api.

So that is my doubt, why validate this data so many times? I know that database schemas is not only to do that, but doing theses things once in front and twice in backend cause too many repetition and may be a little hard to maintain.

Here goes a few lines of code only to illustrate the case. Don't judge me, I'm still learning.

import mongoose from "mongoose";

const TaskSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true,
    trim: true,
    maxlength: 20,
  },

  description: {
    type: String,
    required: false,
  },

  completed: {
    type: Boolean,
    default: false,
  },

  date: {
    type: Date,
    default: Date.now,
  },
});

export default mongoose.model("Task", TaskSchema);
import taskModel from "../models/tasksModel";

export function createTask(req: express.Request, res: express.Response) {
  taskModel
    .create(req.body)
    .then((task) => res.status(201).send(task))
    .catch((err) => res.status(400).send(err));
}

CodePudding user response:

The thing is that you have both basic and business requirements. Meaning that by declaring database tables (collections), its properties, data types, constraints etc you setup, so to say, basic data structure. But you can also have extra business requirements, that probably won't be covered by the database syntax.

For example, you have in input as array of objects, that should be then saved to database. Probably you would like to prevent passing dublicate objects.

By different conditions (user roles, permissions etc) your data can be validated through different validation schemas.

Also it's a common case that you validate your input and transfer it to various layers, modules, components of your application as DTO.

At last but no least, SQL injection can be made by simple 'consuming' not validated data by database.

CodePudding user response:

On the frontend each user works with their own copy of the application which runs on a single laptop and accepts input from local system or known web resources.

On the backend all users work with a single app which runs on the shared infrastructure and accepts inputs from the Internet.

Serverside validation is required to ensure data integrity and security as you have no control on where HTTP requests come from and what payload they deliver. Even legitimate clients may lack clientside validation if your api is called from a script. Invalid or malicious request can affect all users. Data loss may not be recoverable.

Client side validation is optional and is there to improve UX and provide instant feedback on invalid input - you save on HTTP roundtrip and can validate fields in isolation before whole form is completed and submitted to the server. Security-wise client side application affects only current user and can always be restored to the initial state by reloading the web page.

  •  Tags:  
  • Related