# Безпека Symfony у 2026 році: Voters, Firewalls та питання технічних співбесід

> Вичерпний посібник із системи безпеки Symfony: firewalls, voters, атрибут IsGranted, стратегії прийняття рішень, дебагінг у Twig 7.4 та питання технічних співбесід для PHP-розробників.

- Published: 2026-06-18
- Updated: 2026-06-18
- Author: SharpSkill
- Tags: symfony, security, php, voters, firewall, authentication, interview
- Reading time: 13 min

---

Компонент Security є одним із найскладніших і найбільш детально розглянутих елементів Symfony під час технічних співбесід для backend-розробників у 2026 році. Автентифікація, авторизація, firewalls, voters — кожен рівень спирається на точні абстракції, володіння якими відрізняє senior-спеціалістів від розробників середнього рівня. З випуском Symfony 7.4 LTS система безпеки набула кращої спостережуваності завдяки дебагінгу рішень щодо доступу безпосередньо в Twig, зберігаючи при цьому розширювану архітектуру, яка є сильною стороною фреймворку протягом багатьох років.

Ця стаття глибоко аналізує внутрішні механізми системи безпеки Symfony: конфігурацію firewalls, управління токенами доступу, проєктування voters, стратегії прийняття рішень та найкращі практики зміцнення захисту. Кожен концепт проілюстровано production-ready кодом та пов'язано з питаннями, що виникають на технічних співбесідах.

> **Symfony 7.4 LTS — що нового в безпеці**
>
> Symfony 7.4 LTS, випущений у листопаді 2025 року з підтримкою до листопада 2029, консолідує ключові зміни в компоненті Security, запроваджені починаючи з версії 6.0: уніфіковані автентифікатори, нативний атрибут IsGranted, дебагінг рішень щодо доступу в Profiler та Twig, а також вдосконалена система voters. Ця версія є точкою відліку для продакшн-проєктів і питань технічних співбесід у 2026 році.

## Firewalls: перша лінія оборони

Система безпеки Symfony побудована на архітектурі firewalls, оголошених у файлі `security.yaml`. Кожен firewall визначає периметр захисту для певного набору маршрутів із власними правилами автентифікації та контролю доступу. Порядок оголошення є визначальним: Symfony проходить через firewalls послідовно і застосовує перший, патерн якого відповідає URL запиту.

```yaml
# config/packages/security.yaml
security:
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt))/
            security: false

        api:
            pattern: ^/api/
            stateless: true
            custom_authenticators:
                - App\Security\ApiTokenHandler

        main:
            lazy: true
            provider: app_user_provider
            form_login:
                login_path: app_login
                check_path: app_login
            logout:
                path: app_logout

    access_control:
        - { path: ^/api/public, roles: PUBLIC_ACCESS }
        - { path: ^/api/, roles: ROLE_API_USER }
        - { path: ^/admin, roles: ROLE_ADMIN }
        - { path: ^/dashboard, roles: ROLE_USER }
```

У цій конфігурації співіснують три firewalls. Firewall `dev` повністю вимикає безпеку для маршрутів Profiler та Web Debug Toolbar, усуваючи будь-які перешкоди в середовищі розробки. Firewall `api` захищає API-ендпоінти stateless автентифікацією на основі кастомного токена. Firewall `main` керує класичною автентифікацією через форму із сесією для веб-інтерфейсу.

Секція `access_control` визначає глобальні правила доступу, що оцінюються після автентифікації. Порядок правил є критичним: перемагає перший збіг. Правило `PUBLIC_ACCESS` на `/api/public` дозволяє доступ без автентифікації, навіть коли firewall `api` активний. Ця тонкість є поширеною темою питань на співбесідах.

> **Обережно з security: false на маршрутах API**
>
> Прапорець `security: false` повністю вимикає компонент Security для відповідних маршрутів: жодного токена, жодного користувача, жодного voter. Ця опція ніколи не повинна використовуватися на продакшн-маршрутах, відкритих для загального доступу. Для надання неавтентифікованого доступу до певних маршрутів API слід використовувати `PUBLIC_ACCESS` в `access_control`, зберігаючи активний firewall.

## Stateless проти Stateful: дві парадигми автентифікації

