- Issue created by @gr4phic3r
- 🇬🇧United Kingdom mcdruid 🇬🇧🇪🇺
Drupal apps will typically try to let a webserver (e.g. apache, nginx) handle requests for static files such as images, css files etc..
You can make PHP/Drupal handle those requests (e.g. with the private files functionality) but that's usually far less efficient than letting a webserver do the job it's designed for.
That means that Drupal often isn't involved in serving those static assets at all.
If you want to emit particular security headers for them, you'll often have to configure your webserver to do that - e.g. with .htaccess rules or whatever the equivalent is for your webserver of choice.
Some security headers are less relevant when serving static files anyway.
So I think this is "works as designed" unless I'm missing something?
- 🇦🇹Austria gr4phic3r
@mcdruid
thanks for the information, I´m a frontend dev, so I don´t know how dangerous it is and I thought it´s better to open an issue, but when you say that it is not relevant then I guess it is "works as designed". I will try to fix it via .htaccess, but if it is not a big thing to include it then I would still think about it to add this too. - 🇬🇧United Kingdom mcdruid 🇬🇧🇪🇺
The only way seckit can do anything for static assets is if Drupal's private files (or a similar stream-wrapper) is used to serve those files through Drupal / PHP.
Otherwise Drupal doesn't get involved in serving the files at all - the webserver does it without "spinning up" a Drupal / PHP process.
In the majority of cases it's not worth the extra overhead of having Drupal/PHP serve your static files; the webserver is typically really good at doing that job efficiently.
I will close this as "works as designed" as there's nothing for the project to do; this is really down to the configuration of the application and the webserver.
- 🇦🇹Austria gr4phic3r
@mcdruid
Thank you for the clarification, yes, please close it, thanks