10 самых распространенных ошибок веб-разработчиков: руководство для разработчиков

Опубликовано: 2022-03-11

С момента появления термина World Wide Web в 1990 году разработка веб-приложений прошла путь от обслуживания статических HTML-страниц до полностью динамических сложных бизнес-приложений.

Сегодня у нас есть тысячи цифровых и печатных ресурсов, которые предоставляют пошаговые инструкции по разработке всевозможных веб-приложений. Среды разработки достаточно «умны», чтобы обнаруживать и исправлять многие ошибки, с которыми регулярно сталкивались ранние разработчики. Существует даже множество различных платформ разработки, которые легко превращают простые статические HTML-страницы в высокоинтерактивные приложения.

Все эти шаблоны, практики и платформы разработки имеют общую основу, и все они подвержены схожим проблемам веб-разработки, вызванным самой природой веб-приложений.

Цель этих советов по веб-разработке — пролить свет на некоторые распространенные ошибки, допускаемые на разных этапах процесса веб-разработки, и помочь вам стать лучшим разработчиком. Я затронул несколько общих тем, общих практически для всех веб-разработчиков, таких как проверка, безопасность, масштабируемость и SEO. Вы, конечно, не должны ограничиваться конкретными примерами, которые я описал в этом руководстве, поскольку они перечислены только для того, чтобы дать вам представление о потенциальных проблемах, с которыми вы можете столкнуться.

Распространенная ошибка № 1: неполная проверка ввода

Проверка пользовательского ввода на стороне клиента и сервера просто необходима ! Мы все знаем мудрый совет «не доверять пользовательскому вводу» , но, тем не менее, ошибки, связанные с валидацией, случаются слишком часто.

Одним из наиболее распространенных последствий этой ошибки является SQL-инъекция , которая год за годом входит в десятку лучших OWASP.

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

Распространенная ошибка № 2: аутентификация без надлежащей авторизации

Прежде чем мы продолжим, давайте удостоверимся, что мы согласны с этими двумя терминами. Как указано в 10 наиболее распространенных уязвимостях веб-безопасности:

Аутентификация: проверка того, что человек является (или, по крайней мере, кажется) конкретным пользователем, поскольку он / она правильно предоставил свои учетные данные безопасности (пароль, ответы на контрольные вопросы, сканирование отпечатков пальцев и т. д.).

Авторизация: подтверждение того, что конкретный пользователь имеет доступ к определенному ресурсу или ему предоставлено разрешение на выполнение определенного действия.

Другими словами, аутентификация — это знание сущности, а авторизация — знание того, что может делать данная сущность.

Позвольте мне продемонстрировать эту проблему на примере:

Учтите, что ваш браузер хранит текущую зарегистрированную информацию о пользователе в объекте, подобном следующему:

 { username:'elvis', role:'singer', token:'123456789' }

При смене пароля ваше приложение выполняет POST:

 POST /changepassword/:username/:newpassword

В вашем методе /changepassword вы проверяете, что пользователь вошел в систему и срок действия токена не истек . Затем вы находите профиль пользователя на основе параметра :username и меняете пароль пользователя.

Итак, вы подтвердили, что ваш пользователь правильно вошел в систему, а затем выполнили его запрос, тем самым изменив его пароль. Процесс кажется нормальным, верно? К сожалению, ответ НЕТ!

На этом этапе важно убедиться, что пользователь, выполняющий действие, и пользователь, чей пароль изменен, совпадают. Любая информация, хранящаяся в браузере, может быть изменена, и любой опытный пользователь может легко username:'elvis' на username:'Administrator' не используя ничего, кроме встроенных инструментов браузера.

Итак, в этом случае мы просто позаботились об Authentication , убедившись, что пользователь предоставил учетные данные безопасности. Мы даже можем добавить проверку того, что метод /changepassword может выполняться только Authenticated пользователями. Однако этого все же недостаточно для защиты ваших пользователей от злонамеренных попыток.

Вам необходимо убедиться, что вы проверяете фактического запрашивающего и содержимое запроса в вашем методе /changepassword и реализуете правильную Authorization запроса, гарантируя, что пользователь может изменять только свои данные.

Authentication и Authorization — две стороны одной медали. Никогда не лечите их отдельно.

Распространенная ошибка № 3: не готовы к масштабированию

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

Однако из-за этого постоянного дефицита времени даже хорошие команды веб-разработчиков часто упускают из виду определенные проблемы. Масштабирование часто является одной из тех вещей, которые команды считают само собой разумеющимся. Концепция MVP великолепна, но если зайти слишком далеко, то возникнут серьезные проблемы. К сожалению, недостаточно выбрать масштабируемую базу данных и веб-сервер и разделить все уровни приложений на независимых масштабируемых серверах. Есть много деталей, о которых вам нужно подумать, если вы хотите избежать переписывания значительных частей вашего приложения позже, что становится серьезной проблемой веб-разработки.

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

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

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

Распространенная ошибка № 4: неправильное или отсутствующее SEO

Коренной причиной неверных или отсутствующих передовых методов SEO на веб-сайтах является дезинформация «специалистов по SEO». Многие веб-разработчики считают, что они достаточно знают о SEO и что это не особенно сложно, но это не так. Мастерство SEO требует значительного времени, потраченного на изучение лучших практик и постоянно меняющихся правил индексации Интернета Google, Bing и Yahoo. Если вы постоянно не экспериментируете и не имеете точного отслеживания + анализа, вы не являетесь SEO-специалистом, и вы не должны им претендовать.

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

Как и в случае с масштабируемостью, вы должны думать о SEO с того момента, как начнете создавать свое веб-приложение, иначе вы можете обнаружить, что завершение вашего проекта внедрения SEO означает переписывание всей вашей системы.