Вибір між stateless та stateful автентифікацією визначає архітектуру безпеки застосунку. У парадигмі stateful (firewall `main`) Symfony зберігає токен автентифікації в PHP-сесії. Кожен наступний запит відновлює контекст безпеки з сесії без повторної автентифікації. Прапорець `lazy: true` оптимізує цей процес, завантажуючи сесію лише тоді, коли перевірка авторизації дійсно потрібна.

У парадигмі stateless (firewall `api`) кожен запит несе власні облікові дані — Bearer-токен, API-ключ, JWT-підпис. На стороні сервера жодна сесія не створюється. Ця модель природно підходить для розподілених архітектур, мікросервісів та мобільних клієнтів, але вимагає, щоб кожен запит був самодостатнім з точки зору автентифікації.

Вибір між цими двома парадигмами не є технічним уподобанням, а архітектурним обмеженням. Монолітний застосунок із веб-інтерфейсом віддає перевагу stateful-режиму через простоту управління. API, що споживається гетерогенними клієнтами, вимагає stateless-режиму для горизонтальної масштабованості.

## Access Token Handler: кастомна автентифікація

Symfony 6.2 запровадив систему Access Token Handler, що уніфікує управління токенами автентифікації через чіткий інтерфейс. Цей механізм замінив старі Guard Authenticators, пропонуючи більш пряму інтеграцію з компонентом Security.

```php
// src/Security/ApiTokenHandler.php
namespace App\Security;

use App\Repository\ApiTokenRepository;
use Symfony\Component\Security\Core\Exception\BadCredentialsException;
use Symfony\Component\Security\Http\AccessToken\AccessTokenHandlerInterface;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;

final readonly class ApiTokenHandler implements AccessTokenHandlerInterface
{
    public function __construct(
        private ApiTokenRepository $repository,
    ) {}

    public function getUserBadgeFrom(#[\SensitiveParameter] string $accessToken): UserBadge
    {
        $token = $this->repository->findOneByValue($accessToken);

        if ($token === null || !$token->isValid()) {
            throw new BadCredentialsException('Invalid or expired token.');
        }

        return new UserBadge($token->getUser()->getUserIdentifier());
    }
}
```

Інтерфейс `AccessTokenHandlerInterface` вимагає єдиний метод: `getUserBadgeFrom`. Цей метод отримує необроблений токен, витягнутий із запиту (за замовчуванням заголовок `Authorization: Bearer xxx`), і повинен повернути об'єкт `UserBadge`, що містить ідентифікатор пов'язаного користувача. Атрибут `#[\SensitiveParameter]` позначає токен як чутливі дані, запобігаючи його появі в stack traces та логах — передова практика безпеки, запроваджена в PHP 8.2.

Патерн навмисно мінімалістичний: валідація токена (існування, термін дії, відкликання) залишається в репозиторії або окремому сервісі. Handler лише перетворює токен на ідентичність користувача. Цей поділ відповідальностей спрощує модульне тестування та дотримується принципу єдиної відповідальності.

## Voters: гранулярний контроль доступу

Voters є центральним механізмом авторизації в Symfony. На відміну від статичних ролей, визначених в `access_control`, voters забезпечують динамічну логіку прийняття рішень на основі контексту: поточного користувача, цільового об'єкта та запитуваної дії. Кожен voter відповідає на точне запитання: «Чи може цей користувач виконати цю дію над цим об'єктом?»

