AppSec interpretation of guidelines, eagerness of engineers and operational pains

As an Engineer we go through the cycles of feature completion and then Application Security reviews with AppSec engineers, Penetration testing to make sure our application is safe for our customers. One of the most painful parts of this process in my view is to go on long Slack Threads or meetings to make sure engineers understand the different between Input Encoding/Input Validations to avoid injections attacks vs Output encoding. It must be simple right? It isn't as all the documents are confusing from context point of view and leads to engineers understanding it wrong and limiting their views to prevention of problems and avoiding the impacts of these changes in future of product lifecycle.

Looks at the OWASP section for injection, It is detailed from one broad context but isn't detailed enough to explain what to do in other cases. e.g., It talks about prevention is quite convoluted way:

It explains what to do but fails to explain `When`, So when people read it, they end up interpreting it as input validation to solve all their problems and that is where the problem lies. Why is it not good enough?

Input validation is part of prevention but not enough as not always at the input layer you have enough context of the way the data would be interpreted, Without knowing these, any encoding would have to reversed to avoid breaking customer experience. e.g., Is it going to SQL or No-SQL database? Is it going to be transformed to XML, JSON, CSV, TSV, HTML? Also in most large distributed systems you pass the data to your dependencies and applying data transformation of customer data before passing on would end up either corrupting data or break of service contracts.

I get the reason engineers always fall in the trap of input validation rather than Output encoding as it is a simpler mental model and feels more safe to do, Issue is that it comes with operational challenges. So we should be aware of applying it with output encoding. Here are somethings about Output Encoding.

As shown above, Web frameworks like React automatically encode data entered unless we configure it to handle unsafe data, we should depend on safe defaults rather than develop our own.

Attaching the links of those resources above so you can have a follow up.

Cross Site Scripting Prevention - OWASP Cheat Sheet Series
Website with the collection of all the cheat sheets of the project.
OWASP Top Ten Proactive Controls 2018 | C4: Encode and Escape Data | OWASP Foundation
C4: Encode and Escape Data on the main website for The OWASP Foundation. OWASP is a nonprofit foundation that works to improve the security of software.
What are the best practices for output encoding to prevent XSS attacks?
Learn what output encoding is, why it is important, how to choose, implement, and test it, and how to complement it with other security measures to prevent XSS attacks.
Output Encoding | TTS Engineering Practices Guide
A set of guidelines and best practices for an awesome engineering team

Thanks and hope you learnt something today.