Нужно ли защищать обработчик формы (PHP файл) от прямого доступа?

Доброе время суток.

Есть простая форма.
<form action="/action_page.php">
  First name:<br>
  <input type="text" name="firstname" value="John">
  <br>
  Last name:<br>
  <input type="text" name="lastname" value="Doe">
  <br><br>
  <input type="submit" value="Submit">
</form>

Нужно ли защищать от прямого доступа обработчик формы action_page.php и как вообще нужно его защищать? Просто там как раз важная информация.
Из этого вопроса Как ограничить доступ к файлам PHP?, я понял что при правильной настройке веб-сервера не надо дополнительно что то делать. Тогда вопрос, где в Nginx, посмотреть правильно ли настроен сервер и как правильно настроить что бы обезопасить action_page.php?
  • Вопрос задан
  • 1053 просмотра
Решения вопроса 3
@FanatPHP
Не бывает никакого "непрямого" доступа к обработчикам форм. Доступ всегда прямой.
Не бывает никаких отдельных специальных обработчиков форм. Твой обработчик - это обычный пхп скрипт, такой же как все остальные. И защищать его надо не больше и не меньше, чем остальные скрипты.

Поэтому надо выкинуть эти фантазии из головы и заняться чем-нибудь полезным.
Ответ написан
GennadyS
@GennadyS
Программист, философ
Нет, файл-PHP защищать не нужно, если веб-сервер передает его на обработку PHP-интерпретатору. То есть, если сценарии вообще работают, а не выдается содержимое PHP-файла при запросе по адресу ваш-сайт/action_page.php. Большинство PHP-движков спокойно хранят настройки в PHP-скриптах.

Однако, если данные очень критичны и есть боязнь сбоя сервера (например, администратор допустит случайную и временную ошибку, открыв доступ к содержимому скриптов, исключив интерпретацию), можете вынести все приватные данные за пределы action_page.php, например, в action_page_handler.php , в свою очередь находящийся за пределами публичной директории, и подключаемый, скажем, как require __DIR__ . '../../scripts/action_page_handler.php'; (и это будет единственная строчка в action_page.php, которую кто-либо когда-либо сможет увидеть).
Ответ написан
Ninazu
@Ninazu
1. Создай единую точку входа, и оставь ее в корне сайта, остальные файлы вынеси за пределы (Это не только сделает твое приложении более гибким, понятным, и структурированным, но и в случае отваливания веб сервера, такое когда-то у меня было, после кривого обновлении до php7, исходный код показывался браузером)
2. Не забудь про SQL иньекции. Никакой конкатенации или вставок PHP. Только плейсхолдеры и байндинг
3. Если есть возможность загружать файлы, нужно исключить возможность исполнения в этой папке.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@Narts
Поставь isset или простенькую валидацию на данные и в случае какой-то ошибки делай редирект на страницу с ошибкой
Если ты о том, что перейдя по ссылке со скриптом можно увидеть его код, то на сервере можно запретить просмотр этих файлов
Ответ написан
@alekssamos
Программист любитель
Если будут проблемы с интернет соединением на сервере или упадёт сайт, когда ключ может показаться в тексте ошибки. Для надёжности ещё отключи вывод всех ошибок
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
MAG Development Москва
от 150 000 до 250 000 руб.
Radyushin & Co Тольятти
от 40 000 до 80 000 руб.
25 авг. 2019, в 17:25
500 руб./за проект
25 авг. 2019, в 14:05
60000 руб./за проект