Разрешить некоторые символы

есть регулярка для поля login

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

Про sql injection - см. prepared statements.

-----
PostgreSQL DBA

А как же XSS-атака возможно же вставить html теги в поле password и каки можно наделать. как правильно фильтровать или экранировать ?

И? Да хоть бинарного мусора. password_hash и password_verify как-то без разницы.


Зачем?
Вот не поверите - неверен сам вопрос.
Верный вопрос:
- как передать значение в SQL так, чтобы СУБД не могла воспринять часть данных за команду
- как представить данные в HTML так, чтобы браузер отображал именно эти данные, а не считал что это разметка
- как корректно использовать данные в любом_заданном_формате, чтобы они воспринимались как эти самые данные при чтении этого самого заранее известного формата

"оой, ну наверное кавычки это страшная хакерская штука, их не должно быть в пароле"? "ой, уравнение a<b and b>c никто в здравом уме не напишет, это же опаснейших HTML тег"?

Вам нужно подставить данные в CSV? Что, будете удалять все запятые из текста? Да нет, конечно. Возьмёте не менее стандартные функции форматирования CSV
Нужно передать JSON? Реально будете вырезать регуляркой всё, что имеет значение в JSON? Опять нет. Возьмёте стандартный json_encode
Нужно подставить параметр в ссылку? urlencode к вашим услугам.
Вам нужно вывести данные в HTML? htmlspecialchars.
Передать данные базе данных? У каждой базы есть родной интерфейс для этого. В частности, механизм prepared statements.

На сладкое мой любимый пример:
Введите сумму перевода: _
Везде проверили, что прислали число, что у пользователя есть столько денег, пользователь существует. Всё отлично, делаем одному balance = balance + ?, второму вычитаем с баланса
А потом некто просто вводит отрицательное число.

Потому второй верный вопрос: какие данные мы тут ожидаем и где их будем использовать.

-----
PostgreSQL DBA