A < Diretório > dentro de um < VirtualHost > só se aplicará a arquivos dentro daquele diretório quando eles forem acessados através daquele VHost. < Diretório > fora de um < VirtualHost > será sempre aplicável (a menos que seja substituído no < VirtualHost > ou em outro lugar, é claro).
Do ponto de vista da segurança, você pode argumentar em ambos os lados: é provável que os níveis adicionais de acesso ( AllowOverride all
, f.ex.) sejam configurados dentro de um < VirtualHost & gt ;, pois uma interação imprevista entre os scripts em outro VHost pode permitir que você inicie um ataque XSS. As restrições de acesso ( Deny from all
, Allow from 127.0.0.1
) fazem mais sentido fora de um < VirtualHost & gt ;, no caso de haver um backdoor por meio de algo como um Alias de nível superior ou ScriptAlias. E então você entra nas possibilidades realmente complicadas: onde um AllowOverride all
que alimenta uma restrição de acesso em .htaccess
go, já que pode haver um VHost que tenha seu mecanismo de script desativado por motivos de desempenho ou segurança, mas que expõe um arquivo com informações confidenciais normalmente protegidas por .htaccess
?
No final do dia, onde colocar o < Directory > acaba sendo uma combinação de três coisas, em ordem crescente de importância:
- Política - se a empresa sempre colocar o < Directory > dentro de < VirtualHost & gt ;, é quase certamente incorreto agitar o barco.
- Legibilidade - se você tiver seiscentos VHosts, todos eles precisam do mesmo < Diretório > stanza, provavelmente vale a pena quebrar a política.
- Segurança - Se há um benefício de segurança claro para uma abordagem ou outra, então essa é a escolha certa, a política e a legibilidade devem ser condenadas (embora seja aconselhável documentar por que e como você quebrou a política e tomar medidas como usar
Include
para maximizar a legibilidade).