Where in the MVC concept of a web application should HTML special characters be filtered?

Question

Software design

There is a web application (site) that is built on the ideas of MVC: there is a controller that processes incoming requests and returns a response, a view that generates the HTML code of the pages and JSON code for the API, and a model that stores data and deals with the so-called business logic.
This site has a form that accepts text data from the client, then the application creates an object based on them (the field values ​​are the text from the form), saves it to the database (using SQL), and then loads the object from the database and outputs HTML -page with the data of this object. In the future, the site will be developed (it is not known where) and this data can be used in the future for other purposes. It is important to maintain the clarity of the source code and the simplicity of the system.
Everyone knows that in text data received from the client, it is imperative to escape HTML special characters before inserting this text into the HTML code of the page. Actually the question is: at what stage of the site’s work should special HTML characters be escaped:

• in the controller when receiving data from the form;
  
• in the model before saving to the database;
  
• in the controller or model when passing data to the view;
  
• on view when inserting text into HTML;
  
• or elsewhere?
  

Please justify your answer.

Answer 1

In this place:
Reasoning: because the data can be absolutely anything and needs to be processed, and the problem can only arise when displayed in the user's browser.
In more detail: here is the diagram . (blocks "Preparing module output data" and "Preparing application output data")

Answer 2

I do not think that your question has an unconditional and unanimously correct answer. First of all, it all depends on the framework you use, respectively, in different frameworks there are different implementations of such mechanisms.
For example, in Symfony2/3 there is such a thing as "DataTransformers", which transforms data when saving / retrieving according to a given formula. In Laravel 5.x - there are "Mutators" that perform similar manipulations with model fields. Also, depending on the framework, there can be a variety of filters, converters, and so on.
For example, if you use the Twig template engine, it has a lot of ready-made filters + the ability to write your own, filtering the data before displaying it. And, a template (view) - there is a place for filtering data no better and no worse than others,if your template engine has such a mechanism .
But let's think logically. Will you ever need a 100% original text? That is, such a text that would preserve all the tags that the user entered, all spaces (including extra ones), the case of these tags, etc. details / features of what the user entered?
If yes, but you will rarely need this data, for example, for some statistics, then save it in some separate field in the database, such as "user_text_original".
If yes (the data is needed in 100% original consistency), and you will need this data often - filter it where the framework allows you or where you need it already filtered. If for some reason you need them in a filtered form inside the controller - filter them in the controller, before they are needed there, or before they get into the controller (in the model). If you don't need them in the controller and you can filter the data inside the View, filter them there, no problem.
If, however, you do not need the data in its original form in 99% of cases, but you need already filtered data, from which all unnecessary HTML tags have been cleaned, for example, then a reasonable question arises: why constantly drive filters back and forth, save the filtered data right away in the database, in accordance with the capabilities and mechanisms of your framework (as I wrote above, these can be DataTransformers, Mutators, etc.). Since you remove tags from the data, their volume is reduced (this is a plus), and since you pull the filter only 1 time, the load on the system is reduced (this is also a plus). But this layout will only work if the saved data is obtained more often than it is saved. So, for example, if you display comments on the page, then each independent comment unit should be shown at least 2 times. I.e,
I hope you understand the idea that I wanted to convey. MVC is an application architecture model, quite general. It does not have a strict division or description of any individual menanisms, such as query processing or data filtering. In addition, MVC as an architecture/concept was described in 1979, a little earlier than the concept of "web" or, even more so, "modern web" appeared.
PS Of course, I could describe everything in more detail, but it turned out so much...

Answer 3

The protection is simple (I don’t mention any csrf, etc.)
1) shield data from SQL injections before putting it into the database
2) shield data from XSS attacks before outputting it to the browser