This is a copy of the original question on Stack Overflow which didn't get much love and is probably more relevant here:

There are plenty of performance reasons why apps shouldn't be run in debug="true" mode (good rundown from Scott Gu), but are there any attack vectors exposed by this practice? It's not a question of "should you or shouldn't you", that much is clear, it's a question of whether it introduces any specific vulnerabilities.

I'm inclined to think that the ability to remotely detect it combined with the known performance issues could lead to an exploit against service availability but I'd like something a bit more definite. Does anyone know of a specific attack that can be orchestrated against an app running debug="true"?

  • This depends almost entirely on what language, framework and application you're talking about. What are you using?
    – nealmcb
    Dec 16, 2010 at 20:24
  • ASP.NET, as per the tag :)
    – Troy Hunt
    Dec 16, 2010 at 21:06

6 Answers 6


I've had some interesting feedback on this question both here and on Stack Overflow. There have been lots of responses related to stack traces (a custom errors issue, not a debug issue) and performance (not [directly] a security issue).

The most compelling response is that conditional compilation constants (#if DEBUG...) could cause unexpected behavior, but this again is more of a functionality risk (unintended code being executed in a live environment), than a security risk.

I suspect debug mode may open some pathways to other exploits based on the performance overhead it places on the app and the ability to remotely detect it (service continuity risk, perhaps). I've written up my conclusions as part of OWASP Top 10 for .NET developers part 6: Security Misconfiguration.

So for the sake of completeness, the answer appears to be that there is no clear security risk from running in debug mode, but it certainly isn't a good idea for production apps given the factors mentioned above.


By allowing potential attackers potential access to source code, stack traces, etc. it certainly allows them to focus/narrow an attack to the system.

I'd also assume (though haven't tested it) that since debug=true causes the compilation error rather than the expected site customerror, you could be exposed to the .net customerror crypto bug.


  • 4
    Thanks for the feedback, but HOW does debug mode expose either source code or the stack trace? Custom errors is a separate topic - let's assume they're on and there's no YSOD or stack trace exposed in the web response.
    – Troy Hunt
    Dec 16, 2010 at 6:11
  • @TroyHunt When writing in PHP, the stack trace and errors can be sent the client... that's probably the case of other languages too. Apr 11, 2016 at 21:42

I would think that if customErrors = off and debug= true, than even more information would be sent to an attacker.

It is safer to say customErrors = on or customErrors = RemoteOnly. That way a remote user will always get the generic ASP.NET error page. More information on MSDN

  • 1
    I believe you have that backwards. customerrors should be remoteOnly or on.
    – Steve
    Dec 16, 2010 at 17:23

The biggest thing to keep in mind when debug=true is that the symbols are there. The application can be precompiled with debug=true, but this is part of the deployment process. E.g. you get it built by the build server or on your local machine and transfer the assemblies over. (everyone is precompiling their applications before production deployment right?! :) ) Debug also has certain runtime optimizations turned off. An obvious attack would be a DoS. If custom errors are off you can also find out more information on the call stack -- moreso than if custom errors are off and the symbols are not there.

  • I think you're right about the precompiling - I'm pretty sure that's the way it was in v2/earlier, which has been changed (so I removed my answer).
    – AviD
    Dec 16, 2010 at 16:53
  • @AviD I believe you are correct, but only if the application is deployed as source code.
    – Steve
    Dec 16, 2010 at 17:14

This depends almost entirely on the language/framework/deployment environment.

For python/django, it is very explicitly the case that DEBUG=True is a security issue. See e.g. the notes on not showing configuration variables for 'SECRET', 'PASSWORD', 'PROFANITIES', or 'SIGNATURE' - see http://docs.djangoproject.com/en/dev/ref/settings/#debug

  • 1
    True, but the context was for ASP.NET which is somewhat different than Python :)
    – Steve
    Dec 16, 2010 at 20:45

It's bad from information leak point of view, no need to repeat that. Additionally in debug mode request execution timeout is about 5 hours, so you can debug your application without getting timeouts. (Normal timeout value is 110 seconds by default) So if attackers find a code that takes too long to execute this attack may turn into a denial of service.

  • 1
    Sure, but what are you leaking? Keeping the issue of custom error settings aside, is debug mode alone "leakage"? Ok, that fact the app is in debug can be disclosed by making an HTTP DEBUG request, but other than that, is there really any info leakage?
    – Troy Hunt
    Dec 21, 2010 at 22:06
  • You are right you don't leak at lot of information if you configure custom errors. But anyway you are leaking the fact that you debug your applications on production servers, you are unlikely to have a well defined test,release cycle, you are likely to have debug code on your server etc etc.
    – Nathan B.
    Dec 23, 2010 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .