Security hardening for default PostgreSQL credentials & public DB exposure in Dify deployments

[Cristliu]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

During an ethics-reviewed measurement of self-hosted LLM deployments (multi-platform), we noticed that some Dify setups expose their database service to the Internet and keep weak/default credentials. In testbed validation, this combination can escalate to severe impact.
We are not sharing exploitation details here and have a private write-up ready for the maintainers via GHSA/security contact.

2. Additional context or comments

To reduce admin mistakes and improve out-of-the-box security, we suggest:

• Production instances remove host-level DB port mapping; prefer network-local access only.

• First-run must generate strong random secrets and refuse to start when defaults are detected.

• Use least-privilege DB role for the app; superuser reserved for offline admin.

• Add startup guardrails (blocking banner or health check) when DB is world-reachable or weak creds are detected.

• Provide a “Production Hardening” doc covering DB exposure, secret rotation, HTTPS, RBAC, and reverse-proxy/VPN patterns.

We’re happy to coordinate privately (GHSA) and retest fixes on our lab setup.

3. Can you help us with this feature?

• I am interested in contributing to this feature.