Иногда самая полезная проверка начинается не с тестов, а с простого вопроса: «Что увидит человек, который откроет мой сайт впервые?» В собственном сайте-портфолио я столкнулся с неприятной деталью. В разделе «Навыки» любой посетитель видел кнопку «Редактировать». Более того, она открывала форму и позволяла сохранить изменения. Звучит как серьёзная уязвимость. Но здесь важна точность. 🧩 Что действительно происходило Этот раздел не имел собственного серверного API. Изменения сохранялись в localStorage — хранилище конкретного браузера. То есть посетитель не мог через эту кнопку изменить общую базу данных или чужие записи. Но публичный интерфейс выглядел так, словно административные функции доступны всем. Это не подтверждённый взлом. Это ошибка разграничения режимов, которую нельзя оставлять без внимания. ⚙️ Как исправлял Сначала разделил две задачи: что должен видеть посетитель и что ему разрешено делать. Для публичного режима убрал элементы редактирования. Затем добавил проверки не только на отображение кнопки, но и на сами действия: открытие редактора и сохранение. Почему не ограничился скрытием кнопки? Потому что внешний вид страницы — не механизм авторизации. Скрытый элемент можно снова показать, а обработчик события — вызвать отдельно. Дальше проверил соседние разделы «Проекты» и «Сертификаты». Там уже есть серверные операции. Запросы на создание, изменение и удаление без действующей сессии должны отклоняться — именно это и подтвердили проверки. Главная граница доступа проходит на сервере, а не в интерфейсе. 🔄 Неожиданный второй раунд После первого исправления появился скриншот, где кнопка всё ещё была видна. Пришлось разбирать не только код, но и поведение браузера. Восстановление страницы из back/forward cache может вернуть сохранённое состояние интерфейса без повторного запуска скриптов. Я добавил повторную проверку режима при событии pageshow. При этом причина конкретного случая на опубликованном сайте осталась неподтверждённой: возможно, там ещё была старая версия или закэшированная страница. Приписывать всё одному механизму было бы неправильно. 🧪 Что осталось после исправлений В репозитории появились регрессионные проверки: — публичный режим не показывает элементы управления; — функции редактирования не запускаются без нужного режима; — серверные операции требуют действующую сессию. В отчёте последнего объединённого изменения зафиксировано 94 успешно пройденных автоматических теста. Это результат тестового прогона, а не обещание, что ошибок больше нет. 💡 Три вывода для своих проектов 1. Проверяйте сайт глазами гостя. Особенно формы, кнопки управления и скрытые разделы. 2. Не путайте UI и безопасность. Ограничения в браузере улучшают интерфейс. Права на изменение серверных данных проверяет backend. 3. Тестируйте возврат на страницу. Кэш и восстановление вкладок иногда проявляют ошибки, которых нет при обычной загрузке. 🎯 Главный вывод Сейчас AI-инструменты помогают писать код быстрее. Но скорость разработки не заменяет понимания того, кому система доверяет и почему. Надёжность начинается там, где разработчик проверяет не только счастливый сценарий, но и границы доступа. 💬 А вы когда-нибудь находили в своём проекте ошибку, которую обычные тесты не замечали? #ВебРазработка #AIEngineering #Безопасность