Безопасность

apidcms использует SQLite — это файл базы данных на сервере. Такая архитектура даёт простоту, но требует внимания к защите.

Где находится база

База данных всегда находится в /admin/storage/database/cms.db — внутри админ-панели. Это правильный путь, закреплённый в ядерном fallback-конфиге (core_lib/front/config/config.php).

Важно: на проекте не должно быть других копий cms.db. После обновление ядра проверяйте, что база не появилась в core_lib/admin/storage/ или storage/database/.

Главная уязвимость: прямой доступ к базе

Если веб-сервер не настроен на блокировку .db файлов, базу можно скачать по прямой ссылке:

https://вашсайт.ru/admin/storage/database/cms.db

В базе хранятся все данные сайта: страницы, настройки, навигация, заявки из форм, контент.

Как защититься

Защита админки (первый слой)

База находится в /admin/ — все запросы к админке проходят через CMS с проверкой авторизации:

RewriteRule ^admin(.*)$ index.php [QSA,L]

.htaccess — блокировка .db файлов (второй слой)

RewriteRule — блокировка любых .db файлов:

RewriteRule \.db$ - [F,L]

Срабатывает раньше всех остальных правил. Любой URL, заканчивающийся на .db — мгновенный 403.

Files-защита — запрещённые расширения (третий слой):

<Files ~ "\.(env|json|config\.js|md|gitignore|gitattributes|lock|sql|db)$">
    Order allow,deny
    Deny from all
</Files>

Nginx

Для nginx .htaccess не работает. Добавьте в конфиг сервера:

location ~ \.db$ {
    deny all;
    return 403;
}

Как проверить защиту

curl -I https://вашсайт.ru/admin/storage/database/cms.db

Должен вернуть 403 Forbidden. Если возвращает 200 OK и размер в байтах — дыра открыта. Немедленно исправьте.

Также убедитесь, что файл есть только по пути /admin/storage/database/cms.db:

find . -name 'cms.db' -type f
# Должен быть ровно один файл

Если .htaccess не работает

На некоторых хостингах AllowOverride может быть отключён в конфиге Apache. В этом случае:

1. Свяжитесь с поддержкой хостинга
2. Попросите включить AllowOverride All для вашего сайта
3. Как временная мера — добавьте правила блокировки .db в конфиг Apache напрямую
4. База под админкой — даже без .htaccess защита авторизацией остаётся

Регулярный аудит

Рекомендуем проверять защиту базы после каждого обновления ядра (обновление ядра) и не реже раза в месяц:

# 1. Проверить, что база только в админке
find . -name 'cms.db' -type f
# Должен быть только ./admin/storage/database/cms.db

# 2. Проверить, что база недоступна по HTTP
curl -s -o /dev/null -w '%{http_code}' https://вашсайт.ru/admin/storage/database/cms.db
# Должен быть 403

# 3. Проверить, что нет базы в core_lib (мусор от обновление ядра)
ls core_lib/admin/storage/database/cms.db 2>/dev/null && echo "МУСОР — удалить!"

Дополнительные меры

• Не публикуйте cms.db в git-репозиториях — добавьте в .gitignore
• Настройте регулярные бэкапы базы данных
• Используйте HTTPS — обязательно для форм с персональными данными
• После обновление ядра проверяйте — обновление ядра может создать дубликаты базы