This bug is still present in 4.2, is there any way we can help to solve this? I'm not sure where to start to fix this by myself. 😕

This issue seem's to be setted in the Normalization of Symfony\Bundle\SecurityBundle\DependencyInjection\MainConfiguration::getConfigTreeBuilder

$rootNode
	->beforeNormalization()
		->ifTrue(function ($v) {
			if (!isset($v['access_decision_manager'])) {
				return true;
			}

			if (!isset($v['access_decision_manager']['strategy']) && !isset($v['access_decision_manager']['service'])) {
				return true;
			}

			return false;
		})
		->then(function ($v) {
			$v['access_decision_manager']['strategy'] = AccessDecisionManager::STRATEGY_AFFIRMATIVE;

			return $v;
		})
	->end()

If reproduce this issue by adding the config/package/security.yaml to the following:

access_decision_manager:
    strategy: unanimous
    allow_if_all_abstain: false

If you set something in the config/package/dev/security.yaml for instance but don't set the access_decision_managers, it will override if with the default value set in the MainConfiguration when processing the second (dev config) and override the main config with the default normalization value.

This bug is still present in Symfony 4.3

This bug is still present in Symfony 5.2, and when you wan to use own Access decision manager:

security:
    access_decision_manager:
        service: App\Security\OwnAccessDecisionManager
        # not strategy defined

it also returns an error related to this issue:

Invalid configuration for path "security.access_decision_manager": "strategy" and "service" cannot be used together.

ifTrue() returns false, but then() is still called.

Also reported in #39939

status: reviewed

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

I don't think this was solved.

I agree. The bug i.m.o. is very relevant and can cause security incidents.

In our case, we created a custom voter, denying access to a certain resource for a user in 'demo-mode'.
With a unanimous decision, the user would get a 403.

however, in the prod environment, we enabled login throttling in config/packages/prod/security.yaml
to find out later, that users were able to access the content that should not be availbable to them.

using debug:config security told us that the decision strategy was now suddenly affermative
So some other voters that were also voting (f.i. by default access rules) where overruling our custom voter's result.

a workaround would be to copy/paste settings to the prod/security.yaml configuration. That did solve the issue in this case, but makes you wondering what other settings are overwritten by defaults.

On version 5.3.9

Same issue here, in 5.3.10 - and I quite agree with @Gielovic, in my case it was causing tests to behave differently that the app, which could lead to (authorization) issues being pushed to production.

I'm not sure how to easily fix it (in Symfony code), though.