> Also kinda anoying to have to duplicate this tho
Oh yes it is...
I once worked on a project where we had a tool that dynamically built client-side forms based on each customer's needs. After rolling it out for a big customer I discovered (after the original engineer responsible had already been fired for other reasons) that all of our dynamic forms had NO server side validation. none, zilch, nada.
We did have client side validation though, a good amount of it and nearly all of it was using native HTML features, and we had the whole form available server-side as well. So given that I was under a crunch, on form submission I loaded the HTML form server-side, manually iterated over all the elements and re-implemented the validation checks that were embedded in the HTML. Crazy times, but heck it was flexible!
I think it's a trilemma between security, convenience, and architectural sophistication (NB: I'm deliberately not saying complexity, because the code doesn't necessarily get more complex). It is usually physically possible to find a solution with equal security for a given level of convenience, but it will require an investment of creativity and possibly refactoring to realize. Both of those things are very expensive.
To take an extreme example, you could ensure that validation happens identically on both the back and front end by writing your own framework with that property. You could create a framework with no more security bugs than the next best alternative and while providing great UX. But writing a framework and shaking out the bugs is a huge lift.
So in practice you can't go all the way out on the third axis and it is approximately a dilemma. But if you're on the lookout for exceptions you may find an opportunity to cheat/curve bend (eg as suggested by other commenters, when using JS for the front and backend, you can use data modeling libraries like Zod to get most of the benefit for a fraction of the price of writing a framework).
> (NB: I'm deliberately not saying complexity, because the code doesn't necessarily get more complex)
the context was already lamenting the duplication of code, which in itself is a form of inconvenience, as you kinda admit; because generalizing it to "complexity" would be forgetting the possibility of adding resilience, and adding stuff doesn't necessarily mean anything gets more complex - just more entrophic, the stuff added may not be optimal.
> But writing a .... is a huge lift.
And also the only way to minimize the security risk; by rewriting/auditing/formalizing.
Ultimately the risk transformation is exponential; don't roll your own crypto, don't DIY authentication/authorization, don't risk your own inconvenience and assume security.
However the opposite, to use all the "agreed"-upon code, introduces a near similar surface area of risk, simply spread across more vectors. And because the vectors are spread, and the system is more complex, the dissolution of responsibility leads to the opportune laziest option - patching code together, trusting it works.
it would be wise to question why this convention is so normalized.
Just to put it on the record I am happy to acknowledge that duplication is an inconvenience as well as a security issue.
Your point about trusting conventional code is well made and important. Once I repeated that I shouldn't roll my own crypto. A cryptographer shrugged and told me, I mean, somebody has to write it, and that person might be you. (That person isn't me. I don't roll my own crypto. I do roll my own auth, because I'm comfortable with my understanding of authn/authz attacks. Use my software at your peril.)
Regarding complexity what I was thinking is that, after a lot of clever reflection, you might realize the proper solution is actually to take something away. To give an illustrative though not very realistic example, you might realize you didn't actually need a web backend at all and that the app can function local-only. Thereby solving your UX and security issues - client side validation is now completely acceptable. This architecture is simpler (less complex) in that the diagram contains fewer elements, but more sophisticated in that it contains more baked-in wisdom about how your normally web-based application can fulfill all it's requirements locally.
>To give an illustrative though not very realistic example, you might realize you didn't actually need a web backend at all and that the app can function local-only.
ssshhhh, don't give away the only secret that keeps us employed.
if they knew for certain our stuff wouldn't break, we wouldn't had been kept around.
But dont remenber to also verify serverside. Anything clientside can have been fumbeled with. (Also kinda anoying to have to duplicate this tho)