```php
// src/Security/Voter/PostVoter.php
namespace App\Security\Voter;

use App\Entity\Post;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Vote;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;
use Symfony\Component\Security\Core\User\UserInterface;

final class PostVoter extends Voter
{
    public const EDIT = 'POST_EDIT';
    public const DELETE = 'POST_DELETE';
    public const PUBLISH = 'POST_PUBLISH';

    protected function supports(string $attribute, mixed $subject): bool
    {
        return in_array($attribute, [self::EDIT, self::DELETE, self::PUBLISH])
            && $subject instanceof Post;
    }

    protected function voteOnAttribute(
        string $attribute,
        mixed $subject,
        TokenInterface $token,
        ?Vote $vote = null,
    ): bool {
        $user = $token->getUser();
        if (!$user instanceof UserInterface) {
            $vote?->addReason('User is not authenticated.');
            return false;
        }

        /** @var Post $post */
        $post = $subject;

        return match ($attribute) {
            self::EDIT => $this->canEdit($post, $user, $vote),
            self::DELETE => $this->canDelete($post, $user, $vote),
            self::PUBLISH => $this->canPublish($post, $user, $vote),
            default => false,
        };
    }

    private function canEdit(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if ($post->getAuthor() === $user) {
            $vote?->addReason('User is the author of the post.');
            return true;
        }

        $vote?->addReason('User is not the author.');
        return false;
    }

    private function canDelete(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_ADMIN', $user->getRoles())) {
            $vote?->addReason('User has ROLE_ADMIN.');
            return true;
        }

        if ($post->getAuthor() === $user && !$post->isPublished()) {
            $vote?->addReason('Author can delete unpublished posts.');
            return true;
        }

        $vote?->addReason('Only admins or authors of unpublished posts can delete.');
        return false;
    }

    private function canPublish(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_EDITOR', $user->getRoles())) {
            $vote?->addReason('User has ROLE_EDITOR.');
            return true;
        }

        $vote?->addReason('Only editors can publish posts.');
        return false;
    }
}
```

Кілька елементів цього voter заслуговують на детальний аналіз. Параметр `Vote` (запроваджений у Symfony 7.1) дозволяє прикріплювати текстові обґрунтування до кожного рішення, спрощуючи дебагінг у середовищі розробки та забезпечуючи аудитованість у продакшні. Метод `supports` фільтрує виклики: voter активується виключно для атрибутів `POST_EDIT`, `POST_DELETE` та `POST_PUBLISH`, пов'язаних з екземпляром `Post`.

Вираз `match` у `voteOnAttribute` делегує логіку спеціалізованим приватним методам, кожен з яких інкапсулює бізнес-правила окремої дії. Така структура робить voter читабельним та легко розширюваним: додавання нової дії зводиться до оголошення константи, додавання випадку в `match` та написання приватного методу.

Логіка `canDelete` ілюструє поширений патерн: поєднання перевірки ролі з перевіркою володіння. Адміністратор може видалити будь-яку статтю, але автор може видалити лише власні неопубліковані статті. Такий тип контекстного правила неможливо виразити простими ролями в `access_control`.

## Атрибут IsGranted: декларативний контроль доступу

Атрибут `#[IsGranted]` застосовує контроль доступу безпосередньо на рівні контролера або методу, виконуючи ту саму функцію, що й попередні анотації безпеки, але з нативним синтаксисом PHP. Symfony обчислює вираз перед виконанням методу і повертає відповідь 403, якщо перевірка не пройдена.

```php
// src/Controller/PostController.php
namespace App\Controller;

use App\Entity\Post;
use App\Security\Voter\PostVoter;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

#[Route('/post')]
final class PostController extends AbstractController
{
    #[Route('/{id}/edit', methods: ['GET', 'POST'])]
    #[IsGranted(PostVoter::EDIT, subject: 'post', message: 'You cannot edit this post.')]
    public function edit(Post $post): Response
    {
        // User is guaranteed to have edit permission at this point
        return $this->render('post/edit.html.twig', [
            'post' => $post,
        ]);
    }

    #[Route('/{id}/publish', methods: ['POST'])]
    #[IsGranted(PostVoter::PUBLISH, subject: 'post')]
    public function publish(Post $post): Response
    {
        // Only editors reach this code
        $post->setPublished(true);
        // ...
        return $this->redirectToRoute('post_show', ['id' => $post->getId()]);
    }
}
```

Параметр `subject: 'post'` прив'язує атрибут до параметра методу з такою самою назвою. Symfony автоматично розв'язує сутність через ParamConverter і передає її voter як суб'єкт перевірки. Параметр `message` персоналізує повідомлення про помилку 403, що корисно для дебагінгу та аудит-логів.

Цей декларативний стиль має суттєву перевагу в плані читабельності: правила доступу видимі в тому самому місці, що й сигнатура методу, без необхідності перегляду тіла функції. На технічній співбесіді здатність пояснити повний шлях — від атрибута через voter до `AccessDecisionManager` — демонструє глибоке розуміння компонента Security.

## Стратегії прийняття рішень: unanimous, affirmative, consensus

