爲什麼應用程序不能在debug =「true」模式下運行（good rundown from Scott Gu），有很多性能原因，但是這種做法是否暴露了任何攻擊媒介？這不是「你應該或不應該你」的問題，很明顯，這是一個問題，它是否會引入任何特定的漏洞。在debug =「true」中運行web應用程序是否存在安全風險？
我傾向於認爲remotely detect it與已知性能問題相結合的能力可能會導致對服務可用性的利用，但我希望得到更明確一些的東西。有誰知道可以針對運行debug =「true」的應用程序編排特定的攻擊嗎？
我對這個問題有一些有趣的反饋，特別是在Security Stack Exchange上。有很多與堆棧跟蹤有關的響應（自定義錯誤問題，而不是調試問題）和性能（而不是[直接]安全問題）。
最引人注目的回答是條件編譯常量（#if DEBUG ...）可能會導致意外的行爲，但這又是一個功能風險（在活動環境中執行的意外代碼），而不是安全風險。
我懷疑調試模式可能會根據其在應用程序上的性能開銷以及遠程檢測它的能力（可能存在服務連續性風險）爲其他攻擊打開一些途徑。我已經寫下了我的結論，作爲OWASP Top 10 for .NET developers part 6: Security Misconfiguration的一部分。
因此，爲了完整起見，答案似乎是在調試模式下運行時沒有明顯的安全風險，但考慮到上述因素，對於生產應用程序來說這肯定不是一個好主意。
這在很大程度上取決於DEBUG條件編譯所包含的代碼。
您是否有任何可調試的代碼可被利用？在調試模式下發現'carte blanche'管理員權限並不鮮見...
如果您只有零調試代碼，那麼我能想到的唯一可能是在Web錯誤中發佈了太多堆棧錯誤信息報告。
如果您的應用程序具有良好的（可配置級別）日誌記錄功能（如log4Net），則這一點有點沒有實際意義。
好處，雖然你可能會認爲應用程序中的條件邏輯漏洞的問題多於調試模式本身的漏洞。這個問題與任何特定的應用程序無關，這是一個普遍的問題，關於調試是否只是性能問題或潛在的安全問題。 – 2010-12-12 07:03:50
@Troy Hunt：沒錯，但他們並駕齊驅。我想這將成爲任何代碼審查的一部分... – 2010-12-12 07:07:23
我想你應該把所有的調試操作轉移到一個定製的控制檯，以防止造成debgugging提示，使得攻擊者能夠誤用你的應用程序的漏洞。
爲什麼不在[SecuritySE]（http://security.stackexchange.com/）上提問？ – AviD 2010-12-12 08:44:38
好點，我沒有放在那裏，因爲我想我會在這裏得到答案。我已經發送了一份副本：http://security.stackexchange.com/questions/1180/is-there-a-security-risk-running-web-apps-in-debug-true – 2010-12-16 00:58:02
我已經看到完整的連接字符串（包括密碼）在過去的應用程序在Debug模式下運行時，Custom Errors已關閉，連接失敗 - 在這種情況下，不是因爲數據庫服務器出現問題，而是因爲另一臺服務器充當了唯一的DNS服務器主機退役了。啓用調試模式會大大增加敏感內部應用程序信息泄露的風險，但您已經知道這一點。我喜歡類似的事件，而不是由一個事件引起的崩潰，而是一系列結合起來（通常是悲劇性的）結果。 – pwdst 2013-10-23 13:20:04