Field validations

[jdgamble555 (Jonathan Gamble)]

@MichelDiz

Do you have a fundamental reason? Why two typo checks for the same value? don’t you believe in the machine to correct the user?

Yes. It is very easy to hack the front end. It is not on the backend.

@MichelDiz

Typo isn’t security. Why an attacker would force a typo if he gonna have to force it over and over? Unless the typo generates a glitch out something else in the business logic - somehow. If you concern, instead of making a machine to “double-check” should fix the issue at the root of the cause. Right?

I am not sure what you mean here, but it is definitely not just for the purposes of typo checking.

@MichelDiz

This is part of a complex service. You should do it in a Lambda server following some standard out there.

Not necessarily. You may have a field that needs to be checked, isUserValidated, that could easily be check that way.

@MichelDiz

Another business logic rule. You can also do it via Lambda.

Lambdas solve all these problems, but are a pain and way slower than say boolean checks.

@MichelDiz

Really out of scope.

Not really out of scope at all. I don’t want a user to be able to add 100,000 points, instead of 10 points, just by a simple javascript hack. Again, I imagine there are way faster ways to than lambdas to secure this.

@MichelDiz

No DB is safe from a DDOS. No matter what we do, no matter how many typo checks we add. If a hacker wanna DDOS you, he will. Unless you contract some anti-DDOS service like Cloudflare.

Agreed. However, there are great security, and there are poor security practices.

@MichelDiz

So, data validation isn’t about security. Is about data consistency, about the correct format.

Data validation is not just about data consistency. I do not want my app to get hacked. If people pay for features, they should not be able to hack them. This is just one example. I would also argue that data consistency could be a security risk in and of itself.

https://betterprogramming.pub/back-end-data-validations-73ea9004c6d7

@MichelDiz I think this is something that is a necessity for any commercial products, but not in all cases. There is an argument about this:

https://stackoverflow.com/questions/17039934/is-it-practical-to-have-back-end-database-side-validation-for-everything

I definitely don’t think you need to validate everything on the back end, but it is a must for certain things. Again, I have direct experience with this.

Sure, lambdas can handle this, but why not make it easy and faster. Lambdas are a pain. Simple boolean checks would be wonderful. Here is an example of a firestore rule:

let isValidLength = username.size() >= 3 && username.size() <= 15;

All I would have to do is use Chrome dev tools to hack a form. If my page is based on a username, I could permanantly have my site indexed with a username like so:

https://mysite.com/someusernamethatiswaytoolongandthatshouldnotworkatallandkeepsgoingandgoign/post/id…

I do not want this to even be an option.

I am pro this post: http://discuss.dgraph.io/t/moving-graphql-authorization-to-admin-api/13304

Fauna DB (as new as Slash DGraph) currently does not have a solution to this either, and uses something similar to a pre-hook: https://forums.fauna.com/t/data-validation-in-fql-with-abac/329/2

I think a pre-hook may be an option I could be okay with. The problem with lambdas is that I have to basically disable my mutation and create a new one. This is the majority of the painstaking process.

#add-prehook

It would be interesting to hear from other people on this.

Thanks,
J