osx 10.7.5 built-in apache 403 forbidden for sites/default/files/styles this really drives me crazy .. BTW here is a really nice tutorial i tried - everything. believe me ...
from adding users to groups, running apache as different user, chALOT -R (even chmod a+rwx), copying the original httpd.conf back, enabled UserDir, added attributes like

sudo chmod -R +a "group:_www allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" Sites


but .. i'm not an expirienced sys admin // ---

i try to use both - WebServer and User location as Document root

setup
/etc/apache2/http.conf

setup
/etc/apache2/users/me.conf


and actually all seems to work fine. so AllowOverride and FollowSymLinks set

except: sites/default/files/styles/

image styles do not work i get 403 for requests like

sites/default/files/styles/fancy/public/animage.jpg


original images show up ..

maybe related to the 7.20 issue ?!

how can i properly debug this ?
This is more likely to be the issue with the update of Drupal core from 7.19 to 7.20.
As per the release notes, the update was only targeted to address the Denial-of-Service attack on the sites powered by Drupal.

You can add:

$conf['image_allow_insecure_derivatives'] = TRUE;


in the settings.php, to negate the effect of the update. As per the side effects, this will remove this security fix. I wouldn't recommend you do this on production.

existing patch:

--- a/modules/image/image.module
+++ b/modules/image/image.module
@@ -993,7 +993,7 @@ function image_style_url($style_name, $path) {
// The token query is added even if the 'image_allow_insecure_derivatives'
// variable is TRUE, so that the emitted links remain valid if it is changed
// back to the default FALSE.
-  $token_query = array(IMAGE_DERIVATIVE_TOKEN =&gt;  image_style_path_token($style_name, $path));
+  $token_query = array(IMAGE_DERIVATIVE_TOKEN =&gt; image_style_path_token($style_name, file_stream_wrapper_uri_normalize($path)));


works, and $conf can be removed !

I've answered a similar question here.

Note: I'm making this as community wiki, so that someone working on Drupal security (hopefully from the security team) or anyone who is interested could add more to it.