Коли кілька voters висловлюються щодо однієї перевірки доступу, `AccessDecisionManager` застосовує стратегію прийняття рішень для агрегації голосів. Symfony пропонує три стратегії, які налаштовуються в `security.yaml`.

```yaml
# config/packages/security.yaml
security:
    access_decision_manager:
        strategy: unanimous
        allow_if_all_abstain: false
```

Стратегія `affirmative` (за замовчуванням) надає доступ, щойно хоча б один voter проголосує позитивно. Стратегія `unanimous` вимагає, щоб усі voters, які не утрималися, проголосували позитивно. Стратегія `consensus` надає доступ, якщо більшість voters проголосували позитивно. Параметр `allow_if_all_abstain` визначає поведінку, коли всі voters утримуються.

На практиці стратегія `affirmative` за замовчуванням підходить для більшості застосунків. Стратегія `unanimous` необхідна в контекстах, де безпека має пріоритет: фінансові застосунки, медичні дані, критичні системи. Вона гарантує, що жоден voter не заперечує проти доступу, додаючи шар глибинного захисту. Voter перевірки IP, voter ролі та voter володіння — усі мають схвалити доступ для його надання.

## Дебагінг рішень щодо доступу в Twig (Symfony 7.4)

Symfony 7.4 збагачує дебагінг системи безпеки, відкриваючи обґрунтування рішень щодо доступу безпосередньо в шаблонах Twig. Параметр `Vote`, доданий до voters, набуває повного сенсу: обґрунтування, оголошені через `$vote->addReason()`, з'являються в Profiler і можуть умовно відображатися в шаблонах.

```twig
{# templates/post/show.html.twig #}
{% if is_granted('POST_EDIT', post) %}
    <a href="{{ path('post_edit', {id: post.id}) }}">Edit</a>
{% endif %}

{% if is_granted('POST_DELETE', post) %}
    <form method="post" action="{{ path('post_delete', {id: post.id}) }}">
        <button type="submit">Delete</button>
    </form>
{% endif %}

{% if app.debug %}
    {# Symfony 7.4: access decision debugging in Twig #}
    {% set decision = is_granted_debug('POST_EDIT', post) %}
    <details>
        <summary>Access Decision Debug</summary>
        <ul>
            {% for voter_detail in decision.voterDetails %}
                <li>
                    {{ voter_detail.class }}:
                    {{ voter_detail.result > 0 ? 'GRANTED' : (voter_detail.result < 0 ? 'DENIED' : 'ABSTAIN') }}
                    {% for reason in voter_detail.reasons %}
                        <br>&rarr; {{ reason }}
                    {% endfor %}
                </li>
            {% endfor %}
        </ul>
    </details>
{% endif %}
```

Функція `is_granted()` залишається стандартною точкою входу для перевірок доступу в Twig. Її використання в умовах відображення гарантує, що елементи інтерфейсу (кнопки, посилання) видимі лише авторизованим користувачам. Блок дебагінгу, обумовлений `app.debug`, дозволяє інспектувати деталі голосування в середовищі розробки без розкриття цієї інформації в продакшні.

Цей механізм дебагінгу відповідає на поширену проблему в проєктах Symfony: визначення причини відмови в доступі для користувача. До Symfony 7.4 таке розслідування вимагало ручної інспекції Profiler або додавання тимчасових логів у voters.

## Модульне тестування voters

Voters інкапсулюють критичні бізнес-правила та потребують вичерпного покриття тестами. Кожна комбінація користувач/дія/об'єкт повинна бути верифікована для гарантування узгодженості системи авторизації.

```php
// tests/Security/Voter/PostVoterTest.php
namespace App\Tests\Security\Voter;

use App\Entity\Post;
use App\Entity\User;
use App\Security\Voter\PostVoter;
use PHPUnit\Framework\TestCase;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authorization\Voter\VoterInterface;

final class PostVoterTest extends TestCase
{
    private PostVoter $voter;

    protected function setUp(): void
    {
        $this->voter = new PostVoter();
    }

    public function testAuthorCanEditOwnPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testNonAuthorCannotEditPost(): void
    {
        $author = new User();
        $otherUser = new User();
        $post = (new Post())->setAuthor($author);
        $token = new UsernamePasswordToken($otherUser, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testAdminCanDeleteAnyPost(): void
    {
        $admin = new User();
        $post = (new Post())->setAuthor(new User());
        $token = new UsernamePasswordToken($admin, 'main', ['ROLE_ADMIN']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCanDeleteUnpublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(false);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCannotDeletePublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(true);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testOnlyEditorCanPublish(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_EDITOR']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::PUBLISH]),
        );
    }

    public function testVoterAbstainsOnUnsupportedAttribute(): void
    {
        $user = new User();
        $post = new Post();
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_ABSTAIN,
            $this->voter->vote($token, $post, ['UNSUPPORTED']),
        );
    }
}
```

