Дмитрий Энтелис

Imho стандартное решение:
При авторизации пользователя по логину-паролю генерим некую длинную строку (токен), записываем в базу, + пишем в куки.
При каждом запросе пользователя берем этот токен из кук и проверяем есть ли такой.
По желанию можно докрутить время жизни, проверку ip итд итп.

Если +- шаблонные то mailchimp.com например
Если уникальные то freelansim.ru

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

1. strip_tags с набором разрешенных, mysqli_real_escape_string или pdo.
2. Можно самому считать открытые закрытые, код видится не сложным. Заодно всякие инлайн стили вырезать итд.

Пардон, curl тут не причем, не правильно понял вопрос.

мне надо чтобы при открытии ссылки например site.ru/code (которой не существует) вытаскивалось значение 'code' и забиралось в переменную для обработки

1. Делаем .htaccess, в нем рерайтим все запросы на какой нибудь скрипт передавая туда url

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

2. в скрипте разбираем url

Через 3 запроса

да

Не надо так делать. По куче причин - от огромных размеров дырке в безопасности, до отсутствия истории кода.

Начните пользовать git или mercurial и настройте автодеплой на сервер.

Поймите, все утечки которые происходят - в 99% это не exploit, а тупо человеческий фактор.
Все решения с конфигами сервера, ORM и прочим - абсолютно бессмысленны когда вашему сисадмину подарят новый X6 и он сольет дамп сервера целиком.

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

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

Решение 1:
Пишем хранимку которая отдает связанные логины-пароли от внешнего сервиса по логину-паролю от нашего мульти-мессенджера.
Доступ к изменению хранимки и к базе в которой лежат все пароли есть у 1 человека в компании. Остальные тупо ходят через хранимку. Способа получить полный список логинов-паролей сервиса не существует.

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

Решение 2:
Разделяем каждый пароль от внешнего сервиса на N частей (N >= 3)
Дублируем решение 1 на N серверов, каждый пароль получается размазан на N серверов.
Первоначальная хранимка занимается тем что собирает данные из N хранимок с N серверов.
У каждого сервера - свой ответственный человек. Доступ к каждому серверу есть только у ответственного и у bigboss (на случай внештатных ситуаций).

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

Не знаю кто такие эти ваши basicdata.ru, есть официальный сайт:
fias.nalog.ru/Public/DownloadPage.aspx

1. Скачайте полную версию в dbf.
   
2. Любым конвертером например https://github.com/xtranophilist/dbf2sql сконвертируйте в sql.
   
3. ????
   
4. PROFIT
   

Например считать хеш с солью по данным каждого запроса.
Совсем хорошо соль считать динамически от времени например.
И всё это по https обязательно.

Захотят вскрыть - вскроют, но уже с геморроем.