index0h

Я всегда в любых своих проектах использовал данные из массива $_SERVER напрямую.

Использовать глобальные переменные - плохая практика. С точки зрения безопасности, тестируемости и надежности вашего кода. На счет суперглобальных: один раз при инициализации вашего приложения вытягиваете нужные для вас данные из них, проверяете и вставляете в некий объект Request, это уже данные, которым вы можете доверять, посему изменять их внутри Request нельзя. Посмотрите symfony.com/doc/current/book/http_fundamentals.html

require_once $_SERVER['DOCUMENT_ROOT'].'/папка/файл.php'

Так писать по нельзя. От слова "совсем".
Используйте Composer. Подключение файлов вручную нужно только в точке входа (обычно это index.php). Опять же с точки зрения безопасности.
Никто вам не гарантирует, что $_SERVER['DOCUMENT_ROOT'] будет правильным, да и то, что будет создан такой элемент - тоже не гарантирует.

Исходя из этого возникает вопрос. На сколько это оправдано?

Со всей силы оправдано.

Но, что мне делать с массивом $_SERVER?

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

Каким образом он может быть подменен или в него может быть вставлена инъекция?

$_SERVER['DOCUMENT_ROOT'] = '/dev/null';

require 'path/to/your/file.php';

Если запустить скрипт из консоли - куча элементов $_SERVER просто не будут созданы, например QUERY_STRING

Может быть NetBeans прав?

Прав

и действительно нужна обработка.

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

Рекомендую почитать: Попросили проверить код, на что смотреть нужно?

сверено с исходниками - все чисто

И в БД тоже? Я очень давно последний раз трогал MODx и на сколько помню там было в моде часть исходников хранить в БД.
Надеюсь вы проверяли исходники не вручную? (в смысле через diff в вашей VCS + в БД)

Есть мысли вынести сайты на уровень выше корня, оставив только точку входа

Это первое, что нужно делать))

Как вообще проводится поиск эксплойтов на сайте, если идей никаких нет?

0 - Если у вас в публичном каталоге не одна точка входа, а весь проект - вы уже себе в ногу выстрелили
1 - Ищутся CVE в багтрекере CMS
2 - Проверяются плагины, установленные в системе, они тоже могут содержать уязвимости
3 - Проверяется возможность загрузить и выполнить файл. Например на uploads (или как там каталог называется) права на запуск должны со всей силы отсутствовать
4 - Проверяются открытые порты сервера (если наружу торчит mysql, redis, memcached, ... - тогда сами себе злобный буратино)
5 - Ищутся все возможные точки с eval/include/require/include_once/require_once/exec/shell_exec/... для стороннего кода это потенциальная точка выполнения
6 - Ищутся возможные sql инъекции по коду cms/плагинов
7 - Ищутся всевозможные phpmyadmin и тому подобные сервисы, торчащие наружу
8 - Если в коде активно юзаются глобальные переменные - это потенциальная дыра в безопасности
9 - Если аргументы методов не проверяются - это тоже потенциальная дыра в безопасности
10 - Вам стоит убедиться и в том, что отсутствует утечка изнутри. На одном проекте случайно нашел залитый бывшими сотрудниками phpspy

Welcome to NodeJS))
www.sitepoint.com/exploring-different-cms-solution...

хранением базы данных в файле.

Обычно так никто не делает. Есть СУБД и вы с ней работаете, а не с файлом.

Golang по умолчанию компилируется в 1 бинарь. Да, можно подключать shared либы, да можно собирать, но язык заточен не под это.
Что бы подключать функционал - гуглите на тему "golang unsafe", "golang load dynamic library". Но вообще говоря - это со всей силы не golang-way.

каждый модуль использовать как микросервис

вполне вариант

представить не могу как расширить функцию парсинга команд

Вам нужен некий резолвер, который будет заполняться мета данными о ваших командах в процессе старта приложения. Далее на основании собранных данных нужно будет настраивать парсер команд.

Если же вы хотите нечто эдакое сделать с помощью отдельных микросервисов - потребуется как минимум еще один, который будет распределять действия между остальными. Например через сервер очередей, либо rpc. В любом случае протокол общения между сервисами вам придется спроектировать. А если запуск через консоль - это еще один клиент. Грубо говоря эта штука может выглядеть так:

[client] <-??-> [client-app] <-rpc|queue|...-> [main-server] <-rpc|queue|...=>[modules]

nohup php /path/to/file.php &

Для php web разработки must have:
- vagrant: https://www.youtube.com/watch?v=3WldiUHkFnw
- phpStorm
- git

И как заливать изменения в проекте на сервер? С помощью GIT?

Есть много подходов, git pull - один из них. Все зависит от проекта, серверной архитектуры и требований к безопасности.

Скорость сборки в большей части зависит от правил сборки. Можно даже на отличном железе сделать медленную фигню. Очень критично - не пересобирать то, что этого не требует. В остальном - да, cpu.

Проверять данные в каждом методе - это вполне отличная практика, по сути это соблюдение интерфейса метода.
Но возвращать при этом null/false - практика хреновая, если ваш метод на вход требует int, а получил array - надо бросать исключение. Так вы будете знать, что внешний код, который использует ваш метод работает не корректно.

Для объектов настоятельно рекомендую использовать type hinting:

public function test(MyObject $object, $id)
{
    if (!is_int($id)) {
        throw new \InvalidArgumentException('Argument "id" must be int');
    } elseif ($id < 0) {
        throw new \InvalidArgumentException('Argument "id" must be positive');
    }
...

Если пишете на семерке, то и для скаляров и на вывод - тоже стоит указывать type hinting. Правда с выводом не всегда это можно делать, например возврата null, или что-то еще.

public function checkPositive(int $intData): bool

Для сокращения проверок можете мой пакет заюзать https://packagist.org/packages/ko-ko-ko/assert, он спроектирован под максимальную производительность и использование в каждом методе.

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?

Да. За счет этого вы выигрываете в безопасности, надежности и времени поиска багов.