Кожен тест ізолює конкретне бізнес-правило. Тест `testAuthorCannotDeletePublishedPost` верифікує обмеження, згідно з яким автор втрачає право на видалення після публікації — правило, яке легко пропустити за відсутності тестів. Тест утримання на непідтримуваному атрибуті підтверджує, що voter не втручається в рішення інших voters.

Voters — це чисті PHP-класи без залежностей від фреймворку (у цьому прикладі відсутні інжектовані сервіси), що уможливлює прості модульні тести з PHPUnit. Для складніших voters, що потребують сервісів (перевірка підписки, квотні обмеження), мокування залежностей через `createMock()` залишається стандартним підходом.

> **Події безпеки**
>
> Symfony диспатчить події на кожному етапі процесу безпеки: `AuthenticationSuccessEvent`, `LoginSuccessEvent`, `LogoutEvent`, `SwitchUserEvent` та `AccessDeniedEvent`. Ці події дозволяють додавати логування, сповіщення або додаткові перевірки без модифікації існуючих автентифікаторів чи voters. У продакшні прослуховування `AccessDeniedEvent` живить системи моніторингу та виявляє спроби несанкціонованого доступу.

## Зміцнення безпеки: UserChecker та найкращі практики

Поза voters та firewalls зміцнення безпеки Symfony відбувається через кілька додаткових механізмів. Інтерфейс `UserCheckerInterface` дозволяє додавати додаткові перевірки під час автентифікації, до та після валідації облікових даних.

```php
// src/Security/UserEnabledChecker.php
namespace App\Security;

use App\Entity\User;
use Symfony\Component\Security\Core\Exception\CustomUserMessageAccountStatusException;
use Symfony\Component\Security\Core\User\UserCheckerInterface;
use Symfony\Component\Security\Core\User\UserInterface;

final class UserEnabledChecker implements UserCheckerInterface
{
    public function checkPreAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if ($user->isBanned()) {
            throw new CustomUserMessageAccountStatusException(
                'Your account has been banned. Contact support.'
            );
        }
    }

    public function checkPostAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if (!$user->isVerified()) {
            throw new CustomUserMessageAccountStatusException(
                'Please verify your email address before logging in.'
            );
        }
    }
}
```

`UserChecker` розділяє перевірки на дві фази: `checkPreAuth` виконується перед перевіркою пароля (випадок заблокованого користувача — немає сенсу перевіряти його облікові дані), `checkPostAuth` виконується після (випадок неверифікованої електронної пошти — пароль правильний, але акаунт ще не активований). Цей поділ оптимізує потік автентифікації та надає повідомлення про помилки, специфічні для кожної ситуації.

Додаткові найкращі практики зміцнення безпеки включають:

- **Обмеження частоти запитів**: компонент RateLimiter, інтегрований у Symfony, дозволяє обмежувати спроби входу за IP або ідентифікатором користувача, захищаючи від brute force атак
- **Захист від CSRF**: активація CSRF-захисту на всіх формах, включаючи форму входу, через параметр `enable_csrf` firewall
- **Хешування паролів**: використання хешера `auto`, який автоматично обирає найбезпечніший доступний алгоритм (bcrypt або Argon2id залежно від інсталяції PHP)
- **Ротація секретів**: використання Vault Symfony для чутливих облікових даних, з автоматизованою ротацією ключів шифрування
- **Заголовки безпеки**: налаштування HTTP-заголовків `Content-Security-Policy`, `X-Frame-Options`, `Strict-Transport-Security` через event listener на `kernel.response`

## Питання технічних співбесід

