Lorsque &php; est compilé en tant que module Apache, ce module hérite des permissions accordées à l'utilisateur faisant tourner Apache (par défaut, l'utilisateur "nobody"). Cela à plusieurs impacts sur la sécurité et les autorisations. Par exemple, si vous utilisez &php; pour accéder à une base de données, à moins que la base n'ait un système de droits d'accès interne, vous devrez rendre la base accessible à l'utilisateur "nobody". Cela signifie qu'un script mal intentionné peut accéder à la base, la modifier sans authentification. Il est aussi possible qu'un robot accède à la page d'administration, et détruise toutes les pages. Vous devez aussi protéger vos bases de données avec les autorisations Apache, ou définir votre propre modèle d'accès avec LDAP, &htaccess;, etc. et inclure ce code dans tous vos scripts : &php;. Souvent, lorsqu'on a établi les droits de l'utilisateur &php; (ici, l'utilisateur Apache) pour minimiser les risques, on s'aperçoit que &php; ne peut plus écrire de virus dans les fichiers des utilisateurs. Ou encore, modifier une base de données privée. Il est aussi incapable de modifier des fichiers qu'il devrait pouvoir modifier, ou effectuer certaines transactions. Une erreur fréquente de sécurité est de donner à l'utilisateur Apache les droits de superadministrateur ou d'améliorer les possibilités d'Apache d'une autre façon. Donner de telles permissions à l'utilisateur Apache est extrêmement dangereux, et peut compromettre tout le système, telle que l'utilisation des sudo ou du chroot. Pour les novices de la sécurité, une telle utilisation est à exclure d'office. Il existe des solutions plus simples. En utilisant open_basedir vous pouvez contrôler et restreindre l'accès à certains dossiers qui pourront être utilisés par &php;. Vous pouvez aussi créer des aires de restrictionsApache, pour restreindre les activités anonymes liées aux internautes.