Correct owner/group/permissions for Apache 2 site files/folders under Mac OS X?

If you really don't like the Terminal here is the GUI way to do dkamins is telling you :

1) Go to your user home directory (ludo would be mine) and from the File menu choose Get Info cmdI in the inspector :

2) By alt/option clicking on the [+] sign add the _www group and set it's permission to read-only :

• Thus consider (good practice) not storing personnal information at the root of your user home folder (& hard disk) !
• You may skip this step if the **everyone** group has **read-only** permission but since AirDrop the **/Public/Drop Box** folder is mostly useless...

3) Show the Get Info inspector of your user Sites folder and reproduce step 2 then from the gear action sub-menu choose Apply to enclosed Items... :

Voilà 3 steps and the GUI only way...

I know this is an old post, but for anyone upgrading to Mountain Lion (10.8) and experiencing similar issues, adding FollowSymLinks to your {username}.conf file (in /etc/apache2/users/) did the trick for me. So the file looks like this:

<Directory "/Users/username/Sites/">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride All
  Order allow,deny
  Allow from all
</Directory>

This is the most restrictive and safest way I've found, as explained here for hypothetical ~/my/web/root/ directory for your web content:

• For each parent directory leading to your web root (e.g. ~/my, ~/my/web, ~/my/web/root):
  • chmod go-rwx DIR (nobody other than owner can access content)
  • chmod go+x DIR (to allow "users" including _www to "enter" the dir)
• sudo chgrp -R _www ~/my/web/root (all web content is now group _www)
• chmod -R go-rwx ~/my/web/root (nobody other than owner can access web content)
• chmod -R g+rx ~/my/web/root (all web content is now readable/executable/enterable by _www)

All other solutions leave files open to other local users (who are part of the "staff" group as well as obviously being in the "o"/others group). These users may then freely browse and access DB configurations, source code, or other sensitive details in your web config files and scripts if such are part of your content. If this is not an issue for you, then by all means go with one of the simpler solutions.