Thanks for the reply, Allard! In short it means that the Nginx configuration will become identical to Magento's default configuration using htaccess files (it's too much credit to call it my solution :)). At least, if it's just a typo that you mentioned /lib/ in your last comment (should have been /skin/).

Of course I also think that the current restriction is good practice. The only problem is that it's different from Magento's default.

Will release Mark's solution tomorrow: disallow /var/ and /media/, allow in /js/ and /lib/ and render static 404 in all these places.

Michael will document this soon. Although I think the current restriction is good practise, a couple of our users have spent much of their time debugging this problem.

Even if we write good docs, they will still have to figure out that the problem of missing CSS can be solved by implementing recipies from those docs.

The better option is to allow /js/ and /skin/, but render static 404 there. Then deny from /var/ and /media/. So in short, Mark's solution. We'll discuss internally.

Good luck!

I think the reason that php execution is prohibited, by default, is because if a site gets hijacked, the attacker often tries to hide backdoors among the images for instance. In my opinion the current settings are a sane default. It's not like one will dynamically place php files in a folder that need to be requested via http. Adding php files to media or skin is a discrete/static event that can be planned and anticipated. Imo all that is required is a consistent and documented way to override the default.

Thanks Luk for the clear answer! I assume it solves my problem, will try this afternoon. It's obvious that I haven't played enough with Nginx :)

Still I think it's good for Hypernode to follow Magento's default rules for easier migration to Hypernode.

More important: the rules that Magento defines make sense: /media is the place for user data and /var for application data, so php execution should be denied there (and /var should be denied public access). I can't think of any reason for denying execution in /skin or /js.

Of course, the rule for plain 404s in /skin and /js should stay in place. The 404 page for missing files in /skin or /js should never be generated by Magento.

Fortunately (in this case) Ngnix does not have a "first match" or "stateful" matching principle when matching requests to location blocks, but they have their own matching order: http://nginx.org/en/docs/http/ngx_http_core_module.html#location

This means that one can locally override the (sane) security measure that Byte implemented for specific files. One can append the follow kind of code to $HOME/nginx/server.rewrites (or create your own server.something file)

# Override security check for this css-generating php file in the skin folder
location = /skin/frontend/mypackage/mytheme/css/blablabla.css.php {
echo_exec @phpfpm;
}

Note that the equals sign denotes an exact match. Don't forget the leading slash! However, ignore the query string (?var1=val1&var2=val2)!

Obviously this works for php files in any given directory, be it app, media, var, js, skin or any other directory.

@peterjaap I only see /var and /media mentioned there. Exactly like Magento configures it for you.

Maybe it has something to do with Lee's talk at MM14NY about Magento security where he advocated something like (but not exactly) this; http://www.slideshare.net/lsaferite/magento-security-and-us