Безпека Symfony є обов'язковою темою технічних співбесід для PHP backend-розробників. Наступні питання охоплюють теми, що оцінюються рекрутерами, від середнього до senior рівня.

**Яка різниця між автентифікацією та авторизацією в Symfony?**
Автентифікація відповідає на питання «Хто ви?» — ідентифікує користувача за його обліковими даними (логін/пароль, API-токен, сертифікат). Авторизація відповідає на питання «Чи маєте ви право?» — перевіряє дозволи автентифікованого користувача через ролі, voters та вирази безпеки. У Symfony firewall керує автентифікацією, тоді як `AccessDecisionManager` та voters керують авторизацією.

**Як працює voter і коли його використовувати замість access_control?**
Voter реалізує `VoterInterface` та відповідає трьома значеннями: `ACCESS_GRANTED`, `ACCESS_DENIED` або `ACCESS_ABSTAIN`. Voters переважні, коли рішення про доступ залежить від контексту: цільового об'єкта (Post, Замовлення), стану цього об'єкта (опублікований, архівований) або зв'язку між користувачем та об'єктом (автор, менеджер). Правила `access_control` в `security.yaml` обмежені статичними перевірками ролей та URL-патернів.

**Яка роль параметра Vote, запровадженого в Symfony 7.1?**
Параметр `Vote` дозволяє voters прикріплювати текстові обґрунтування до своїх рішень. Ці обґрунтування відображаються в Symfony Profiler та можуть використовуватися в шаблонах Twig для дебагінгу. У продакшні вони живлять аудит-логи. Параметр є опціональним і nullable (`?Vote $vote = null`) для збереження зворотної сумісності з існуючими voters.

**Як захистити stateless API в Symfony?**
Firewall повинен бути налаштований з `stateless: true` для вимкнення управління сесіями. Автентифікація спирається на `AccessTokenHandler`, який витягує та валідує токен з кожного запиту. Токени повинні мати обмежений термін дії, безпечно зберігатися на стороні клієнта та бути відкликаними на стороні сервера. Прапорець `#[\SensitiveParameter]` на параметрі токена запобігає його витоку в логи та stack traces.

**Як вичерпно тестувати voters?**
Voters тестуються як стандартні PHP-класи за допомогою PHPUnit. Кожен тест створює екземпляр voter, будує `UsernamePasswordToken`, що симулює користувача з певними ролями, створює цільовий об'єкт у потрібному стані та верифікує, що `vote()` повертає очікуване значення (`ACCESS_GRANTED`, `ACCESS_DENIED` або `ACCESS_ABSTAIN`). Покриття повинно включати всі підтримувані атрибути, граничні випадки (неавтентифікований користувач, непідтримуваний атрибут) та комбінації ролей.

## Висновок

Компонент Security Symfony пропонує архітектуру, одночасно строгу та розширювану, здатну охопити сценарії від класичної автентифікації через форму до багатокритеріальних систем авторизації в розподілених середовищах. Його опанування є безперечним маркером senior-рівня на технічних співбесідах.

Ключові моменти для запам'ятовування:

- **Firewalls**: порядок оголошення визначає відповідність; `security: false` використовувати лише для маршрутів розробки, ніколи в продакшні
- **Stateless проти stateful**: вибір залежить від архітектури (моноліт проти мікросервісів), а не від технічного уподобання
- **Access Token Handler**: інтерфейс `AccessTokenHandlerInterface` уніфікує управління токенами одним методом, спрощуючи тести та підтримку
- **Voters**: віддавати перевагу voters для будь-якої контекстної логіки авторизації; структурувати кожен voter приватними методами на кожну дію
- **Параметр Vote**: використовувати `addReason()` для дебагінгу та аудитованості рішень щодо доступу
- **IsGranted**: застосовувати контроль доступу декларативно на рівні контролера для максимальної читабельності
- **Стратегії рішень**: обирати `unanimous` у чутливих контекстах, де потрібен глибинний захист
- **Тести**: покривати кожну комбінацію користувач/дія/об'єкт у модульних тестах voters
- **Зміцнення**: поєднувати `UserChecker`, обмеження частоти запитів, CSRF, заголовки безпеки та ротацію секретів для багатошарового захисту

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/symfony/symfony-security-voters-firewalls-interview-questions