Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[HttpKernel] Prevent search engines from indexing dev applications #30325
Mar 4, 2019
added a commit
this pull request
Mar 4, 2019
referenced this pull request
Mar 13, 2019
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, including
I can work on a PR.
framework: default_headers: Content-Security-Policy : "script-src 'self' www.google-analytics.com ajax.googleapis.com" Referrer-Policy: same-origin Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload" X-Robot-Tag: noindex X-XSS-Protection: "1; mode=block" X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff
We could even provide sane defaults. WDYT?
For all these security headers, I think using https://github.com/nelmio/NelmioSecurityBundle/ is better. Most of them require more configuration than just knowing whether we are in debug mode or no.
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 using
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.