Hallo

Dann bleibt noch das Szenario übrig, dass der Webserver fehlkonfiguriert ist und PHP-Code unabgearbeitet rausgibt. Das sollte zwar recht schnell auffallen, weil dann mit Sicherheit ziemlich viel nicht mehr läuft, dagegen hilft aber, (PHP-)Code in eine Datei auszulagern, die nicht ausgeliefert werden kann. Also Dateien, die außerhalb des DocumentRoot abgelegt sind. Und das kann dann ruhig PHP-Code bleiben, muss nicht irgendein anderes Dateiformat werden. Allerdings ist das DocumentRoot ebenfalls (fehl)konfigurierbar.

Vorschlag: Alle Libraries aus dem DocRoot rausnehmen und nur noch eine PHP-Datei vorhalten, die vom Webserver geparst wird.

Nur mal so. Wenn man nicht alles in einer Ressource, typischerweise mit einem Haufen von URL-Parametern, die bestimmen, was ausgegeben wird, abhandeln will, hat man für jede Seite eine zu parsende PHP-Datei. Ich persönlich finde das übersichtlicher, aber lassen wir das Geschmackssache sein. Daher würden bei mir jene Dateien, die Zugangsdaten jeglicher Coleur enthalten, außerhalb des Docroot oder ersatzweise in einem per .htaccess gesicherten Verzeichnis [1] landen.

<nitpicking>Außerdem werden natürlich auch die eingebundenen, außerhalb des Docroot liegenden, PHP-Dateien, wenn auch nicht durch den Webserver, sondern durch den durch ihn aufgerufenen PHP-Interpreter, geparst.</nitpicking>

?
   ?
  ?
\_/7

Joah, meiner ist mittlerweile kalt.

[1] Es soll ja vereinzelt immer noch Hoster geben, bei denen man keinen Zugriff auf Verzeichnisse außerhalb des Docroot hat. Man sollte denen aber auf die Füße treten oder über kurz oder lang den Rücken kehren.

Tschö, Auge