Экранировать ввод или вывод?

Тенденция иметь один ответ на все возможные варианты может не только облегчить жизнь программисту, но и навредить результатам его профессиональной деятельности. Этот случай не исключение.

Принимая во внимание все многообразие существующих Веб-сайтов (и это только если их рассматривать отдельно) можно ли считать, что для всех может существовать один принцип экранирования данных? В реальности из стартапов в большие проекты вырываются те, кто сумел обойти конкурентов. Одно из условий - скорость работы приложения.

Это потом уже, вырвавшись из конкурентной гонки, специалисты этих проектов перераспределяют усилия на большую нагрузку и могут давать советы стартапам (и вообще всем) использовать микросервисы и прочее, что сами не использовали.

При рассмотрении данной темы есть интересное взаимоисключение - если экранировать на входе, то нет возможности отдавать исходные данные в разных форматах, если на выходе, то скорость определенно теряется. И нельзя создать единое экранирование для всех форматов, кроме небольшого компромисса, об этом далее.

Для чего нам потребуется отдавать данные в разных форматах? Самый часто встречаемый в интернете формат - это HTML. Потом уже идут JSON, XML, CSV и тд. Если мы собираемся давать совет на все случаи Веб-сайтов, без сомнений будем отталкиватся от HTML. Если искать правильный единый ответ для мейнстримной на данный момент технологии создания сайтов, то он скорее всего подразумевает интерпрайз код, которого в интернете по массе своей меньше. Несомненно, последнее нужно уточнять при написании категоричных статей типа "Всегда экранировать вывод, но не ввод". На многих сайтах кроме HTML другие форматы вывода не используются и не будут использоваться никогда, исходя из предназначения ресурса.

Проще говоря, если вывод информации в одном из форматов сильно преобладает (например HTML 90%, остальные 10% по статистике нагрузки) или важно именно в этом формате сделать упор на скорость, можно экранировать на вводе пользовательские данные, что обычно является узким местом, в конкретный преобладающий формат (здесь HTML) и хранить их в таком виде, а в остальных преобразовывать примененное экранирование обратно и конвертировать в нужный.

Что касается использования HTML, то наравне с JSON, результат которого часто размещается в том же DOM-дереве сайта, здесь большинство проблем сразу решает экранирование < и > в HTML сущности. Также по правилам принято экранировать знак &, что игнорируется всеми браузерами и может привести к проблемам при повторном экранировании первых двух указанных символов.

Результат вывода в CSV и подобные, который обычно не отображается пользователю сразу, а является генерацией файла по требованию, можно подвергнуть обратной конвертации, заменив указанные символы (HTML-сущности символов <, > и &) на исходные. При этом нельзя сказать точно, на какой формат приходится больше нагрузки, задачи каждого проекта особенны (надеюсь). Если неизвестно и цели сайта постоянно меняются, то здесь да, нужно экранировать вывод и смирится с тем, что функция экранирования будет запускаться всегда и везде, даже при инвалидации кеша. При этом важно, что узкоспециальное экранирование для каждого формата выполняется при выводе в этот формат.

Также нужно учитывать, где находится узкое место сайта, при вводе информации или выводе. Обычно в меньшинстве ввод, пользователь ввел какой то контент и потом он многократно, более раз и мест, чем создание и редактирование, отображается ему и другим пользователям.

Если посмотреть с точки зрения разработки программного обеспечения, то размещение экранирования (<, > и &) в узкой части также уменьшает вероятность банальной ошибки. Речь, конечно, только про экранирование этих трех символов, хотя по факту угрозу безопасности составляют толька два из них(< и >) . В современных фреймворках и использовании правильных подходов, это всё происходит через функцию-обёртку в которой функция экранирования присутствует единожды для каждого формата и это решает указанную выше проблему с выбором узкого места.

Посыл этого экскурса в тему экранирования заключается в более универсальном принципе, следовании здравому смыслу, в каждом конкретном случае нужно рассматривать задачи и структуру проекта индивидуально