[the_mitsuhiko]

> explicitly try to figure out if it's running in production mode

Does not help. The cases I saw in the past were people putting Werkzeug's stuff behind ngrok, proxies, nginx in which cases it will all look like local requests.

[jzd]

Not true. For example nginx can use the proxy_pass directive to forward real IP address information and log it

[the_mitsuhiko]

The situation here is that people did not read the docs. Do you think they will start to read the docs for the proxy pass?

Aside of that, you cannot securely detect this because what it actually does is passing in a header which if not reliably set can be forged.

[gozo]

I wouldn't assume people didn't read the docs so much as they made a mistake deploying (part of) a development setup to production. Security isn't an all or nothing thing, it's about having a good chance of doing the right thing. I think having to explicitly enable the interactive part, something that isn't really standard either, would be sensible e.g. app.run(debug=True, debug_shell=True). At least that would make people even more aware and limit the potential of incidents to those who actually use the feature.

It's not exactly uncommon that people leak errors, remote code execution is another level though. It doesn't hurt to be careful with such a feature.

[the_mitsuhiko]

I implemented a pin based system now. It prints a PIN on first usage in 8 hours to the terminal and you need to enter it to unlock the console. This is IP bound.

It's still only a way to prevent greater damage, you should still not run the debugger enabled in prod.