Безопасность кода плагина: 7 проверок, которые ловят половину проблем до релиза

Безопасность кода плагина: 7 проверок, которые ловят половину проблем до релиза

В плагинах WordPress уязвимости чаще всего появляются не в «сложной логике», а в рутине: форма, запрос к БД, загрузка файла, AJAX-обработчик. Поэтому базовый фильтр должен быть одинаковым в каждом проекте.

— Проверяй права доступа перед любым действием: текущий пользователь должен иметь нужную capability, а не просто быть авторизованным.
— Для всех запросов из форм и AJAX используй nonce и проверяй его на сервере.
— Все входные данные прогоняй через sanitize_*, а вывод — через esc_*, иначе одна строка может сломать весь экран.
— Для SQL не склеивай строки вручную: используй prepare() и только параметризованные значения.
— Любую загрузку файлов ограничивай по типу, размеру и имени; путь к файлу нельзя собирать из сырого ввода.
— Если плагин работает с REST, закрывай лишние маршруты и проверяй права в callback, а не «на входе где-то выше».
— Логи и отладка не должны хранить секреты, токены и полные ответы внешних сервисов.

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

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