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 прав?

Прав

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

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

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

nohup php /path/to/file.php &

ну, эта ваша защита от ничего))

<?php

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class InvalidRequestParam extends \InvalidArgumentException
{}

class MyController
{
    /**
     * @param Request $request
     * @return Response
     */
    public function myAction(Request $request)
    {
        try {
            $intPostParam          = $request->request->get('intPostParam');
            $unsignedIntPostParam  = $request->request->get('unsignedIntPostParam');
            $md5GetParam           = $request->query->get('md5GetParam');
            $optionalDigitGetParam = $request->query->get('optionalDigitGetParam');

            if (is_null($intPostParam)) {
                throw new InvalidRequestParam('"intPostParam" is required');
            } elseif (!is_numeric($intPostParam)) {
                throw new InvalidRequestParam('"intPostParam" must be numeric');
            }

            if (is_null($unsignedIntPostParam)) {
                throw new InvalidRequestParam('"unsignedIntPostParam" is required');
            } elseif (!ctype_digit($unsignedIntPostParam)) {
                throw new InvalidRequestParam('"unsignedIntPostParam" must be digit');
            }

            if (is_null($md5GetParam)) {
                throw new InvalidRequestParam('"md5GetParam" is required');
            } elseif (!preg_match('/^[\da-f]{32}$/', $md5GetParam)) {
                throw new InvalidRequestParam('"md5GetParam" must be correct md5 hash');
            }

            if (!is_null($optionalDigitGetParam) && !ctype_digit($optionalDigitGetParam)) {
                throw new InvalidRequestParam('"optionalDigitGetParam" must be digit or null');
            }

            // Тут ваша бизнес логика

            return new Response('All params correct');
        } catch (InvalidRequestParam $e) {
            return new Response($e->getMessage(), Response::HTTP_BAD_REQUEST);
        } catch (\Throwable $e) {
            return new Response('Some thing went wrong', Response::HTTP_INTERNAL_SERVER_ERROR);
        }
    }
}

Защита на глобальных переменных - это не самая хорошая идея. В любой точке кода строка
$_SESSION['admin'] = 1;
отключит ее.

В своей практике наталкивался на случаи, когда даже сами сотрудники добавляют в uploads вредоносный код, под видом невинных файлов (я уже молчу про анонимусов, которым захочется вас взломать). А в вашем случае взлом будет еще и нереально легким.
-- --
Контроль доступа как правило имеет смысл делать в экшнах, а не в конструкторе контроллера.
-- --
echo $e->getMessage(); - вот это плохая идея. Не выводите клиенту текст исключения, прописывайте его явно. Что будет, если словите исключение с куском SQL? Будете показывать структуру вашей БД кому попало?
-- --
Бросание исключения после редиректа обычно бессмысленно. Вы уже знаете ответ для клиента, завершайте процесс.
-- --
Кстати, фатальные исключения - это не круто, это признак говнаря, не делайте так.

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

Что ж - тогда нужно столкнуться. Мидл отличается от Джуна не некими "мистическими знаниями", а опытом решения не стандартных задач.

Что касается используемых фреймворков вами - чем раньше перейдете на Symfony - тем быстрее вырастите. Безусловно, для своих задач yii - не плох, но это средне-маленькие проектики, для больших - это скорее плохой выбор, чем хороший (экспоненциальное разрастание моделей в случае больших команд - это убийственная практика). Kohana на пару с CodeIgniter - вообще учат тому, как писать не стоит((

Собственно чего я набросил на kohana?
1. Фреймворк не должен меняться, и не должен быть "в перемешку" с вашим кодом. Слишком велик соблазн что-то поменять во фреймворке. Как следствие - обновление части кода с фреймворком усложнится.
2. Явная инициализация всех подсистем проекта при загрузке. Зачем? Велика вероятность, что вообще все что там на каждый запрос не нужно.
3. Больше автолоада богу автолоада. Есть принятые стандарты PSR-0 и PSR-4, используйте их. Поймете зачем нужны неймспейсы. А кукули типа My_Very_Perfect_Controller - это практика 2000-х.
4.

<?php defined('SYSPATH') or die('No direct access allowed.');

Эта защита имеет смысл только в случае, если ваш код в публичном доступе, чего вообще-то быть не должно. По хорошему в публичном каталоге должен быть только один исполняемый php файл index.php
5. Статика - это путь к бесконтрольной связности проекта. Код с ее использованием тяжело поддается тестированию и изменению.
6. ActiveRecord для больших проектов - это самоубийственная практика, увы. Передавая модель куда-то вы передаете не только данные, но и подключение к БД. Как следствие код, который со всей силы не должен иметь возможность делать запросы к БД - может это делать и будет.

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