黑客能夠從服務器上下載index.php文件的機會是什麼（不是結果，而是index.php文件的內容）？你是否建議將index.php的內容放到modules/index_content.php，其中modules文件夾是.htaccess保護AND index.php包含唯一字符串<?php require_once('modules/index_content.php') ?>？是否有意義？index.php並保護其內容
源代碼披露可能發生在配置良好的服務器上，並不像您想象的那麼難得。正如其他人所說，如果你的服務器配置是健全的，那麼直接請求PHP文件的人就不會有問題。
但是你仍然有可能受到：
腳本源通過備份殘疾人專用
許多編輯留下常見的文件擴展名的備份文件，如~或.bak。您的服務器可能無法通過PHP解釋器運行這些服務器，因爲它們通常是通過文件擴展名配置的。留下這些備份文件，你可以公開你的來源。
本地文件包含
還可以有一個問題，如果您有使用用戶輸入讀取其他文件的web應用程序。如果腳本沒有正確驗證用戶輸入，它可能容易受到LFI的影響。這些腳本只能讀取列入白名單的文件，或者至少應限制在某個目錄中。如果「../」被接受，那麼你有一個目錄遍歷漏洞，這將加劇上述兩個漏洞會更加嚴重。
添加到這一點，許多服務器已經啓用
目錄瀏覽
這是當你的服務器將列出目錄中的文件，如果一個默認文件不存在（index.html，index.php，default.htm等）。這不會公開任何來源，但允許服務器上的許多文件（服務器端處理或不處理）將被枚舉給惡意用戶，使其成爲可能非常容易集中進一步的攻擊。經由備用服務器
來源公開
另一個意外情形可以是當指出兩個web服務器（可能是間接地）在相同的文檔根。如果其中一個Web服務器未配置爲處理PHP，則可以披露該源。當一個Web服務器被配置爲反向代理某個URL模式的鏈式應用程序服務器（通常通過目錄）時，我曾多次意外地看到過這種情況。例如讓Tomcat處理/ forum下的所有內容。
SQL注入
幾乎每一個嚴肅的DBMS具有的功能，允許其在系統上讀取文件。如果您不保護數據庫輸入（請僅使用參數化查詢），則可能會通過此機制泄露源代碼。請注意，在這種情況下，源代碼泄露是您最後關心的問題。
我確定有很多其他人，但這些是我看到這種披露的最常見方式。請記住，安全是一個過程，範圍廣泛。通常是作爲導致問題的獨立實體處理的關注點，系統或應用程序的交互。
+1實際提及真正的攻擊考慮。雖然應該注意的是，在一個現代的Linux發行版中，您將無法使用DMBS的文件io功能訪問web根目錄。 AppArmor或SELinux會阻止你。它應該在沒有問題的默認窗口框上工作。 – rook
如果* .php文件被Apache視爲PHP文件（即正常呈現），則不能訪問源，至少不能通過其他腳本或方式訪問服務器（在這種情況下，將腳本添加到modules/index_content.php將不會產生影響）。
它沒有任何意義。
如果有人有權訪問index.php源文件，他還可以訪問所有包含文件的源文件。
沒有辦法通過http下載.php文件，假設您的服務器配置不會改變（例如PHP文件的處理程序被刪除）。如果發生這種情況，那麼有可能.php文件可以作爲純文本文件下載。
您應該將所有核心文件放在公共目錄（public_html，htdocs等）之外並使用它們的路徑調用它們。
+1將您的核心代碼保留在文檔根目錄之外。這可以真正限制其他漏洞的影響。 – Cheekysoft
如果您有目錄遍歷漏洞，則可能會發生這種情況。 – rook
如果您已經在您的網絡服務器上設置了PHP，他們無法下載php文件。
注意：使用htaccess保護文件夾模塊，並在index.php文件中包含一個文件，當有人訪問index.php時，他們必須提供密碼和用戶名才能訪問包含的文件。
有可能爲空。兩大例外，但：
除非你的PHP安裝搞砸了，他們不能下載代碼（假設他們沒有ssh，ftp等訪問權限）。我安裝了一次php + apache，並忘記重新啓動apache，結果人們能夠看到我的* .php文件的源代碼。 – Vamsi