Распространенная ошибка № 5: действия, потребляющие время или процессор в обработчиках запросов

Одним из лучших примеров этой ошибки является отправка электронной почты на основе действий пользователя. Слишком часто разработчики думают, что решением проблемы является вызов SMTP и отправка сообщения непосредственно из обработчика запросов пользователя.

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

Любое действие, потребляющее время или процессор, должно обрабатываться внешним процессом, пока вы освобождаете свои HTTP-запросы как можно скорее. В этом случае у вас должна быть внешняя почтовая служба, которая собирает заказы и отправляет уведомления.

Распространенная ошибка № 6: отсутствие оптимизации использования пропускной способности

Большая часть разработки и тестирования происходит в локальной сетевой среде. Таким образом, когда вы загружаете 5 фоновых изображений размером 3 МБ или более, вы можете не определить проблему со скоростью соединения 1 Гбит в вашей среде разработки. Но когда ваши пользователи начнут загружать на свои смартфоны 15-мегабайтную домашнюю страницу через соединение 3G, вам следует подготовиться к списку жалоб и проблем.

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

  1. Минификация всего JavaScript
  2. Минификация всего CSS
  3. HTTP-сжатие на стороне сервера
  4. Оптимизация размера и разрешения изображения

Распространенная ошибка № 7: не разрабатывать под разные размеры экрана

Адаптивный дизайн был большой темой в последние несколько лет. Распространение смартфонов с различными разрешениями экрана принесло много новых способов доступа к онлайн-контенту, что также связано с множеством проблем веб-разработки. Количество посещений веб-сайтов со смартфонов и планшетов растет с каждым днем, и эта тенденция ускоряется.

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

Существует множество шаблонов и методов создания адаптивных веб-приложений. У каждой платформы разработки есть свои советы и рекомендации, но есть некоторые платформы, которые не зависят от платформы. Вероятно, самым популярным является Twitter Bootstrap. Это бесплатная платформа HTML, CSS и JavaScript с открытым исходным кодом, которая была принята всеми основными платформами разработки. Просто придерживайтесь шаблонов и методов Bootstrap при создании приложения, и вы без проблем получите адаптивное веб-приложение.

Распространенная ошибка № 8: кроссбраузерная несовместимость

Процесс разработки в большинстве случаев сильно ограничен во времени. Каждое приложение должно быть выпущено как можно скорее, и даже хорошие веб-разработчики часто сосредоточены на предоставлении функциональности, а не на дизайне. Несмотря на то, что у большинства разработчиков установлены Chrome, Firefox, IE, в 90% случаев они используют только один из них. Общепринятой практикой является использование одного браузера во время разработки, и как только приложение близится к завершению, вы начинаете тестировать его в других браузерах. Это вполне разумно, если у вас есть много времени для тестирования и устранения проблем, которые появляются на этом этапе.

Однако есть несколько советов по веб-разработке, которые могут значительно сэкономить ваше время, когда ваше приложение достигнет фазы кросс-браузерного тестирования:

  1. Вам не нужно тестировать во всех браузерах во время разработки; это отнимает много времени и неэффективно. Однако это не означает, что вы не можете часто переключаться между браузерами. Используйте другой браузер каждые пару дней, и вы, по крайней мере, заметите основные проблемы на ранней стадии разработки.
  2. Будьте осторожны, используя статистику для оправдания отказа от поддержки браузера. Есть много организаций, которые медленно внедряют новое программное обеспечение или обновляют его. Тысячи работающих там пользователей могут по-прежнему нуждаться в доступе к вашему приложению, и они не могут установить последнюю версию бесплатного браузера из-за внутренней политики безопасности и бизнес-политик.
  3. Избегайте кода, специфичного для браузера. В большинстве случаев есть элегантное решение, совместимое с разными браузерами.

Распространенная ошибка № 9: не планировать переносимость

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

Идеальная установка приложения должна быть необслуживаемой:

  1. Убедитесь, что ваше приложение может масштабироваться и работать в среде с несколькими серверами с балансировкой нагрузки.
  2. Разрешить простую и понятную настройку — возможно, в одном файле конфигурации.
  3. Обработка исключений, когда конфигурация веб-сервера не соответствует ожидаемой.

Распространенная ошибка № 10: Антипаттерны RESTful

RESTful API заняли свое место в веб-разработке и останутся. Почти в каждом веб-приложении реализованы какие-либо службы REST, будь то для внутреннего использования или интеграции с внешней системой. Но мы по-прежнему видим сломанные шаблоны RESTful и сервисы, которые не соответствуют ожидаемым практикам.

Две наиболее распространенные ошибки при написании RESTful API:

  1. Использование неправильных глаголов HTTP. Например, используя GET для записи данных. HTTP GET был разработан, чтобы быть идемпотентным и безопасным, а это означает, что независимо от того, сколько раз вы вызываете GET для одного и того же ресурса, ответ всегда должен быть одним и тем же, и не должно происходить никаких изменений в состоянии приложения.

  2. Не отправляются правильные коды состояния HTTP. Лучший пример этой ошибки — отправка сообщений об ошибках с кодом ответа 200.

     HTTP 200 OK { message:'there was an error' }

Вы должны отправлять HTTP 200 OK только в том случае, если запрос не вызвал ошибку. В случае ошибки следует отправить 400, 401, 500 или любой другой код состояния, соответствующий возникшей ошибке.

Подробный обзор стандартных кодов состояния HTTP можно найти здесь.

Заворачивать

Веб-разработка — чрезвычайно широкий термин, который может на законных основаниях охватывать разработку веб-сайта, веб-службы или сложного веб-приложения.

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