On top of CAM-11293, I propose that HTTP Basic Authentication should be enabled for REST engine out-of-the-box. Reasons:

• Encourage secure-by-default. Requiring a user (especially that Camunda is open source software that can be used without training) understands that Camunda by default is insecure is not realistic.
• Potential risk of security breaches that damages for Camunda users and Camunda itself. Please learn from MongoDB (https://nakedsecurity.sophos.com/2018/09/19/here-we-mongo-again-millions-of-records-exposed-by-insecure-database/) and Elasticsearch (https://securityboulevard.com/2019/11/an-unsecured-elasticsearch-server-exposed-1-2-billion-user-records-containing-their-personal-and-social-information/)
• Most initial users will care more about Cockpit and Tasklist than REST. And when they do care about REST, adding an Authorization header is not a big effort, and with proper documentation/quickstart, should be smooth. And again, *with a good password*, more secure than no authentication.

I'd also argue that having a demo:demo account is a bad idea. It should be an auto-generated password that is shown to console on first startup (and provides a way to reset it if missing), and this auto-generation can be turned off. In Kubernetes/Helm environment, the auto-generated password is saved to a Kubernetes secret, which makes it both secure and convenient. But this is another topic.

Our experience with Camunda BPM Run: https://about.lovia.life/docs/infrastructure/camunda/

cc tobias.metzke