@GaryPEGEOT Please, don't change code that your PR does not change (even if fabbot ask for it).

@javiereguiluz where should I document the new option?

Thank you@GaryPEGEOT.

@GaryPEGEOT sorry I didn't reply to your comment. This feature is being documented insymfony/symfony-docs#11148. Thanks.

Sorry I'm late on this one, but this feature could have been a bit more generic: the config could allow to set headers that will always be sent, includingX-Robot-Tag, but also Content Security Policies, HSTS, HPKP settings, theReferrer header, CORS settings...

I can work on a PR.

@dunglas can you please show an example of the HTTP header/s added to the response with your proposal and a sample of the YAML config used to do that? Thanks.

on the other side, having rich configuration with sane defaults, per case is nice. But agree this could be aggregated into a single default header listener 👍

@javiereguiluz:

framework:default_headers:Content-Security-Policy:"script-src 'self' www.google-analytics.com ajax.googleapis.com"Referrer-Policy:same-originStrict-Transport-Security:"max-age=31536000; includeSubDomains; preload"X-Robot-Tag:noindexX-XSS-Protection:"1; mode=block"X-Frame-Options:SAMEORIGINX-Content-Type-Options:nosniff

We could even provide sane defaults. WDYT?

I like this idea@dunglas ! Perhaps it should be underframework.http.* though, because there are more http related settings such as session?

@dunglas are we completely sure that 100% of existing apps are going to keep working if we apply those headers by default? Thanks.

@javiereguiluz no! By default I mean "in the config generated by the recipe".

Please don't call other people "idiots".

For all these security headers, I think usinghttps://github.com/nelmio/NelmioSecurityBundle/ is better. Most of them require more configuration than just knowing whether we are in debug mode or no.

And thisdefault_headers proposal would still have to be separate from the current feature, as addingX-Robot-Tags through it only in debug mode would be much more complex.

@HTMLGuyLLC I agree with@linaori's comment and I ask you to please not call other people "idiots".

About your original comment, I'm afraid that those people who"run Symfony in dev because they cannot make it work in prod" will need to try again to put things in prod and report here any problem that they find in Symfony itself. Thanks!

Even if we don't go with an idea of having config for these like@dunglas suggested, at least listener class itself could be made in more generic way, so userland can write compiler pass with own rules. Having such single purpose listener which is completely inflexible seems such a waste to me. Changing it so headers can be injected should be trivial.

edit: on second thought, problem with this might be be that it needs to be re-registered in prod :/

one can still provide default headers per environment config, given this node merges each. A sub config might want to clear an inherited header usingX-Name: false

For all these security headers, I think usinghttps://github.com/nelmio/NelmioSecurityBundle/ is better.

Agree, but for the simple case this config spares out some boilerplate code.

The flip side is we get more feature requests eventually; like expression support; better security defaults. I think that's reasonable, but so is a code solution or an external bundle.

Sticking with "config per case" avoids that decision path.