5.6.2 Adding Server-side validation proposal

[mesutgungor]

In 5.6 Validation and Sanitization Architecture Although "trusted service layer" covers it, I would propose adding "server-side(back-end) validation" explicitly to make it more clarified.

Current :

#	Description	L1	L2	L3	CWE
5.6.2	[MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability, security must not rely on it.	✓	✓	✓	602

Proposal	#	Description	L1	L2	L3	CWE
5.6.2	[MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability, security must not rely on it. Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations.	✓	✓	✓	602

[elarlang]

For me the proposed phrase just duplicates the requirement and does not provide anything extra.

[mesutgungor]

I would partially agree and also mentioned. But It feels like a bit implicit to me if we divide the requirement

• The requirement : Verify that the application is designed to enforce input validation at a trusted service layer.
• How not to do it : While client-side validation improves usability, security must not rely on it.
• How to do it properly : Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations.

[ryarmst]

Would it be suitable to use the Glossary (Appendix A) to provide an expanded definition of and examples of "trusted service layer"? Notably, the top Google search results for me all come from its use with the ASVS. I see it is currently defined in V1.5.

[tghosth]

I would partially agree and also mentioned. But It feels like a bit implicit to me if we divide the requirement

• The requirement : Verify that the application is designed to enforce input validation at a trusted service layer.
• How not to do it : While client-side validation improves usability, security must not rely on it.
• How to do it properly : Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations.

I think the requirement could be slightly clearer based on this structure but I agree with Ryan that I prefer to keep the trusted service layer terminology but make sure it is sufficiently covered in the glossary

[elarlang]

https://github.com/OWASP/ASVS/issues/1553 - in this issue, there is a discussion of how and why we reached the current requirement text.

[tghosth]

Ok so I added a minor clarification to 5.6.2 and also added trusted service layer to the glossary. @mesutgungor

2018 for your approval @elarlang

[elarlang]

Well, seems that the PR is merged already.

I really don't think we need " as it can be bypassed" to the requirement.

bypass - for me it is a situation, when there is proper defense in place but there is some mistake in program code that gives you opportunity to send the parameters in a way that security mechanisms are not exectuted.

In this context is not the case - client-side validation is just a usability on the client side and from the server-side/trusted service layer point of view, when communicating with the service directly, there is nothing to bypass. You just skip the UI part.

[tghosth]

Can you think of a better way to word this?

[elarlang]

We just don't need this phrase in the requirement, it does not give anything extra.

Trusted means that we are not concerned that an untrusted user will be able to bypass the control.

The description part, maybe we should go with message like (input for wordsmithing): Trusted means that we are not relying on a client-controlled layer such as JavaScript executed in the browser as it is possible to communicate with service directly without JavaScript code providing any effect to the data quality.

[tghosth]

Discussed with @elarlang

@set-reminder 7 days @tghosth to rollback addition to requirement and update the glossary.

For glossary:

...that an untrusted user will be able to bypass or skip the layer or controls implemented at that layer.

[octo-reminder[bot]]

⏰ Reminder Thursday, August 22, 2024 12:00 AM (GMT+02:00)

@tghosth to rollback addition to requirement and update the glossary.

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to rollback addition to requirement and update the glossary.

[tghosth]

Ok @elarlang can you confirm your approval on #2025