Caso 1: sólo se sirven archivos públicos

Si su servidor no tiene contenido alguno que no esté restringido por contraseñas o control de acceso basado en direcciones ip, no hay ninguna necesidad de recurrir a estas opciones de configuración. Si su servidor web no le permite hacer redireccionamientos, o el servidor no tiene una forma de comunicarle al binario PHP que la petición de redireccionamiento es segura, puede especificar la opción --enable-force-cgi-redirect en el script de configuración. Aun así debe asegurarse de que sus scripts PHP no dependan de alguna forma especial de hacer llamados al script, ya sea directamente mediante http://mi.servidor/cgi-bin/php/dir/script.php ni por la redirecciónhttp://mi.servidor/dir/script.php.

Los redireccionamientos pueden ser configurados en Apache mediante el uso de directivas AddHandler y Action (vea más adelante).

Caso 2: uso de --enable-force-cgi-redirect

Esta opción en tiempo de compilación previene que cualquier persona haga llamados a PHP directamente mediante una URL como http://mi.servidor/cgi-bin/php/directorio_secreto/script.php. En lugar de esto, PHP analizará documentos de esta forma únicamente si han pasado por una regla de redirección del servidor web.

Por lo general, el redireccionamiento en la configuración de Apache es realizada con alguna de las siguientes directivas:

Action php-script /cgi-bin/php
AddHandler php-script .php

Esta opción ha sido probada únicamente con el servidor web Apache, y depende de que Apache defina la variable de entorno no-estándar REDIRECT_STATUS a la hora de gestionar peticiones redirigidas. Si su servidor web no dispone de modo alguno de comunicar si la petición es directa o redirigida, no puede usar esta opción y debe recurrir a alguna de las otras formas documentadas aquí de ejecutar la versión CGI.

Caso 3: configuración de doc_root o user_dir

Incluir contenido activo en los directorios de documentos del servidor web, como scripts y ejecutables, es considerada en ocasiones una práctica insegura. Si, por algún fallo de configuración, los scripts no llegaran a ser ejecutados sino desplegados como documentos HTML normales, esto podría resultar en la revelación de información crítica como trabajos cubiertos por normas de propiedad intelectual o datos de seguridad como contraseñas. Por lo tanto muchos administradores de sistemas preferirán la configuración de otra estructura de directorios para los scripts que sean asequibles únicamente a través del CGI PHP, y por lo tanto deben ser interpretados siempre y no desplegados directamente.

Así mismo, si el método para asegurarse de que las peticiones no son redireccionadas, tal y como se describió en la sección anterior, no está disponible, es necesario entonces configurar un directorio raíz (doc_root) de scripts que sea diferente al directorio raíz de documentos web.

Puede definir el directorio raíz para scripts de PHP mediante la directiva de configuración doc_root en el archivo de configuración, o puede darle un valor a la variable de entorno PHP_DOCUMENT_ROOT. Si ésta está definida, la versión CGI de PHP construirá siempre el nombre del archivo a abrir con este doc_root y la información de la ruta dada en la petición, de modo que puede estar seguro de que ningún script será ejecutado por fuera de este directorio (excepto por aquellos indicados en user_dir, como se verá a continuación).

Otra opción que puede ser usada en este caso es user_dir. Cuando user_dir no está definida, lo único que controla la apretura de archivos es doc_root. Abrir una URL como http://mi.servidor/~usuario/doc.php no resulta en la apertura de un archivo bajo el directorio personal del usuario, sino de un archivo llamado ~usuario/doc.php bajo la ruta doc_root (así es, un directorio cuyo nombre comienza por el caracter de equivalencia [~]).

Si user_dir está definido como, por ejemplo, public_php, una petición como http://mi.servidor/~usuario/doc.php abrirá un archivo llamado doc.php bajo el directorio con el nombre public_php ubicado en el directorio personal del usuario. Si el directorio personal del usuario es /home/usuario, el archivo ejecutado es /home/usuario/public_php/doc.php.

La expansión del valor de user_dir ocurre independientemente del parámetro doc_root, de modo que es posible controlar el directorio raíz de los documentos y el acceso a los directorios de los usuarios en forma separada.

Caso 4: intérprete PHP por fuera del árbol web

Una opción bastante segura es colocar el intérprete binario de PHP en alguna parte por fuera del árbol de archivos web. En /usr/local/bin, por ejemplo. El único inconveniente real con esta alternativa es que ahora usted tendrá que colocar una línea como esta:

#!/usr/local/bin/php

al comienzo de cualquier archivo que contenga etiquetas PHP. También tendrá que hacer cada archivo ejecutable. Esto quiere decir que debe tratarlo exactamente igual a como trataría cualquier otro script CGI escrito en Perl o sh o cualquier otro lenguaje de scripting común que usara el mecanismo de escape-shell #! para el lanzamiento del intérprete.

Para lograr que PHP gestione correctamente la información de PATH_INFO y PATH_TRANSLATED con este tipo de configuración, el intérprete PHP debe haber sido compilado con la opción de configuración --enable-discard-path.