A <Directory> inside of a <VirtualHost> will only apply to files within that directory when they are accessed via that VHost. <Directory> outside of a <VirtualHost> will always apply (unless overridden in the <VirtualHost> or elsewhere, of course).
From a security standpoint, you can argue both sides: additional levels of access (
AllowOverride all, f.ex.) are probably wiser to configure inside a <VirtualHost>, since an unforeseen interaction between the scripts on another VHost might allow you to launch a XSS attack. Restrictions on access (
Deny from all,
Allow from 127.0.0.1) make more sense outside of a <VirtualHost>, in case there's a backdoor via something like a top-level Alias or ScriptAlias. And then you get into the really complicated possibilities: where does an
AllowOverride all that powers an access restriction in an
.htaccess go, since one might have a VHost which has its scripting engine disabled for performance or security reasons, but which then exposes a file with sensitive information typically protected by
At the end of the day, where to place the <Directory> ends up being a combination of three things, in increasing order of importance:
- Policy—if the company always puts <Directory> inside <VirtualHost>, it's almost certainly incorrect to rock the boat.
- Legibility—if you have six hundred VHosts, all of which need the same <Directory> stanza, it's probably worth breaking with policy.
- Security—If there's a clear security benefit to one approach or the other, then that is the de facto right choice, policy and legibility be damned (though you'd be well-advised to document why and how you broke with policy, and to take measures like using
Include to maximize legibility).